Federal XML Naming and Design Rules and Guidelines

Table of Contents

[1 Introduction 1-7](#introduction)

[1.1 Purpose 1-7](#purpose)

[1.2 Scope 1-7](#scope)

[1.3 Audiences 1-8](#audiences)

[1.4 Terminology and Notation 1-9](#terminology-and-notation)

[1.5 Conformance to PL 104-113 and OMB A119
1-12](#conformance-to-pl-104-113-and-omb-a119)

[1.5.1 W3C Recommendations 1-14](#w3c-recommendations)

[1.6 Guiding Principles 1-16](#guiding-principles)

[1.6.1 General Guiding Principles 1-16](#general-guiding-principles)

[1.6.2 Design For Extensibility 1-17](#design-for-extensibility)

[1.6.3 Data versus Document Centric XML
1-18](#data-versus-document-centric-xml)

[1.6.4 Code Generation 1-19](#code-generation)

[1.7 Document Organization 1-19](#document-organization)

[2 Information Analysis 2-1](#information-analysis)

[2.1 Defining Data 2-1](#defining-data)

[2.2 Relationships Between Data Elements 2-2](#defining-relationships)

[2.3 Transforming Data into XML 2-3](#transforming-data-into-xml)

[3 General XML Constructs 3-1](#general-xml-constructs)

[3.1 Overall XML Schema Structure 3-1](#overall-xml-schema-structure)

[3.1.1 Root Element 3-3](#root-element)

[3.2 Constraints 3-4](#constraints)

[3.2.1 Naming Constraints 3-4](#naming-constraints)

[3.2.2 Modeling Constraints 3-4](#modeling-constraints)

[3.3 Reusability Scheme 3-6](#reusability-scheme)

[3.4 Namespace Scheme 3-6](#namespace-scheme)

[3.4.1 Declaring Namespaces 3-7](#declaring-namespaces)

[3.4.2 Namespace Uniform Resource Indicators
3-9](#namespace-uniform-resource-indicators)

[3.4.3 Persistence Error! Bookmark not
defined.](#__RefHeading___Toc114385967)

[3.5 Versioning Scheme 3-11](#versioning-scheme)

[3.5.1 Draft XML Schema 3-12](#draft-xml-schema)

[3.5.2 Standard XML Schema 3-13](#standard-xml-schema)

[3.5.3 Minor Version Changes 3-13](#minor-version-changes)

[3.5.4 Versioning Numbering Scheme 3-14](#versioning-numbering-scheme)

[3.5.5 Versioning Import Requirements
3-14](#versioning-import-requirements)

[3.6 Modularity 3-14](#modularity)

[3.6.1 Leveraging VCS Datatypes 3-17](#leveraging-vcs-datatypes)

[3.6.2 XML Schema Modules 3-18](#xml-schema-modules)

[3.6.3 Federal External XML Schema Modules
3-20](#federal-external-xml-schema-modules)

[3.6.4 Department and Agency Modularity Options
3-22](#department-and-agency-modularity-options)

[3.6.5 Modularity and Namespaces 3-25](#modularity-and-namespaces)

[3.7 Documentation 3-27](#documentation)

[3.7.1 Annotation 3-27](#annotation)

[3.7.2 Embedded Documentation 3-27](#embedded-documentation)

[3.7.3 Management Information 3-28](#section)

[3.7.4 Content Information 3-33](#__RefHeading___Toc114385984)

[3.7.5 XML Schema Guides Error! Bookmark not
defined.](#__RefHeading___Toc114385985)

[4 Naming XML Constructs 4-1](#naming-xml-constructs)

[4.1 General Naming Rules 4-1](#general-naming-rules)

[4.1.1 Syntax Neutral Naming Rules 4-1](#syntax-neutral-naming-rules)

[4.1.2 XML Naming Rules 4-7](#__RefHeading___Toc114385989)

[4.2 Type Naming Rules 4-8](#type-naming-rules)

[4.2.1 Complex Type Names for Complex Data Elements
4-8](#complex-type-names-for-complex-data-elements)

[4.2.2 Complex Type Names for Simple Data Elements
4-8](#complex-type-names-for-simple-data-elements)

[4.2.3 Type Names for Unqualified Datatypes
4-8](#type-names-for-unqualified-datatypes)

[4.2.4 Type Names for Qualified Datatypes
4-9](#type-names-for-qualified-datatypes)

[4.2.5 Type Names for Codes and Identifiers
4-9](#type-names-for-codes-and-identifiers)

[4.3 Element Naming Rules 4-9](#element-naming-rules)

[4.3.1 Element Names for Complex Data Elements
4-9](#element-names-for-complex-data-elements)

[4.4 Attribute Naming Rules 4-9](#attribute-naming-rules)

[5 Declarations and Definitions 5-1](#declarations-and-definitions)

[5.1 Type Definitions 5-1](#type-definitions)

[5.1.1 General Type Definitions 5-1](#general-type-definitions)

[5.1.2 Simple Type Definitions 5-1](#simple-type-definitions)

[5.1.3 Complex Type Definitions 5-1](#complex-type-definitions)

[5.2 Element Declarations 5-4](#element-declarations)

[5.2.1 Global and Local Elements 5-4](#global-and-local-elements)

[5.2.2 Elements Bound to Complex Types
5-4](#elements-bound-to-complex-types)

[5.2.3 Elements Bound to Simple Types
5-5](#elements-bound-to-simple-types)

[5.2.4 Elements Representing Associations between Complex Data Elements
5-5](#elements-representing-associations-between-complex-data-elements)

[5.2.5 Elements Bound to Datatypes 5-5](#elements-bound-to-datatypes)

[5.2.6 Elements representing Code Lists and Identifier Lists
5-5](#elements-representing-code-lists-and-identifier-lists)

[5.2.7 Empty Elements 5-5](#empty-elements)

[5.2.8 XSD:Any Elements 5-7](#section-4)

[5.3 Attribute Declarations 5-7](#attribute-declarations)

[5.3.1 User Defined Attributes 5-7](#user-defined-attributes)

[5.3.2 Metadata Attributes 5-7](#metadata-attributes)

[5.3.3 Global Attributes 5-8](#attribute-groups)

[5.3.4 Using Attribute Groups Error! Bookmark not
defined.](#__RefHeading___Toc114386017)

[5.3.5 XML Schema Location 5-8](#xml-schema-location)

[5.3.6 XSD:Nil 5-8](#xsdnil)

[5.3.7 XSD:anyAttribute 5-8](#xsdanyattribute)

[6 Extending and Restricting Types
6-1](#extending-and-restricting-types)

[6.1 Guidelines for Extension 6-1](#guidelines-for-extension)

[6.2 Guidelines for Restriction 6-1](#guidelines-for-restriction)

[6.3 Xsd:SubstitutionGroup 6-1](#xsdsubstitutiongroup)

[6.4 xsd:final 6-1](#xsdfinal)

[7 Code Lists and Identifier Lists
7-1](#code-lists-and-identifier-lists)

[8 Using XML Schematron 8-1](#using-xml-schematron)

[9 Miscellaneous XSD Rules 9-1](#miscellaneous-xsd-rules)

[9.1 xsd:simpleType 9-1](#xsdsimpletype)

[9.2 Namespace Declaration 9-1](#namespace-declaration)

[9.3 xsd:notation 9-1](#xsdnotation)

[9.4 xsd:appinfo 9-1](#xsdappinfo)

[9.5 xsd:key and xsd:keyRef 9-1](#xsdkey-and-xsdkeyref)

[10 XML Instances 10-1](#xml-instances)

[10.1 Validation 10-1](#validation)

[10.2 Character Encoding 10-1](#character-encoding)

[10.3 Root Element 10-1](#root-element-1)

[10.4 XML Schema Instance Attribute Namespace Declaration
10-2](#xml-schema-instance-attribute-namespace-declaration)

[10.5 Empty Elements and Null Values Error! Bookmark not
defined.](#__RefHeading___Toc114386039)

### Appendix A Federal XML Naming and Design Rules Checklist {#appendix-a-federal-xml-naming-and-design-rules-checklist .unnumbered}

### Appendix B Approved Acronyms and Abbreviations {#appendix-b-approved-acronyms-and-abbreviations .unnumbered}

### Appendix C Metadata Components {#appendix-c-metadata-components .unnumbered}

### Appendix D Approved Representation Terms {#appendix-d-approved-representation-terms .unnumbered}

### Appendix E Technical Terminology {#appendix-e-technical-terminology .unnumbered}

# Introduction

Shortly after the release of the World Wide Web Consortium (W3C) XML
Schema Definition (XSD) Language specifications, the Federal XML Working
Group released the first draft Federal XML Users Guide. That document
provided developers with early guidance on creating XMLSchema in a
consistent fashion so as to further XML interoperability. As XML has
matured, the need for an update to that document has become more and
more apparent. This document leverages that earlier work and is intended
to enable more consistent, interoperable XML solutions at every level
with the federal government.

## Purpose

The purpose of this Federal Naming and Design Rules and Guidelines
(NDRG) document is to provide:

-   a flexible federal modularity model that defines the structure for
    creating interoperable XML Schema

-   a clearly defined namespace scheme that ensures consistency across
    Agencies

-   a versioning scheme that will support consistency in versioning of
    government XML Schema

-   a Federal canonical XML Schema for base Data Types

-   specific NDR's by government agencies or communities of practice
    that build on this document

-   a reference to use for a mapping of different agency NDR's to each
    other

## Scope

This Federal XML Naming and Design Rules and Guidelines document is
intended for use by Executive Branch Departments and Agencies
(hereinafter referred to as Agency) that employ XML, including
commercial and government off-the-shelf XML related product
implementations. It should be used by contractors and vendors doing XML
development work on behalf of Departments and Agencies. Agencies
developing specific XML Naming and Design Rules and Guidelines should
use this document as the baseline for those efforts.

Section of this document describes that XML can be used within
data-centric as well as document-centric environments. The rules and
guidelines in this document, however, apply only to the development of
XML content intended for use in data-centric applications. Within IT
systems, XML Schema can also be used to support document presentation
requirements.

This document, however, provides no guidance regarding document-centric
scenarios and should not be considered as guidance for document-centric
XML Schema development. Any references to document-centric XML Schema is
included solely to establish a context for the respective rule or
guidance for those readers who may be more familiar with
document-centric initiatives..

Finally, it is critical to note that this document provides one piece of
a larger whole. That is, while the rules and guidance put forth in this
document provide the means by which XML interoperability efforts can be
streamlined, successful adoption and implementation of these rules and
guidance can occur only when they are understood within the context of a
governance framework.

Such a framework will specify the policies and procedures for such
things as submission and approval of XML Schema content by an agency for
use by the larger federal community. The definition of such a governance
framework and its rules of engagement are fully outside of the scope of
this document but are assumed (and referred to as such) to be critical,
supplementary content to this document.

## Audiences

-   Developers of Federal Enterprise XML Schema. Federal enterprise XML
    Schema are those XML Schema that will achieve status as a standard
    to be used across the federal government by all agencies and
    departments. These include federal level reusable XML Schema as
    defined in Section (x.x), as well as XML Schema designed for
    specific business processes or information blocks that will have
    widespread reuse.

-   Agency level developers interested in fostering interoperability.
    Agency level XML Schema and XML Schema components can be developed
    with an eye towards future interoperability. These would include XML
    Schema whose initial focus is limited to a specific agency, but
    whose broader use for the entire federal government is either a
    possibility or an objective.

-   Developers of Agency XML Schema and Government organizations looking
    for guidance. Agencies who are looking to avoid reinvention should
    look to adopt the Federal NDRG. Agencies are encouraged to apply
    even stricter interpretations than currently exist for rules in this
    document whose language is other than MUST. These rules are well
    suited for such an approach and will provide Agencies an out of the
    box experience for XML development that will remain at the Agency
    level.

-   Private sector organizations who wish to track or support government
    efforts. Many private sector content and application developers have
    a vested interest in following the direction of the federal
    government as a way of ensuring that their products, services, and
    related offerings support government requirements. This NDRG
    provides such direction.

## Terminology and Notation

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in Internet Engineering Task Force (IETF)
Request for Comments (RFC) 2119. Non-capitalized forms of these words
are used in the regular English sense.

This document provides both rules and general guidance for federal XML
Schema development. The term 'rule' should be understood as a
unconditional requirement in regards to inter-agency XML data exchange.
As such, this document's use of the RFC 2119 terminology applies solely
to inter-agency XML development rules.

Within the bounds of a specific agency, the reader should consider the
RFC 2119 terms as guidance so as to promote interoperability with XML
developed external to that agency.

\[Definition\] -- A formal definition of a term. Definitions are
normative.

\[Example\] -- A representation of a definition or a rule. Examples are
informative.

\[Note\] -- Explanatory information. Notes are informative.

\[RRR*n*\] - Identification of a rule that requires conformance to
ensure that an XML Schema is conformant. The value RRR is a prefix to
categorize the type of rule where the value of RRR is as defined in
Table 1 and n (1..n) indicates the sequential number of the rule within
its category. In order to ensure continuity across versions of the
specification, rule numbers that are deleted in future versions will not
be re-issued, and any new rules will be assigned the next higher
number - regardless of location in the text. Future versions will
contain an appendix that lists deleted rules and the reason for their
deletion. Only rules are normative; all other text is explanatory.

Figure 1 - Rule Prefix Token Value

  ------------------ ----------------------------------------------------
  Rule Prefix Token  Value

  ATD                Attribute Declaration

  ATN                Attribute Naming

  CDL                Code List

  CTD                ComplexType Definition

  DEN                Data Element Dictionary Entry Names and Definitions

  DOC                Documentation

  ELD                Element Declaration

  ELN                Element Naming

  GNR                General Naming

  GTD                General Type Definition

  GXS                General XML Schema

  IND                Instance Document

  MDC                Modeling Constraints

  NMC                Naming Constraints

  NMS                Namespace

  RED                Root Element Declaration

  SSM                XML Schema Structure Modularity

  STD                SimpleType Definition

  STR                Standards Requirements

  VER                Versioning
  ------------------ ----------------------------------------------------

Bold - The bolding of words is used to represent example names or parts
of names taken from the library.

Courier -- All words appearing in courier font are values, objects, and
keywords.

*Italics* -- All words appearing in italics, when not titles or used for
emphasis, are special terms defined in Appendix A.

The terms "W3C XML Schema" and "XSD" are used throughout this document.
They are considered synonymous; both refer to XML Schemas that conform
to Parts 1 and 2 of the World Wide Web Consortium (W3C) *XML Schema
Definition Language* (XSD) Recommendations. See Appendix A for
additional term definitions.

This document will refer to "W3C XML Schema" and "XSD" as "XML Schema"
(case sensitivity being applicable). The Federal Enterprise Architecture
Glossary of Terms[^1] defines XML Schema as follows:

An XML Schema is a description of a type of XML document, typically
expressed in terms of constraints on the structure and content of
documents of that type, above and beyond the basic syntax constraints
imposed by XML itself. An XML Schema provides a view of the document
type at a relatively high level of abstraction.

## Conformance to PL 104-113 and OMB A119

Public Law 104-113 requires the use of voluntary consensus standards
(VCS) where appropriate rather than development of government
proprietary standards.[^2] In XML terms, this means that using existing
xml technical and business standards should take precedence over
developing federal or agency standards.

Office of Management and Budget (OMB) Policy Circular A-119 authorizes
Agencies to expend funds in support of participating in the development
of standards. This is important as government participation is critical
in ensuring that government requirements are included in VCS
standards.[^3]

To help guide conformance with the statute and policy, the following
hierarchy of standards is to be used by Departments and Agencies
(highest to lowest):

\[ED. NOTE: PER 9/12/2005 Meeting "All XML components SHOULD be, at a
minimum, at the enterprise level - agency."

\[ED. NOTE: PER 9/12/2005 Meeting "Should give an example for each one.
Make sure that examples are not an endorsement."

\[ED. NOTE: PER 9/12/2005 Meeting "Make sure it is clear that hierarchy
is dependent on a level meeting business requirements. If not, provide
examples of how this is addressed."

\[ED. NOTE: PER 9/12/2005 Meeting "Talk about requirements to promote to
federal wherever possible"

STR1 To ensure conformance with both statutory and policy requirements
contained in Public Law 104-113 and Office of Management and Budget
Circular A-119, all Federal XML implementations SHOULD adhere to the
following hierarchy of standards in creating and using XML (VCS means
Voluntary Consensus Standards). When attempting to identify candidate
XML standards for use, XML analysts SHOULD refer those initiatives
according to the following order of priority:

\* De jure VCS

\* Horizontal VCS

\* Vertical VCS

\* Federal Enterprise Wide Standards

\* Agency specific standards

\[ED. NOTE: Per the 8/11/2005 meeting "Recommend additional explanation
for the hierarchy at top of p.1-9. For example, what is a \"de jure\"
VCS? What are \"cross-sector\" and \"sector-specific\" VCSs? Examples of
each level would also help"\]

Example of the VCS standards cited above are as follows:

-   De jure VCS -- Examples of these standards include the International
    Organization for Standardization (ISO), the International
    Electrotechnical Commission (IEC), the United Nations Economic
    Commission for Europe (UNECE), and the International
    Telecommunication Union (ITU).

-   Horizontal VCS -- Examples of these standards include the American
    National Standards Institute (ANSI), and United Nations Centre for
    Trade Facilitation and Electronic Business (UN/CEFACT).

-   Vertical VCS -- Examples of these standards include the Open Travel
    Alliance (OTA), the Petroleum Industry Data Exchange (PIDX), and the
    Extensible Business Reporting Language (XBRL).

-   Agency Specific Standards -- Examples of these standards include
    EPA's Core Reference Model, and Global Justice XML.

-   De facto --

Agencies are encouraged to address XML at an enterprise level.

SR2 Agencies SHOULD create Agency level policy, procedures and guidance
to ensure XML is developed and governed at an enterprise level

As Agencies move forward with enterprise level approaches to XML, Agency
level XML components -- elements, complex types, and XML Schema will
begin to emerge. These components provide significant wealth to the
federal government as a whole and should be made available for reuse.
The best way to make this happen is for Agencies to promote their XML
components as candidate Federal components, and to appropriate Voluntary
Consensus Standards bodies.

STR3 Agencies SHOULD promote Agency level XML components to candidate
federal level components and candidate Voluntary Consensus Standards
Bodies

\[ED. NOTE: Per the 8/11/2005 meeting "Recommend striking these rules,
as they are out of scope of naming & design rules. They address policy
and operational aspects"\]

### W3C Recommendations

In keeping with the basic tenants of PL 104-113 and OMB A-119, Federal
XML will be based on recognized standards rather than developing
proprietary standards. Standards promulgated by nationally or
internationally accredited standards bodies (such as ISO, IEEE, ANSI,
UN/CEFACT, etc.) should always be adhered to when developing
applications within the domain that the standard addresses. The only
exception to this is when a standard produced by one of these bodies
competes with a similar product of the W3C. In this case, only, the W3C
should have precedence. Although competing standards exist in the XML
space, the World Wide Web Consortium is the only International Standards
organization that is committed to ensuring end-to-end interoperability
of its suite of XML standards. The W3C standards are recognized
throughout the world as the authoritative set of XML standards, and the
vast majority of developers use W3C standards rather than those of other
competing bodies. Accordingly, Federal XML will be primarily based on
the W3C suite of XML standards.

\[STA1\] All XML Schemas MUST be conformant to the W3C XML Schema
Recommendations: XML Schema Part 1: Structures and XML Schema Part 2:
Datatypes.

In general, production applications should only use software that
implements [W3C](#W3C) Final [Recommendations](#Recommendation) and
final specifications of the accredited standards bodies referenced in
the above paragraph.

\[STA2\] All XML Schema MUST be based on the W3C suite of technical
specifications holding recommendation status.

Applications using software that implements [W3C technical
reports](../w.w3.org/TR/) at other stages of the development process, or
other draft products of Voluntary Consensus Standards bodies, should
only do so with the following restrictions:

-   Production Applications:

```{=html}
<!-- -->
```
-   Prior to creating, incorporating or using software that implements
    non-W3C specifications, activities MUST:

```{=html}
<!-- -->
```
-   Ensure that no competing W3C endorsed recommendation exists or is
    being developed.

-   Ensure that the specification is a product of an accredited
    standards body (ISO, IEEE, ANSI, UN/CEFACT) or a credible Voluntary
    Consensus Standards body such as the Organization for the
    Advancement of Structured Information Standards (OASIS), the OMG,
    OAG, UDDI, RosettaNet, or BizTalk.

```{=html}
<!-- -->
```
-   Pilot Applications: Activities developing pilot applications (as a
    precursor to production) MAY also implement software that conforms
    to W3C technical reports with a Candidate Recommendation status.

-   (Advanced Concept) Demonstrations: Activities developing
    demonstration applications (as a proof of concept) MAY also
    implement software that conforms to W3C technical reports with a
    Working Draft status or another accredited standards body or
    Voluntary Consensus Standards body's draft specifications.

Proprietary extensions to W3C Technical Specifications or other
technical specifications by accredited standards bodies should not be
employed in any software or XML document (instance, XML Schema,
stylesheet) that will be shared publicly with activities outside a
particular development environment.

\[STA3\] Proprietary extensions to the W3C specifications MUST never be
used.

To ensure that XML content provided by other standards groups is used
appropriately, agencies should defer to the conformance, compliance, or
certification clauses issued by those organizations.

## Guiding Principles

Federal XML guiding principles encompass three areas:

-   General guiding principles

-   Extensibility

-   Code generation

### General Guiding Principles

Tool Use and Support -- The design of Federal XML will not make any
assumptions about sophisticated tools for creation, management, storage,
or presentation being available, nor levy any government unique
requirements that would necessitate tool vendors developing proprietary
extensions to support Federal requirements.

Legibility -- Federal XML documents should be human-readable and
reasonably clear.

Simplicity -- Federal XML content developers should strive to design XML
Schemas in such a way as to keep them as simple as possible to meet the
requirements at hand.

Component Reuse -- Federal XML Schema should make use of the principle
of reuse which has been proven as a successful design strategy within
the software industry.

Standardization -- The number of ways to express the same information in
a Federal XML instance is to be kept as close to one as possible.

Prescriptiveness -- Federal XML Schema design will balance
prescriptiveness in any single usage scenario with prescriptiveness
across the breadth of usage scenarios supported. Having precise, tight
content models and Datatypes is a good thing.

XML Technology -- Federal XML Schema design will avail itself of
standard XML processing technology wherever possible (XML itself, XML
Schema, XSLT, XPath, and so on). Federal XML implementations will be
cautious about basing decisions on "standards" (foundational or
vocabulary) that are works in progress.

Legacy formats -- Federal XML Schema design is not responsible for
catering to legacy formats or syntax.

### Design For Extensibility

Many eBusiness documents are, broadly speaking, useful but require minor
structural modifications for specific tasks or industries. When a truly
common XML structure is to be established for eBusiness, it needs to be
easy and inexpensive to modify.

Many data structures used in eBusiness are very similar to "standard"
data structures, but have some significant semantic difference native to
a particular industry or process. In traditional Electronic Data
Interchange (EDI), there has been a gradual increase in the number of
published components to accommodate market-specific variations. Handling
these variations are a requirement, and one that is not easy to meet. A
related EDI phenomenon is the overloading of the meaning and use of
existing elements, which greatly complicates interoperation.

To avoid the high degree of cross-application coordination required to
handle structural variations common to EDI and XML Document Type
Definition (DTD) based systems - it is necessary to accommodate the
required variations in basic data structures without either overloading
the meaning and use of existing data elements, or requiring wholesale
addition of new data elements. This can be accomplished by allowing
implementers to specify new element types that inherit the properties of
existing elements, and to also specify exactly the structural and data
content of the modifications.

This can be expressed by saying that extensions of core elements are
driven by context.[^4] Context driven extensions should be renamed to
distinguish them from their parents, and designed so that only the new
elements require new processing. Similarly, data structures should be
designed so that processes can be easily engineered to ignore additions
that are not needed.

### Data versus Document Centric XML

This document provides rules and guidance from the perspective that XML
applications fall into two distinct types: data-centric and
document-centric. The paragraphs below provides an overview of each of
these types but, as stated in section 1.2 of this document all rules and
guidance contained herein pertain only to data-centric applications of
XML. Document-centric XML is not within the scope of this document.

Data-centric XML is used to manage the exchange of structured data
between software applications. A common scenario for using data-centric
XML is the exchange of data between a buyer and a supplier.

In contrast, document-centric XML is used to present formatted content
(typically unstructured) for human consumption or viewing. A common
scenario for using document-centric XML is the formatting of textual
information for presentation on a web page or some other media.

As is stated in the "XML Design Rules and Conventions for the
Environmental Information Exchange Network: Section 2. Schema Design
Rules" document which was published by the EPA, data-centric XML can be
understood as follows:

Developers use data-centric XML for the structured electronic exchange
of data across the Internet (for example, when information is sent from
one database to another or when a person inputs data into a web form and
submits the data to a database). Data-centric XML focuses on data types
and, therefore, must be more rigid than document-centric XML. Usually,
in data-centric XML, the XML instance generates automatically based on
an XML schema and input into a back-end database without human
intervention.

The following are characteristics of data-centric XML:

-   Has granular detail (numerous tags)

-   Has nonvariable structure

-   Is machine generated

That document describes data-centric XML as follows:

Document-centric XML is used primarily for presentations and often
contains graphics. Document-centric XML is far less rigid than
data-centric XML, and typically defines the structure at a higher level.
In document-centric XML, an author creates the XML instance based on an
XML schema, which is combined with a stylesheet that renders the
information in a specified format.

The following are characteristics of document-centric XML:

-   Has broad detail (few tags)

-   Has free-form structure

-   Is human generated (using XML authoring tools

### Code Generation

This NDR document makes no assumptions on the availability or
capabilities of tools to generate Federal conformant XSD XML Schemas.
The Federal NDR design process has scrupulously avoided establishing any
naming or design rules that sub-optimizes the XSD in favor of tool
generation. Conformance to W3C technical specifications holding
recommended status ensures that no preference is given to particular
implementation approaches or tools in generating XML.

## Document Organization

This Federal Naming and Design Rules document is organized as follows:

\[ED. NOTE: Per 9/12/2005 meeting "need to have a paragraph in terms of
governance for this document and governance in terms of standards\]

\[ED. NOTE: Per 9/12/2005 meeting "where security is not an issue then
components need to be visible"\]

# Information Analysis

XML Schemas provide a mechanism with which trading partners can control
data exchanges with one another. XML Schemas are expressed in XML syntax
and, therefore, exhibit characteristics specific to the XML language.
Through this XML

This document will provide a high-level introduction to the topic of
information analysis and its relevance to XML Scheme design and
development. For those readers who wish to delve more thoroughly into
this topic, numerous articles have been written that provide an in-depth
stufdy of this topic. One such article is found on XML.com and describes
analysis and design techniques (in 3 parts) by which UML model scan be
translated into XML Schema models.[^5]

## Defining Data

Sound XML Schema design, especially for XML Schema supporting data
centric XML exchanges, must have a solid foundation in sound data
models. Commonality in data modelling, and by extension process
modelling, enables the expression of XML Schema naming and design rules
in a consistent fashion.

Hitrorically, data Models have been typically expressed in terms of
Entity Relationship Diagrams or Data Classification Structures (one
example being UML Class Diagrams). As shown in Figure 2-1, these two
modelling systems share common concepts. Within the Both entities and
objects represent discrete things. Both entities and objects have data
element concepts that identify that portion of a data element that is
independent of any particular data typing or representation. Both
entities and objects have simple data elements, that part of a data
element that describes its characteristic. The fundamental difference is
that entities only define the data, whereas class diagrams define both
the data and its behavior.

Figure 2-1. Data Structures

![](media/image1.wmf)

In an entity relationship data model, each entity may have multiple
attributes. In a class based data model, each Class may have multiple
properties. The element that represents an Entity with all of its
attributes, or a class with all of its properties is an aggregation
(complex) data element. Complex data elements can have varying contents
depending on the way in which it is being used. Data elements that
represent an attribute of an entity, or a property plus representation
of a type, represent simple (generic) data elements. Simple data
elements are reusable across multiple entities/classes.

## Defining Relationships

Complex data elements may use other complex data elements as one of
their properties. For example, a *Person* complex data element may use a
*Address* complex data element. In this relationship*, Person* has an
association with *Address*. *Person* is said to inherit the properties
of *Address*.

In a UML diagram, such as figure 2-2, a physical connection is made
between the classes and the nature of that relationship is expressed as
a word or words that reflect the role of the associated class as the
property of the associating class. Figure 2-3 indicates that the
association between Person and Address is Mailing Address.

Figure 2-2 Class Association in UML

![](media/image2.wmf)

In a semantic diagram, such as figure 2-4, the properties of the
associated class represented by the complex data element *Mailing* are
represented as a single property in the associating class *Person as
Person. Mailing. Addess.*.

Figure 2-3 Class Association in Semantic Diagram

![](media/image3.wmf)

## Transforming Data into XML

Entity relationship diagrams, object class models, and semantic diagrams
express conceptual data models that enable transforming their data
constructs into consistent, sound XSD artifacts. As shown in Figure 2-4,
the complex data elements that represent entities or object classes can
be expressed as global elements and named complex types. Attributes and
properties that represent simple data element properties can also be
expressed as global elements and complex types. Representation terms as
the expression of the data type, can be expressed as either complex or
simple types depending on their usage requirements.

Figure 2-4. Transforming Data constructs into XML Artifacts

![](media/image1.wmf)

Beyond the expression of simple and complex data elements, agencies must
also accommodate the relationships (associations) between classes. This
is accomplished by declaring distinct global elements which represent
the association of 2 or more object classes. These association objects
then become object classes in their own right and become integral to the
semantic model outlined in Figure 2-4 . Within that semantic model,
association objects would fall within the catrgory 'object class' and,
as such, would be understood as complex type structures within an XML
Schema.

The concept of an association object is similar

# General XML Constructs

## Overall XML Schema Structure

Consistency in development of XML Schema includes consistency in the
appearance and overall structure of each XML Schema. By defining a
canonical form for Federal XML Schema files, agency XML Schema will all
have a consistent look and feel, which should reduce development effort
and costs.

\[GXS1\] Federal Level Data-centric XML Schema SHOULD conform to the
following physical layout as applicable:

XML Declaration

\<!\-- ===== xsd:XML Schema Element With Namespaces Declarations =====
\--\>

xsd:XML Schema element to include version attribute and namespace
declarations in the following order:

xmlns:xsd

Target namespace

Default namespace

CommonComplexElements

CommonSimpleElements

Datatypes

Identifier Schemes

Code Lists

Attribute Declarations -- elementFormDefault="qualified"
attributeFormDefault="unqualified"

\<!\-- ===== Imports ===== \--\>

CommonComplexElements XML Schema module(s)

CommonSimpleElements XML Schema module(s)

Unqualified Datatypes XML Schema module(s)

Qualified Datatypes XML Schema module(s)

Code and Identifier List XML Schema module(s)

\<!\-- ===== Global Attributes ===== \--\>

Global Attributes and Attribute Groups

\<!\-- ===== Root Element ===== \--\>

Root Element Declaration

Root Element Type Definition

\<!\-- ===== Element Declarations ===== \--\>

alphabetized order

\<!\-- ===== Type Definitions ===== \--\>

All type definitions segregated by simple and complex as follows

\<!\-- ===== Complex Data Element Type Definitions ===== \--\>

alphabetized order of Complex Data Element xsd:complexType definitions

\<!\-- =====Simple Data Element Type Definitions ===== \--\>

alphabetized order of simple data element xsd:complexType definitions

While agencies should strive to include as much of this information as
possible, it is understood that this list may not be fully represented
in all circumstances. Federal XML Schema developers should include as
much of this information as is appropriate for their respective
situation. Doing so will promote consistency throughout the federal XML
Schema portfolio.

The following list provides a description of each of the content models
outlined in rule GXS1 (above):

-   Target namespace: The target namespace specifies the namespace to
    which all content defined within the Schema file. For a more
    complete description of the concept of namespaces see references
    (tbd).

-   Default namespace: The default namespace specifies the namespace to
    which all content defined within a Schema belongs to, unless
    specified otherwise.

-   CommonComplexElements: These elements contain data structures that
    are complex in nature. Typically, such elements will contain
    attributes or other, nested elements. The data types of these
    elements should be defined in the appropriate common themselves An
    example of such an element is listed in figure \-\--.

[]{.mark}

[\<xs:element name=\"Person\" type=\"PersonType\"/\>]{.mark}

[\...]{.mark}

[\<xs:complexType name=\"PersonType\"\>]{.mark}

[\<xs:sequence\>]{.mark}

[\<xs:element name=\"FirstName\" type=\"xs:string\"/\>]{.mark}

[\<xs:element name=\"MiddleName\" type=\"xs:string\"/\>]{.mark}

[\<xs:element name=\"LastName\" type=\"xs:string\"/\>]{.mark}

[\</xs:sequence\>]{.mark}

> [\</xs:complexType\>]{.mark}

-   CommonSimpleElements: These elements contain data structures that
    are simple in nature. Typically, such elements will contain simple
    textual or numeric data. An example of such an element is listed in
    figure \-\--

[\<xs:element name=\"PersonName\" type=\"xs:string\"/\>]{.mark}

### Root Element

XML 1.0 describes the concept of a root element that serves as the
anchor for an XML instance. Specifically, XML 1.0 states "There is
exactly one element, called the root, or document element, no part of
which appears in the content of any other element." The root element has
many uses.

Any global element can function as the instance root element. Since
Federal XML Schemas will have all elements declared globally, this has
the potential to cause confusion within the developer and user
community. Accordingly, Federal XML Schema will identify one global
element as the root element for a particular instance. This will be
accomplished through an xsd:annotation child element for that element in
accordance with the following rule:

\[ELD1\] Each XML Schema MUST identify one and only one global element
declaration that defines the document level container being conveyed in
the XML Schema expression. That global element MUST include an
xsd:annotation child element which MUST further contain an
xsd:documentation child element that declares \"*This element MUST be
conveyed as the root element in any instance document based on this XML
Schema expression.*\"

## Constraints

### Naming Constraints

Since each federal XML Schema represents a collection of data derived
from a syntax-neutral library, it is critical that each content model
contained within federal XML Schemas can be traced back to its
syntax-neutral counterpart. Assuming globally defined content (as put
forth in section 3.3 of this document), data types and elements may be
reused within each federal XML Schema.

While reuse of XML content is beneficial, each element or attribute
within a federal XML Schema must refer to a globally unique path within
the federal component library. This provides a mechanism by which each
piece of XML content can be identified according to its clear semantic
definition.

See section \-\-- for guidance on how to construct dictionary entry
names.

\[ED note: This rule should be discussed in regards to its reference to
a single federal dictionary from which all XML Schema content is
'derived'.

\[NMC1\] Each dictionary entry name MUST define one and only one fully
qualified path (FQP) for an element or attribute.

### Modeling Constraints

The goal of this document is to disambiguate information references
within federal XML documents. This is done by promoting use of a common
set of data and a consistent method for naming that data.

In support of this goal agencies should, when possible, use only those
data elements that have undergone the requisite approval process. These
approval processes should apply to agency-specific content as well as
content meant to be consumed by the federal community as a whole. When
it is not possible for an agency to use content from the library of
approved content at the agency level or at the federal level, that
agency may choose to develop their own content for use in the short-term
while also submitting that content for formal approval at the
appropriate level.

This document assumes that a central, governing body will control the
definition of federal XML content (i.e., semantic definitions, names,
etc.) at the agency specific level as well as the federal level. The
policies and procedures surrounding such controls is not within the
scope of this document.

\[MDC1\] Libraries and XML Schemas MUST only use approved datatypes.

Predominantly, data contained within federal XML Schema provides a
structured rendition of data. The makeup of each data type is
discernable clearly and data is structured into its component parts. XML
Schemas that follow this design philosophy are known as data-centric XML
Schemas.

In certain cases, an agency may need to include unstructured, textual
data within a data-centric XML Schema (for any number of reasons). In
such cases, an XML instance document would contain both data that is
well-structured by its enclosing elements and attributes as well as data
that is free flowing text. When an agency requires this mixed content
model, each XML Schema should contain documentation that denotes the
unstructured nature of that XML Schema content.

\[MDC2\] Mixed content MUST NOT be used in data centric XML Schema
except where contained in an xsd:documentation element.

It is important to note that this mixed-content scenario is not
equivalent with the document-centric XML Schema style describes earlier
in this document.

Figure \-\-- illustrates how such mixed content should appear within an
XML Schema.

Figure \-\--

[\<xsd:complexType name=\"ExampleType\"\>]{.mark}

[\<xsd:annotation\>]{.mark}

[\<xsd:documentation xml:lang=\"en\"\>This is sample text that depicts
how textual content should appear within a data-centric XML
Schema.]{.mark}

[\</xsd:documentation\>]{.mark}

[\</xsd:annotation\>]{.mark}

> [\...]{.mark}

In this example, explanatory text is included in the XML Schema
documentation, but it does not impact the interpretation of the XML
Schemas structured data by a validating parser.

## Reusability Scheme

\[ELD2\] All data-centric element declarations MUST be global. All
document-centric element declarations SHOULD be global.

The XML Schema language was designed to be flexible and to support
myriad methods for defining XML data structures. While this flexibility
is beneficial in many ways, it presents the need to decide on a common
design approach within a community of trading partners.

Defining each XML Schema element at a global level will ensure that XML
Schema content is unique.

As a side note, federal XML and software developers should be aware that
gloal element definitions within XML Schema may have an impact on the
design of application softwar. Appendix \-\-- provides references
regarding this topic.

\[ED note: LMI is presenting materials on this topic at XML 2005.
References may be made as appropriate.

## Namespace Scheme

Federal agencies should make use of the namespace mechanisms inherent to
the XML Schema language. Numerous XML Schema design alternatives are
available to Federal agencies with regards to namespaces. Each XML
Schema can define its content in zero or one target namespace and
decisions made at this level will have a significant impact on how XML
Schema are to be developed, maintained, governed, and used within
software applications.

Given that there are many options regarding namespace modularity, it is
critical that each agency develop its XML vocabulary within a set of
namespace that is designed to be managed in coordination with the
larger, federal XML vocabulary.

The following sections provide rules and guidelines that will position
an agency to harmonize its XML vocabulary(s) with other agencies while
maximising the chances to reuse existing content, and thereby lowering
development costs.

### Declaring Namespaces

The configuration of XML Schema namespaces is tied directly to the
concept of XML Schema modularity, which is outlined in section 3.6.2 of
this document. The rules below deal specifically with namespace
declaration, but readers should understand these rules within the larger
context of XML Schema modularity. A description of 'internal' and
'external' XML Schema modules can be found in section 3.6.2.

Each root and external XML Schema should declare a globally unique
target namespace. Adherence to this rule will ensure that XML Schemas
are developed consistently and that the content within each XML Schema
is unique throughout the federal XML Schema library.

This rule applies to ALL federal XML Schemas with the exception of
internal XML Schema modules. Those internal XML Schema modules do not
explicity define a target namespace. Since their content is defined in
no namespace, however, all content they contain are 'coerced' into the
root XML Schema that includes those internal XML Schemas.

\[NMS1\] Every XML Schema module, except internal XML Schema modules,
MUST have a namespace declared using the xsd:targetNamespace attribute.

Figure \-\-- provides an example of how this declaration would appear in
an XML Schema file:

Figure \-\--

[\<?xml version=\"1.0\" encoding=\"UTF-8\"?\>]{.mark}

[\<xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\
targetNamespace=\"urn:us:com:supplyinventory:inventorydepartment:1:0\"
xmlns=\"urn:us:\-\-\--:1:0\"\
xmlns:cac=\"urn:us:\-\--:commonaggregatecomponents\"
elementFormDefault=\"qualified\" attributeFormDefault=\"unqualified\"
version=\"1:0\"\>]{.mark}

Each XML Schema major version MUST be declared in its own unique
namespace.

\[NMS2\] Every defined or used XML Schema set version MUST have its own
unique namespace

Since the function of a target namespace is to define ownership of the
content defined in the pertinent XML Schema(s), it is critical that each
federal namespace contain only content that has been developed by a
federal agency. Use of any non-federal, external XML content would
misrepresent content ownership by changing the namespace associated with
external content to a federal namespace.

A 'federal namespace' should be understood as one that has undergone the
requisite review, approval, and registration processes. As stated
earlier in this document, such governance activities are out of scope of
this document.

\[NMS3\] Federal Namespaces MUST only contain federally developed XML
Schema modules

Once published as standard, the contents of a federal XML namespace must
not be modified. If the assumption is that this rule applies only to
major version changes, then explanatory text may begin as follows: "Once
published as a standard, the contents of a federal XML namespace (as
contained in one or more XML Schema files) must not be modified to break
compatibility with previous minor versions."

\[NMS7\] Published namespaces MUST never be changed.

\[ED. NOTE: Per the 9/12/2005 meeting "need to look at the should
requirement"\] -- Per 11/10/2005 see explanatory text added to section
3.5.3

\[ED. NOTE: Per the 9/12/2005 meeting "need to clarify what is defined
as a "minor" version. Also need to differentiate between versioning of
XML Schemas and versioning of XML Schema namespace"\] -- Per 11/10/2005
see explanatory text added to section 3.5

\[ED. NOTE: Per the 8/11/2005 meeting "recommend the URN and provide
consistent approach to either namespace approach"\] -- Per 11/10/2005
see explanatory text added to section 3.4.2

\[ED. NOTE: Per the 8/11/2005 meeting "need another separator for
parsing variable sub-domains\] \--

\[ED. NOTE: Per the 8/11/2005 meeting "recommend avoid using a period
since it is commonly used for programming purposes"\]

### Namespace Uniform Resource Indicators

To support namespace uniqueness and modularity, each federal namespace
should be defined using a consistent syntax. URL and URN syntax are
prevalent options for defining namespaces. Federal agencies should
create XML Schema namespace URI's in a way that is consistent with the
larger, federal library of XML Schemas.

Agencies should consider both options according to the following
criteria that characterize the purpose of an XML Schema namespace using
URI syntax:

-   Persistence---Each namespace should be persistent and global within
    the federal XML community. As stated earlier, this document does not
    specify and rules or guidelines that control issues associated with
    governance or policies.

-   Ease of understanding---The ability for XML authors and general
    users to grasp the concept of a namespace. URL's are familiar to
    most members of the XML Schema 'audience'. URN's are not. Depending
    on perspective, this can be seen as an advantage or a disadvantage.

-   Syntactic Rigorousness---The syntax used to express the XML Schema
    namespace should provide an unambiguous way to specify a full URI.

-   Reference to external documents---In some cases, URL namespaces may
    reference a site (via the URL) that contains documents and/or
    materials related to the messages that conform to the relevant
    Schema.

Based on these discreet criteria, the following statements about URN and
URL syntax can be considered in light of these criteria (to be
defined...)

For some federal XML analysts, however, URL,s may prove to be more
intuitive and simpler to use. Regardless of which syntax is chosen, it
is critical that a consistent approach be defined, adopted, and enforced
throughout the agency.

Agencies can refer to the Federal Namespaces paper[^6] for guidance on
namespace creation. Each federal namespace should consider including the
following structural components:

-   1st Level Domain -- NID of US

-   2nd Level Domain -- Organization hierarchy. In this case, 'gov'.

-   3rd Level Domain -- Specific Government Hierarchy -- EPA, OMB, DoD,
    Treasury

-   4th Level Domain -- Agency Level Hierarchy -- USN, USAF, IRS, FMS

-   5th Level Domain -- Resource Type -- XML Schema or Other as
    Identified

-   6th Level Domain -- Resource Status

-   7th Level Domain -- Resource Name

-   8th Level Domain -- Versioning

    From the list above, it's critical to note that the eighth level
    domain component is applicable for major versions only. As noted in
    section 3.5 of this document, minor versions are denoted by the
    document 'id' attribute rather than the target namespace.

    Figure \-\-- shows an example XML Schema header using the URN
    namespace syntax cited above:

Figure \-\--

[\<xsd:import namespace=
\"urn:us:gov:dod:dlis:xmlschema:draft:commonaggregatecomponents\"\
schemaLocation=\"CommonAggregateComponents.xsd\"/\>]{.mark}

Figure \-\-- shows an example XML Schema header using the URL namespace
syntax cited above:

Figure \-\--

[\<xsd:import namespace=\
\"http://us/gov/dod/dlis/xmlschema/draft/commonaggregatecomponents/1.0\"\
schemaLocation=\"SI-Enterprise-CommonAggregateComponents.xsd\"/\>]{.mark}

In order to preserve the integrity of each federal XML Schema namespace,
it is critical that the namespace contain only content developed by the
respective agency. XML Schema content developed by external entities
should be referenced via the import mechanism (see section \-\-- below).

\[NMS4\] Agency Namespaces MUST only contain agency developed XML Schema
modules

To promote consistency within the federal XML vocabulary, each draft
federal XML Schema should adhere to a common structure. Such consistency
will also ease configuration at the application software layer.

\[NMS5\] The namespace names for Federal level XML Schemas holding draft
status MUST be of the form:

urn:us:

To promote consistency within the federal XML vocabulary, each approved
federal XML Schema should adhere to a common structure. Such consistency
will also ease configuration at the application software layer.

\[NMS6\] The namespace names for Federal level XML Schemas holding
Approved status MUST be of the form:

urn:us:

## Versioning Scheme

Federal XML Schemas and the data models they contain will likely not be
static. Rather they will change and evolve over time in ways that are
trivial as well in significant. As such, it is critical that a robust
and flexible mechanism exist to record the version of each XML Schema as
it changes.

Numerous mechanisms exist to track the XML document versions. To meet
this requirement, XML Schema authors may choose to use the
targetnamespace attribute, an 'id' attribute, the file name of the XML
Schema, and so on. A detailed explanation of the various XML Schema
versioning options that exist is not part of the scope of this document.
Numerous references are available on the public Internet.

This Federal NRDG document recommends a specific XML Schema versioning
technique which makes use of the targetnamespace attribute for major
version changes and an 'id' attribute for minor version changes. For
consistency and completeness, major versions should also use the 'id'
attribute. This technique provides clear distinction across major
versions while protecting XML content from needless revision with minor
changes.

This section describes XML Schema versioning only as it is reflected in
the 'id' attribute. Section 3.6.5 (Modularity and Namespaces) describes
how federal XML Schemas capture versions n the targetnamespace.

The following sections outlines the method by which both draft and
standard XML Schemas should be versioned using the 'id' attribute.

### Draft XML Schema

Prior to publication as a federal standard, agency XML Schemas must
first be published in draft status. This document does not address draft
submission and approval procedures at the federal level.

In addition to the identification of the XML Schema major version within
the target namespace (see section 3.6.5.1 of this document), agency XML
Schemas should provide an 'id' attribute within the XML Schema header
that also contains the major version.

\[VER1\] Every federal and Agency XML Schema and XML Schema module major
version committee draft MUST have a document-id of the form

\<name\>-\<major\>.0\[.\<revision\>\]

This practice provides a consistent mechanism for both XML analysts and
software applications to determine readily a XML Schema's version.

Figure \-\-- shows how this 'id' attribute would identify a major
version:

Figure \-\-- \[ED note: XML example to be inserted\]

Similarly. agencies should identify XML Schema minor version revisions
within the same 'id' attribute within the XML Schema header. This id
attribute will identify the version that is also captured in the XML
Schemas target namespace.

\[VER3\] Every minor version XML Schema or XML Schema module draft MUST
have a document-id of the form

\<name\>-\<major \>.\<non-zero\>\[.\<revision\>\]

### Standard XML Schema

Agencies should also identify XML Schema minor version revisions within
standard XML Schemas by way of the 'id' attribute within the XML Schema
header.

\[VER2\] Every federal and Agency XML Schema and XML Schema module major
version Standard MUST have a document-id of the form

\<name\>-\<major\>.0

Agencies should also identify XML Schema major version revisions within
standard XML Schemas by way of the 'id' attribute within the XML Schema
header. This id attribute will identify the version that is also
captured in the XML Schemas target namespace.

\[VER4\] Every minor version XML Schema or XML Schema module Standard
MUST have an document-id of the form

\<name\>-\<major \>.\<non-zero\>

\[ED. NOTE: Per the 8/11/2005 meeting "agreement on rule VER4"\]

### Minor Version Changes

A minor version change is one which does NOT cause XML instances
conforming with the previous version to be invalid with the new version.
Preservation of conformance of previous XML instances to a new XML
Schema version is commonly referred to as maintaining backwards
compatibility.

\[ED. Note: The term version construct should be clarified\]

\[VER5\] For minor version changes, the name of the version construct
MUST NOT change.

\[VER9\] XML Schema and XML Schema module minor version changes MUST be
limited to the use of xsd:extension or xsd:restriction to optionally
alter existing types or add new constructs.

\[ED note: This rule should be discussed to provide a bit more clear
wording for 'optional'. That is, restrictions are allowed for minor
version changes only when they refer to content restrictions of an
optional nature. The wording above may not be clear enough about that
that.

\[VER10\] XML Schema and XML Schema module minor version changes MUST
not break semantic compatibility with prior versions.

### Versioning Numbering Scheme

By providing a clear set of guidelines regarding how to determine the
number of a XML Schema file, this document intends to promote a common
and consistent numbering scheme across all federal XML documents.

When the major version of an XML Schema needs to be changed, the new
version number should be the next sequential number. The relevant XML
Schema file(s) should be incremented accordingly.

\[VER6\] Every XML Schema and XML Schema module major version number
MUST be a sequentially assigned, incremental number greater than zero.

Just as is the case with major versions, the number associated with a
new minor version should be the next sequential number. The relevant XML
Schema file(s) should be incremented accordingly.

\[VER7\] Every XML Schema and XML Schema module minor version number
MUST be a sequentially assigned, incremental non-negative integer.

### Versioning Import Requirements

\[VER8\] A minor version document XML Schema MUST import its immediately
preceding version document XML Schema.

\[ED. NOTE: Per the 8/11/2005 meeting "need a persistent location for
versions and support documentation. They have to stay available as some
will note upgrade with changes."\]

## Modularity

Modularity refers to the organization of content within a set of XML
Schema files. As is often the case with XML, many options are available
to agencies defining a modularity model. At one end of the spectrum
might be the preference to define the entirety of an agency's XML
portfolio within the space of a single XML Schema. At the opposite end,
an agency may choose to create a distinct XML Schema file for each piece
of XML content---no matter how small. In between these two options a
variety of alternatives exist.

This document defines a clear method by which federal agencies can move
toward a consistent framework for fragmenting and arranging their XML
Schemas. This framework is known as XML Schema modularity. A robust
Federal modularity model must support the following criteria:

-   Common and Agency Unique Reusable components at the Data and
    Aggregation Levels

-   Common and Agency Unique DataTypes

-   Reusable Code and Identifier Lists

-   Reusable State and Local modules

-   Reusable External Standards Body modules

Figures 3-1 through 3-5 reflects such a model. The federal modularity
model has a highly modularized structure that promotes reuse and
standardization. The federal modularity model provides for both federal
and Agency level XML Schema modules for complex data elements, simple
data elements and datatypes; and also supports both internal and
external XML Schema modules for code lists and identifier lists.

\[ED. NOTE: Per 9/12/2005 meeting "agreement on reuse approach for the
Federal level. And have it as a SHOULD at the agency level, but can
break down them down further if circumstances dictate Will include a
warning that there are complexities in managing namespaces and
components.\]

Figure 3-1 XML Schema Modularity Model

![](media/image2.wmf)

Figure 3-1 Federal XML Schema Modularity Model

![](media/image3.wmf)

### Leveraging VCS Datatypes

At the heart of the Federal XML Schema modularity model are Voluntary
Consensus Standard datatype XML Schema that provide for consistent
expression of the most common core datatypes typically used in
information sharing. These VCS datatype XML Schema serve as the basis of
-- are imported into -- federal unqualified datatype XML Schema. These
federal unqualified datatypes have no restrictions placed on them.
Additionally, as Agencies promote their own restricted datatypes to
federal enterprise level standards, an additional federal qualified
datatype XML Schema will emerge. Both the federal unqualified and
qualified datatype XML Schema modules will serve as the basis of -- are
imported into -- Agency unique unqualified and qualified XML Schema
modules.

### XML Schema Modules

Modularity in XML Schema design promotes content reuse and eases XML
Schema library maintenance. Modules can be either unique in their
functionality, or represent aggregations of data content to facilitate
better performance or XML Schema manageability. A modularity model
provides an efficient and effective mechanism for using other XML Schema
components as needed (by either including or importing them) rather than
dealing with complex, multifaceted XML Schema.

This document provides a robust modularity model that leverages these
benefits.

Root XML Schemas contain the data structure(s) specific to a particular
business information exchange and are limited to defining a single root
element and its associated complex type that fully describes that
exchange. The complex type within the root XML Schema must reference
other data structures by including or importing them (via the
xsd:include or xsd:import mechanism).

\[SSM1\] Root XML Schema expressions MAY be split into multiple XML
Schema modules.

Figure \-\-- shows how the header for a root XML Schema would typically
appear.

Figure \-\--

By definition, a root XML Schema requires visibility to content defined
in some other XML Schema. That XML Schema may, in turn import another,
and so on. The root XML Schema, however, must only import the 'lowest'
level XML Schema. That XML Schema will ensure that all required content
is made available (vie the import mechanism).

\[ED note: The group may want to consider changing the 'root' reference
since what is being referenced is the conceptual root of a higher-level
tree--- not a true root level XML Schema as defined by this document.
See the tentative reference to 'first-level' (below).

\[SSM2\] A root XML Schema in one namespace that is dependent upon type
definitions or element declarations defined in another namespace MUST
only import the root XML Schema from that namespace.

XML Schema modules used by the root XML Schema need to be treated as
modules so that appropriate namespace decisions can be made. Rules in
the sections below provide guidance for how to design those modules used
by the root XML Schema.

Figure 3-1 (above) illustrates that, from the perspective of each root
XML Schema, all other XML Schemas are to be treated as either internal
or external. Internal XML Schemas should be included and external
Schemas should be imported.

This rule is meant simply to further refine the concept that root XML
Schemas are central to the notion of a specific step of a business
process that is being modelled. All other Schema content, whether it be
XML Schema that are internal or external to the root, are ancillary to
that specific step in a process flow.

\[SSM5\] XML Schema modules MUST either be treated as external XML
Schema modules or as internal XML Schema modules of the root XML Schema.

#### Internal XML Schema Modules

If a root XML Schema needs additional complex types beyond those
available in the reusable XML Schema module(s), then those data types
must be defined in what is referred to as an internal XML Schema module.
Content defined in these XML Schemas should be defined in the same
namespace as the XML Schemas that are meant to use them. These XML
Schemas are referred to as internal since their content is meant to be
internalized by agency-specific root XML Schemas.

As such, each internal XML Schema module houses ancillary content for
use by a root XML Schema (for whatever reason).

The XML Schema modularity model defined in this document ensures that
logical associations exist between root and internal XML Schema modules
and that individual modules can be reused as necessary.

\[SSM6\] All internal XML Schema modules MUST be in the same namespace
as their corresponding root XML Schema.

Internal XML Schema content should be defined in the same namespace as
their including root XML Schema. Since the Internal XML Schema reside in
the same namespace as the root, the root XML Schema must use the
xsd:include mechanism to incorporate these internal modules.

It is important that a consistent file naming convention be applied to
internal XML Schema modules. Adherence to a common convention will
promote clarity of file contents and will simplify development efforts
by reducing efforts to locate needed files.

\[SSM7\] Each internal XML Schema module MUST be named {ParentXML
SchemaModuleName}{InternalXML SchemaModuleFunction}{XML Schema module}

To clarify the rules above that define the need for consistency between
root and internal XML Schemas---from a namespace as well as a file
naming perspective, figure \-\-- illustrates how an this would appear
within an XML Schema header:

[\<?xml version=\"1.0\" encoding=\"UTF-8\"?\>\
\<xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\
targetNamespace=\"urn:us:dod:dlis:\-\--:\-\--:1.0\"\
xmlns=\"urn:us:\-\--:1.0\"\
xmlns:cac=\"urn:us:\-\--:commonaggregatecomponents\"\
elementFormDefault=\"qualified\" attributeFormDefault=\"unqualified\"\
version=\"1.0\"\>]{.mark}

### Federal External XML Schema Modules

#### Complex Data Element XML Schema Modules

As noted earlier in this document, XML Schema modularity encourages XML
content reuse (in addition to other benefits) throughout a library of
XML Schemas. This reuse is enabled by the separation of certain XML
Schema content into a XML Schema whos content should be available for
use across a broader base of XML Schemas. The chief criteria by which
federal XML Schemas should identify such content is the likelihood that
other agency root XML Schemas will require such content. If, for
example, a content model called 'AddressType' will likely to be needed
by numerous agency XML Schemas, it makes good sense to move this data
type into a widely available type library.

Accordingly, federal agencies should coordinate their XML Schema
definition activities to work toward the creation of a common federal
library of complex data types. These common data types will then be
available for use throughout the broader agency community. These data
types should be referenced from an XML Schema that contains all global
elements available for use throughout the government,

\[SSM8\] A XML Schema module defining all Federal Common Complex Data
Elements MUST be created.

To promote awareness of this common XML Schema complex types, the
federal community should assign the XML Schema an intuitive name that
will make it easy for authors and developers to find and reuse the XML
Schema and its content.

\[SSM9\] The Federal Common Complex Data Elements XML Schema module MUST
be named \"fed:Common Complex Data Elements XML Schema Module\"

#### Common Simple Data Elements 

Just as it is beneficial for federal common complex data types to be
apportioned to their own XML Schema, so to it effective for common
simple data types to reside in their own XML Schema. These simple data
types will be available for use by cmmon complex data types as well as
elements defined within agency root XML Schemas.

\[SSM10\] A XML Schema module defining all Federal Common Simple Data
Elements MUST be created.

To promote awareness of this common simple types XML Schema, the federal
community should assign the XML Schema an intuitive name that will make
it easy for authors and developers to find and reuse the XML Schema and
its content.

\[SSM11\] The Federal Common Simple Data Elements XML Schema module MUST
be named \"fed:CommonSimpleDataElements XML Schema Module\"

#### Unqualified Datatypes

In almost any modern software system, discreet data types such as
amount, measure, quantity, and text provide the basic building blocks
from which more complex data structures are developed. The XML Schema
language provides numerous native data types for this purpose but in
common data exchange scenarios, additional data attributes are needed.

For instance, data models commonly require an amount type which might
include a monetary amount and a currency code. The XML Schema language
does not provide this as a built-in 'amount' data type. So, a common
federal amount data type could extend the built-in decimal data type and
add a currency code attribute. Since the data type extends decimal, any
element using this type could provide a numeric monetary value.

It will be beneficial for federal agencies to create a common XML Schema
module that defines these frequently used data types. Since these data
types are generic and do not specify any exceptional extensions or
restrictions to the built-in XML Schema data types they are referred to
as 'unqualified'. Section 3.6.3.4 of this document defines the concept
of a qualified data type.

\[SSM12\] A XML Schema module defining all Federal Unqualified Datatypes
MUST be created.

To promote awareness of this common unqualified data types XML Schema,
the federal community should assign the XML Schema an intuitive name
that will make it easy for authors and developers to find and reuse the
XML Schema and its content.

\[SSM13\] The Federal Unqualified Datatype XML Schema module MUST be
named \"fed:Unqualified Datatype XML Schema Module\"

#### Qualified Datatypes

\[ED note: This rule should be discussed regarding its clear reference
to the Core Component data modeling concept of a Qualified Datatype
(QDT). It is critical that a common understanding of what a QDT is, in
the context of the federal NDRG, be established.

As noted above, agencies share the need to access data types that
provide useful additions to the built-in XML Schema types. These are
known as unqualified data types. However, when specializations to the
federal qualified data types are needed, agencies will need to create a
commonly available set of data types that provide further restrictions
to the unqualified data types. The new data types resulting from such
restrictions should be referred to as qualified data types.

\[SSM14\] A XML Schema module defining all Federal Qualified Datatypes
MUST be created.

To promote awareness of this common qualified data types XML Schema, the
federal community should assign the XML Schema an intuitive name that
will make it easy for authors and developers to find and reuse the XML
Schema and its content.

\[SSM15\] The Federal Qualified Datatypes XML Schema module MUST be
named \"fed:Qualified Datatypes XML Schema module\"

### Department and Agency Modularity Options

Each agency is given a great deal of flexibility in their own XML Schema
modularity approaches. An agency may choose to simply promote all XML
Schema artifacts to federal level for inclusion in the appropriate
federal XML Schema. Or it may opt to create agency-specific XML Schema
modules for complex data elements and simple data elements that apply to
that agency's problem space.

Agencies may choose to create a XML Schema module for each individual
XSD artifact. They must however ensure that they do not reinvent
existing artifacts -- rather they should reuse available federal
components and tailor those through derivation by extension or
restriction.

Agencies should also reuse the datatypes available in the federal
unqualified and qualified datatypes XML Schema modules. The federal
unqualified and qualified datatype XML Schema modules will serve as the
basis of agency unique unqualified and qualified XML Schema modules.
Agency XML Schemas should import the Federal namespaces accordingly.

The term 'reuse' refers to the ability for root XML Schemas to use
readily the content defined within common XML Schema(s). This document
provides guidance that this reuse will occur by importing content from
common XML Schema(s) into the root XML Schema(s). Reuse should not be
understood as the ability to copy and paste content from a common XML
Schema into a root XML Schema.

\[SSM16\] Agencies SHOULD create Agency level XML Schema modules for
reusable components not included in Federal level XML Schema. Agencies
SHOULD submit all Agency reusable components for consideration as
Federal level reusable components.

#### Agency Common Complex Data XML Schema Modules

When opting to create an agency-specific XML Schema module to contain
complex datatypes, an agency can create an XML Schema specifically
dedicated to that purpose. Such a XML Schema would represent an
agency-specific analog to the federal external XML Schema module (see
section 3.6.3 of this document)

\[SSM17\] A XML Schema module defining Agency Common Complex Data
Elements MAY be created.

It is important that a consistent file naming convention be applied to
these agency-specific XML Schema modules. Adherence to a common
convention will promote clarity of file contents and will simplify
development efforts by reducing confusion of locating proper files.

\[SSM18\] Agency Common Complex Data Element XML Schema modules MUST be
named \"\<agencyToken\>:\<AgencyName\>\
CommonComplexDataElements XML Schema Module\"

#### Agency Common Simple Data XML Schema Modules 

When opting to create an agency-specific XML Schema module to contain
complex datatypes, an agency can create an XML Schema specifically
dedicated to that purpose.

\[SSM19\] A XML Schema module defining all Agency Common Simple Data
Elements MAY be created.

As with the agency common complex data XML Schema modules, it is
important that a consistent file naming convention be applied to the XML
Schema module containing simple data types. Adherence to a common
convention will promote clarity of file contents and will simplify
development efforts by reducing confusion of locating proper files.

\[SSM20\] Agency Common Simple Data Elements XML Schema modules MUST be
named \"fed: \<agencyToken\>:\<AgencyName\>\
Common Simple Data Elements XML Schema Module\"

#### Unqualified Datatypes

\[SSM21\] A XML Schema module defining all Agency Unqualified Datatypes
MAY be created.

\[SSM22\] Agency Unqualified Datatype XML Schema modules MUST be named
\"\<agencyToken\>:\<AgencyName\> Unqualified Datatype XML Schema
Module\"

#### Qualified Datatypes

\[SSM23\] A XML Schema module defining all Agency Qualified Datatypes
MAY be created.

\[SSM24\] Agency Qualified Datatypes XML Schema modules MUST be named
\<agencyToken\>:\<AgencyName\> Qualified Datatypes XML Schema module\"

### Modularity and Namespaces

XML Schema modularity refers to the manner in which content is
distributed throughout a set of related XML Schema files. A
well-designed modularity model is critical endowing a XML Schema library
with implicit flexibility to meet the needs of a large community of XML
Schema authors and software developers alike. While the XML Schema
authoring community will drive the evolution of the XML data standards,
that community should always be mindful of the impact that XML Schema
design has on the software development community.

The XML Schema language allows for myriad options when establishing a
modularity model for an XML Schema library. Each XML file may have a
target namespace unique to that file, or it's content may be defined
independent of any targetnamespace. In the latter case, however, content
residing in an XML Schema without a namespace may be 'coerced' into
another Schemas namespace.

Federal XML authors should be aware that a target namespace may apply to
one or more XML Schema files. In the context of this document, the only
case in which a namespace extends beyond the bounds of one file is in
internal XML Schema modules. Per rule \[NMS1\] internal XML Schema
modules are NOT required to declare a targetnamespace. In all other
cases, versioning of a namespace should equate with versioning the XML
Schema file that declares that namespace.

#### Common Complex Data Elements XML Schema Modules

As noted earlier in this document (section 3.5), each major version of a
federal XML Schema should be separated into it's own unique namespace.

\[NMS8\] Each Federal and Agency Common Complex Data Elements XML Schema
Module major version MUST reside in its own namespace.

\[NMS9\] Each Federal and Agency Common Complex Data Elements XML Schema
Module MUST be represented by the token
\"CCD\[agencyid\]\[majorversion\]\[minorversion\]\".

Federal XML Schema modules will be easily distinguishable from Agency
XML Schema modules through both namespaces and the addition of agency
identifiers \[agencyid\] to namespace token strings.

#### Common Simple Data Elements XML Schema Modules

To facilitate imrpoved organization of federal XML Schema content, each
agency should group simple data elements together in a single common XML
Schema module. As noted earlier in this document, this XML Schema should
align with the versioning strategy

\[NMS10\] Each Federal and Agency Common Simple Data Elements XML Schema
Module major version MUST reside in its own namespace.

To facilitate a consistent method of defining target namespace prefixes
within each XML Schema, federal agencies should

\[NMS11\] Each Common Simple Data Elements XML Schema module MUST be
represented by the token
\"csd\[agencyid\]\[majorversion\]\[minorversion\]\".

#### Unqualified Datatype XML Schema Modules

\[NMS12\] Each Federal and Agency Unqualified Datatype XML Schema module
major version MUST reside in its own namespace.

\[NMS13\] Each Federal and Agency Unqualified Datatype XML Schema module
namespace MUST be represented by the token
\"udt\[agencyid\]\[majorversion\]\[minorversion\]\".

#### Qualified Datatype XML Schema Modules

\[NMS14\] Each Federal and Agency Qualified Datatypes XML Schema module
MUST reside in its own namespace.

\[NMS15\] Each Federal and Agency Qualified Datatypes XML Schema module
namespace MUST be represented by the token
\"qdt\[agencyid\]\[majorversion\]\[minorversion\]\".

#### Code and Identifier List XML Schema Modules

\[NMS16\] Each CodeList XML Schema module MUST be maintained in a
separate namespace.

## Documentation

### Annotation

Federal XML Schema authors must use care when using the xsd:annotation
element. Although the leaf xsd:documentation element discussed in the
next section provides no problems, the leaf xsd:appInfo provides
significant security risks and must not be used.

\[GXS12\] Federal and agency schemas SHOULD NOT use xsd:appinfo. If
used, xsd:appinfo MUST only be used to convey non-normative information

### Embedded Documentation

When developing XML Schemas, federal agencies should provide adequate
documentation as outlined in this document. Upon deployment of these XML
Schemas to runtime IT environments (test systems, production systems,
ets.) agencies may choose to remove all documentation embedded in an XML
Schema by processing it against an XSLT script available for use by any
federal resource.

When an agency is embarking on the development of any type of
application integration (using Web services, for example) it should
provide a 'version' of the XML Schema that is devoid of documentation.
This documentation can be removed by a simple software application such
as the use of an XSLT script.

Removal of XML Schema documentation will, in many cases, improve
performance. In some cases, a significant performance benefit will be
realized.

\[GXS2\] Federal and Agency XML Schema SHOULD provide two normative XML
Schemas for each transaction, one of which is fully annotated and the
other of which is a run-time XML Schema devoid of documentation.

\[DOC1\] The xsd:documentation element for every Datatype MUST contain a
structured set of annotations in the following sequence and pattern:

ComponentType (mandatory): The type of component to which the object
belongs. For Datatypes this must be "DT".

DictionaryEntryName (mandatory): The official name of a Datatype.

Version (optional): An indication of the evolution over time of the
Datatype.

Definition (mandatory): The semantic meaning of a Datatype.

ObjectClassQualifier (optional): The qualifier for the object class.

ObjectClass (optional): The Object Class represented by the Datatype.

RepresentationTerm (mandatory): A Representation Term is an element of
the name which describes the form in which the property is represented.

DataTypeQualifier (optional): semantically meaningful name that
differentiates the Datatype from its underlying Core Component Type.

DataType (optional): Defines the underlying, fundamental data type.

###  {#section .unnumbered}

\[DOC2\] A Datatype definition MAY contain one or more Content Component
Restrictions to provide additional information on the relationship
between the Datatype and its corresponding Core Component Type. If used,
the Content Component Restrictions must contain a structured set of
annotations in the following patterns:

RestrictionType (mandatory): Defines the type of format restriction that
applies to the Content Component.

RestrictionValue (mandatory): The actual value of the format restriction
that applies to the Content Component.

ExpressionType (optional): Defines the type of the regular expression of
the restriction value.

\[DOC3\] A Qualified Datatype definition MAY contain one or more allowed
metadata attribute restrictions to provide additional information on the
relationship between the Datatype and its corresponding unqualified
Datatype. If used the metadata Restrictions must contain a structured
set of annotations in the following patterns:

MetadataAttributeName (mandatory): Identifies the metadata attribute on
which the restriction applies.

RestrictionValue (mandatory, repetitive): The actual value(s) that is
(are) valid for the metadata attribute

\[DOC4\] The xsd:documentation element for every simple data element
MUST contain a structured set of annotations in the following sequence
and pattern:

DictionaryEntryName (mandatory): The ISO 11179 conformant name.

Version (optional): An indication of the evolution over time of the
simple data element.

Definition(mandatory): The semantic meaning of the simple data element.

Cardinality(mandatory): Indication whether the simple data element
represents a not-applicable, optional, mandatory and/or repetitive
characteristic of higher level aggregates.

ObjectClassQualifier (optional): The qualifier for the object class.

ObjectClass(mandatory): The Object Class of which the simple data
element is a property of.

PropertyTermQualifier (optional): The qualifier for the property term.

PropertyTerm(mandatory): Property Term represents the distinguishing
characteristic or Property of the Object Class and shall occur naturally
in the definition of the simple data element.

RepresentationTerm (mandatory): A Representation Term describes the form
in which the simple data element is represented.

DataTypeQualifier (optional): semantically meaningful name that
differentiates the Qualified Datatype of the simple data element from
its underlying Unqualified Datatype.

DataType (mandatory): Defines the Datatype used for the simple data
element.

AlternativeBusinessTerms (optional): Any synonym terms under which the
Simple data element is commonly known and used in the business.

Examples (optional): Examples of possible values for the Simple data
element.

\[DOC5\] The xsd:documentation element for every complex data element
representing a class MUST contain a structured set of annotations in the
following sequence and pattern:

ComponentType (mandatory): The type of component to which the object
belongs. For classes, this must be "complex data element".

DictionaryEntryName (mandatory): The official name of the complex data
element.

Version (optional): An indication of the evolution over time of the
complex data element.

Definition(mandatory): The semantic meaning of the complex data element.

ObjectClassQualifier (optional): The qualifier for the object class.

ObjectClass(mandatory): The Object Class represented by the complex data
element.

AlternativeBusinessTerms (optional): Any synonym terms under which the
Complex data element is commonly known and used in the business.

\[DOC6\] The xsd:documentation element for every Association Property
element declaration MUST contain a structured set of annotations in the
following sequence and pattern:

AssociationType (mandatory): The nature of the association to which the
object belongs.

DictionaryEntryName (mandatory): The official name of the Association
Property.

Version (optional): An indication of the evolution over time of the
Association Property.

Definition (mandatory): The semantic meaning of the Association
Property.

Cardinality (mandatory): Indication whether the Association Property
represents an optional, mandatory and/or repetitive assocation.

ObjectClass (mandatory): The Object Class containing the Association
Property.

PropertyTermQualifier (optional): A qualifier is a word or words which
help define and differentiate the Association Property.

PropertyTerm(mandatory): The nature of the association between the two
complex data elements.

AssociatedObjectClassQualifier (optional): Associated Object Class
Qualifiers describe the \'context\' of the relationship with another
complex data element.

AssociatedObjectClass (mandatory); Associated Object Class is the Object
Class at the other end of this association. It represents the child
Class contained by the property of the parent class.

\[DOC7\] In addition to the data required by rule DOC5, the
xsd:documentation element for each federal level XML Schema root element
MUST contain a structured set of annotations in the following sequence
and pattern:

\[S65\] Stored Registry Classes shall include a Unique Identifier.

\[S66\] Stored *Registry Classes* shall include a *Version* number to
keep track of the evolution over time of a *Registry Class*.

\[S67\] Stored Registry Classes shall include a Dictionary Entry Name.

\[S68\] Stored *Registry Classes* shall include a *Definition*.

\[S69\] Stored *Registry Classes* may include one or more *Usage Rules*,
describing how and/or when to use the *Registry Class*.

\[S70\] Except for the first *Version* of a *Registry Class*, each
stored *Version* shall be linked to its previous *Version*.

\[S71\] Except for the last *Version* of a *Registry Class*, each stored
*Version* shall be linked to its next *Version*.

\[S72\] Stored *Registry Classes* shall include the history of the
status lifecycle of each *Version*.

### Status (mandatory): Status of the *Registry* Management Information

#### Administrative Information 

\[S73\] Stored *Registry Classes* shall contain administrative
information and shall include the following *Attributes*:

-   Registrar (mandatory): Name of the responsible person who has
    created the *Registry Class* in the registry

-   Registration Authority (mandatory): Organisation authorised to
    register the *Registry Class*.

-   Submitting Organization (mandatory): The organisation that has
    submitted / requested the *Registry Class.*

#### Status Information 

\[S74\] Stored *Registry Classes* shall contain status information to
include the following *Attributes*:

-   Status (mandatory): Status of the *Registry Class* (i.e. draft,
    provisionally registered, registered, to be retired, retired, \...)

-   Start Date (mandatory): Date on which the status comes into effect

-   Reason (optional): Description of why the *Registry Class* status
    has been changed.

-   Reference (optional, repetitive): External Document(s) containing
    relevant information about the status change.

-   Comment (optional, repetitive): Remark about the *Registry Class*
    status.

#### Change History 

\[S75\] Stored *Registry Classes* shall include the history of all
modifications related to each *Version* to include the following
*Attributes*:

-   Change Type (mandatory): Purpose of the Changesuch as new element,
    new version, element modification, status modification, element
    replacement*.*

-   Change Date (mandatory): Date on which the modification has been
    made.

-   Change Description (mandatory): Description of why and how the
    *Registry Class* has been modified.

-   Request By (mandatory): Name of the organisation that has requested
    the modification of the *Registry Class.*

-   Request Date (mandatory): Date on which the modification was
    requested.

-   Comment (optional, repetitive): Remark about the *Registry Class*
    modification.

-   Reference (optional, repetitive): External Document(s) containing
    relevant information about the modification.

#### Replacement Information 

\[S76\] For each stored pair of *Registry Classes* where one *Registry
Class* replaces the other, the stored information shall specify
Replacement Information to include the following *Attributes*:

-   Replacement Description (mandatory): Reason for the *Registry Class*
    being replaced

-   Replacement Date (mandatory): Date from which the replacement is
    effective.

\[S77\] If another *Registry Class* has replaced a *Registry Class*, it
shall be linked to the *Registry Class* by which it has been replaced.

\[S78\] If a *Registry Class* replaces one or more other *Registry
Class(es)*, it shall be linked to the *Registry Class(es)* it replaces

[]{#__RefHeading___Toc114385984 .anchor}

### Content Information

#### Descriptive Information 

\[S79\] Stored *Registry Classes* may include additional descriptive
information to include the following *Attributes*:

-   Comments (optional, repetitive): Comments is additional information
    about a *Registry Class*, which is not part of the *Definition* but
    that is considered relevant for clarification.

-   Reference Document (optional, repetitive): Reference Document is a
    reference (e.g. a Uniform Resource Locator) to external
    documentation that contains relevant additional information about a
    *Registry Class*.

-   Acronym (optional, repetitive): Acronym is an abbreviation or code
    under which the *Registry Class* is commonly known.

-   Keyword (optional, repetitive): Keyword is one or more significant
    words used for the search and retrieval of a *Registry Class*.

#### Representation Information 

\[S80\] Stored *Registry Classes* may optionally include information
about the representation of the *Registry Class* in one or more syntaxes
to include the following *Attributes*.

-   Representation Syntax (mandatory): Identification of the
    representation syntax

-   Representation (mandatory): Physical representation of the *Registry
    Class* (e.g. Extensible Markup Language tag)

-   Constraint (optional, repetitive): Description of additional
    constraints that apply to the representation of the *Registry Class*
    in the given syntax (e.g. maximum length)

#### Association Information 

\[S81\] Stored *Registry Classes* shall include all associations they
have with other stored *Registry Classes* and shall include the
following *Attributes*:

-   Association Name (mandatory): Name of the association

-   Association Description (mandatory): Descriptive text explaining the
    meaning of the association

-   Association Type (mandatory): Type of association (e.g. aggregation,
    specialisation, generalization, simple association \...)

-   Association Multiplicity (mandatory): *Cardinality* of the
    association (i.e. optional/mandatory and repetition)

-   Start Date (mandatory): Date at which the association becomes valid

-   End Date (optional): Date from which the association is no longer
    valid

-   Comment (optional, repetitive): Relevant information about the
    association (e.g. reason why it has been removed, \...)

-   \[ED. NOTE: Per the 9/12/2005 meeting "agreement on the preferences
    and optionality. Will add language explaining the preference and
    define the options along with the cautions"\]

# Naming XML Constructs

## General Naming Rules

### Syntax Neutral Naming Rules

A naming convention is necessary to gain consistency in the naming and
defining of all federal data elements. Such a convention facilitates
comparison during the discovery and analysis process, and helps to
eliminate ambiguity during the process of data harmonization between
disparate organizations, such as the development of multiple complex
data elements with different names that have the same semantic meaning.

The naming convention put forth in this document is derived from the
guidelines and principles described in ISO 11179 Part 5 \-- Naming and
Identification Principles For Data Elements. In certain instances, these
guidelines have been adapted to the XML environment.

One of the properties of a data element that this document refers to
below is a 'Dictionary Entry Name'. A dictionary entry name is a unique
definition of a business concept that is meant to be agreed to by all
federal agencies adhering to the rules and guidance outlined in this
document. All official dictionary entries will be in English. Due to the
growing exchange of data between federal agencies and coalition
partners, an authoritative source that will ensure absolute clarity and
understanding of the names and definitions is required. The Oxford
English Dictionary is that authoritative source. Specifically, Oxford
English Dictionary American spellings will be used as the primary
source.

As a whole, federal dictionary entry names correspond to a
supplementary, controlled vocabulary of Object Classes, Property Terms,
and Qualifiers will be developed to identify the definition to be used
for any words that are potentially ambiguous. This Controlled Vocabulary
shall also be used to identify the preferred word in cases where more
than one word might be used to cover the same definition. The Controlled
Vocabulary will also contain terms not found in the Oxford English
Dictionary. This will ensure that each word within any of the names and
definitions is used in a consistent and unambiguous way. The resultant
semantic integrity will also mean that translation into other languages
retains the precise original meaning.

#### Dictionary Information

Each *data element* contains the following dictionary information that
is impacted by the naming rules in subsequent sub-sections:

-   *Dictionary Entry Name* (Mandatory). This is the unique official
    name of the *Data Element* in the dictionary.

-   *Definition* (Mandatory). This is the unique *Business Semantic* of
    that *Data Element*.

-   *Business Term* (Optional). This is a synonym term under which the
    *data Element i*s commonly known and used in the business. A *Data
    Element* may have several *Business Terms* or synonyms.

::: definition
\[Example\]
:::

::: definition
Dictionary Entry Name -- Person. Tax. Identifier
:::

::: definition
*Definition* -- The registered national tax identification of a person
:::

::: definition
*Business Term* -- Income tax number, national register number, personal
tax register number, social security number, national insurance number
:::

The naming rules are also based on the following concepts as defined in
ISO 11179:

-   *Object Class*. This represents the logical data grouping or
    aggregation (in a logical data model) to which a *Property* belongs.
    The *Object Class* is expressed by an *Object Class Term*. The
    *Object Class* thus is the part of a *Dictionary Entry Name* of the
    *Data Element* that represents an activity or object in a specific
    *Context*. *Object Classes* have explicit boundaries and meaning and
    their *Properties* and behaviour follow the same rules.

-   *Property Term.* This represents the distinguishing characteristic
    or *Property* of the *Object Class* and shall occur naturally in the
    definition.

-   *Representation Term*. An element of the *Data Element* name which
    describes the form in which the *Data Element* is represented.

-   *Qualifier Term*. A word or words which help define and
    differentiate a *Data Element* from its other related *Data
    Elements*.

#### General Rules

The official language for submissions to Core.gov is English. All
official entries should be made in English. In order to ensure absolute
clarity and understanding of the names and definitions it is essential
to use words from the *Oxford English Dictionary*. A supplementary
*Controlled Vocabulary* will be developed to identify the definition to
be used for any words that are potentially ambiguous. This *Controlled
Vocabulary* shall also be used to identify the preferred word in cases
where more than one word might be used to cover the same definition. The
*Controlled Vocabulary* will also contain terms not found in the *Oxford
English Dictionary*. This will ensure that each word within any of the
names and definitions is used in a consistent and unambiguous way. The
resultant semantic integrity will also mean that translation into other
languages retains the precise original meaning.

\[DEN1\] The dictionary content, with the exception of *Business Terms*,
shall be in the *English Language* following the primary *Oxford English
Dictionary* American spellings to assure unambiguous spelling.

#### Rules for Definitions

\[DEN2\] The definition shall be consistent with the requirements of ISO
11179-4 Section 4 and will provide an understandable meaning, which
should also be translatable to other languages.

\[DEN3\] The definition shall take into account the fact that the users
of the Data Elements are not necessarily native English speakers. It
shall therefore contain short sentences, using normal words. Wherever
synonym terms are possible, the definition shall use the preferred term
as identified in the Controlled Vocabulary.

\[DEN4\] The definition of a Simple Data Element shall use a structure
that is based on the existence of the Object Class Term, the Property
Term, the Data Type, and any Qualifiers.

\[DEN5\] The definition of an Association between Complex Data Elements
shall use a structure that is based on the existence of the Object Class
Term of the associating Complex Data Element, the Property (nature of
the association), and the Object Class Term of the associated Complex
Data Element and any Qualifiers.

\[DEN6\] Whenever both the definite (i.e. the) and indefinite article
(i.e. a) are possible in a definition, preference shall be given to an
indefinite article (i.e. a).

::: definition
\[Note\]
:::

::: definition
To verify the quality of the definition, place the *Dictionary Entry
Name* followed by *is* before the definition to ensure that it is not
simply a repetition of the *Dictionary Entry Name.*
:::

#### Rules for Dictionary Entry Names

\[DEN7\] The *Dictionary Entry Name* shall be unique.

\[DEN8\] The *Dictionary Entry Name* shall be extracted from the
definition.

\[DEN9\] The *Dictionary Entry Name* shall be concise and shall not
contain consecutive redundant words.

\[DEN10\] The *Dictionary Entry Name* and all its components shall be in
singular form unless the concept itself is plural.

::: definition
\[Example\]
:::

::: definition
The singular Good does not exist, whereas Goods is a plural noun whose
concept involves one or multiple (plural) items
:::

\[DEN11\] The *Dictionary Entry Name* shall not use non-alphanumeric
characters unless required by language rules. Numeric characters should
not be used for sequencing.

Instead of days of the week, use week days.

\[DEN12\] The *Dictionary Entry Name* shall contain verbs, nouns and
adjectives (i.e. no words like *and, of, the*, etc.) only when it is
natural to do so.

\[DEN13\] Abbreviations and acronyms that are part of the *Dictionary
Entry Name* shall be expanded or explained in the definition.

\[DEN14\] The *Object Class Term, Property Term*, and *Representation
Term* components of a *Dictionary Entry Name* shall be separated by
dots. The space character shall separate words in multi-word *Object
Class Terms* and/or multiword *Property Terms,* including their
*Qualifier Terms*. Every word shall start with a capital letter.
*Qualifier Terms* shall be separated from their associated *Object
Class* or *Property Term* by an underscore (\_) followed by a space to
separate each qualifier. To allow spell checking of the words in the
*Dictionary Entry Nam*e, a space character shall follow the dots after
*Object Class Term(s)* and *Property Term(s)*.

\[DEN15\] *Qualifier Terms* shall precede the associated *Object Class
Term* or *Property Term.* The order of qualifiers shall not be used to
differentiate *Dictionary Entry Names*.

\[DEN16\] The *Dictionary Entry Name* of a Simple Data Element shall
consist of the following parts in the order specified:

the Object Class Term of the owning the corresponding Basic Core
Component Property,

the *Property Term* of the corresponding class property, and

the Representation Term of the Data Type

any Qualfiying Terms

::: definition
\[Example\]
:::

::: definition
Tax. Description. Text
:::

\[DEN17\] The *Dictionary Entry Name* of an Complex Data Element
*Association* shall consist of the following components in the specified
order:

the Object Class Term of the Complex Data Element owning the
corresponding Association Property,

the Property Term of the corresponding Association Property,

the Object Class Term of the Complex Data Element on which the
corresponding Association Core Component Property is based, and

Any Qualifying Terms.

::: definition
\[Example\]
:::

::: definition
Person. Residence. Address
:::

\[DEN18\] The components of a *Dictionary Entry Name* shall be separated
by dots. The space character shall separate words in multi-word *Object
Class Terms* and/or multi-word *Property Terms*. Every word shall start
with a capital letter. To allow spell checking of the *Directory Entry
Names*' words, the dots after *Object Class Terms* and *Property Terms*
shall be followed by a space character.

::: definition
\[Note\]
:::

::: definition
The use of CamelCase for *Dictionary Entry Names* has been considered,
but has been rejected for following reasons:
:::

::: definition
• Use of CamelCase will not allow the use of spell checkers
:::

::: definition
• Strict use of CamelCase makes it impossible to use separators (".")
and\
therefore doesn't allow an unambiguous identification of the\
composing parts of the *Dictionary Entry Name.*
:::

\[DEN19\] The name of an *Object Class* shall always have the same
semantic meaning throughout the dictionary and may consist of more than
one word.

\[DEN20\] The name of a *Property Term* shall occur naturally in the
definition and may consist of more than one word. A name of a *Property
Term* shall be unique within the *Context* of an *Object Class* but may
be reused across different *Object Classes*.

::: definition
\[Example\]
:::

::: definition
Car. Color. Code and Shirt. Color. Code may both exist.
:::

\[DEN21\] The *Dictionary Entry Name* of an *Complex Data Type* shall
consist of a meaningful *Object Class Term*. The *Object Class Term* may
consist of more than one word.

::: definition
\[Example\]
:::

::: definition
Postal Address. Party
:::

[]{#__RefHeading___Toc114385989 .anchor}XML Naming Rules

\[GNR1\] XML element, attribute and type names MUST be in the English
language, using the primary American spellings provided in the Oxford
English Dictionary for writers and editors.

\[GNR2\] XML element, attribute and type names MUST be consistently
derived from ISO 11179 conformant dictionary entry names.

\[GNR3\] XML element, attribute and type names constructed from
dictionary entry names MUST NOT include periods, spaces, other
separators, or characters not allowed by W3C XML 1.0 for XML names.

\[GNR4\] XML element, attribute, and simple and complex type names MUST
NOT use acronyms, abbreviations, or other word truncations, except those
in the list of exceptions published in Appendix XX.

\[GNR5\] Acronyms and abbreviations MUST only be added to the federal
approved acronym and abbreviation list after careful consideration for
maximum understanding and reuse.

\[GNR6\] The acronyms and abbreviations listed in Appendix XX MUST
always be used.

\[GNR7\] XML element, attribute and type names MUST be in singular form
unless the concept itself is plural.

\[GNR8\] The UpperCamelCase (UCC) convention MUST be used for naming
elements and types.

\[GNR9\] The lowerCamelCase (LCC) convention MUST be used for naming
attributes.

## Type Naming Rules

### Complex Type Names for Complex Data Elements

\[CTN1\] An xsd:complexType name based on a complex data element MUST be
the Dictionary Entry Name with the separators removed and with with the
suffix \"Type\" appended following the upper camel case convention.

### Complex Type Names for Simple Data Elements

\[CTN2\] An xsd:complexType name based on a Simple Data Element MUST be
the Simple Data Element Dictionary Entry Name with the separators
removed and with the \"Type\" suffix appended after the representation
term.

### Type Names for Unqualified Datatypes

#### Complex Type Names

\[CTN3\] An xsd:complexType for a unqualified datatype MUST have the
name of the corresponding ccts:CoreComponentType, with the separators
removed and with the \"Type\" suffix appended.

#### Simple Type Names

\[STN1\] Each xsd:simpleType definition name MUST be the datatype
dictionary entry name with the separators removed.

### Type Names for Qualified Datatypes

#### Complex Type Names

#### Simple Type Names

### Type Names for Codes and Identifiers

#### Complex Type Names

#### Simple Type Names

## Element Naming Rules

### Element Names for Complex Data Elements

#### Element Names for Simple Data Elements

#### Element Names for Associations

## Attribute Naming Rules

\[ATN1\] Each xsd:attribute \"name\" MUST be an ISO 11179 conformant
dictionary entry name object class, property term and representation
term with any separators removed.

# Declarations and Definitions

## Type Definitions

### General Type Definitions

The XML Schema language allow for the definition of complex types within
a element. In such cases, these complex types are defined 'locally' from
the perspective of the elements using them and they are not given
specific names.

To promote the development of an federal XML Schema library that lends
itself to reuse over time, XML Schema authors should develop content so
that the complex types are defined globally. Global definition of
complex types will ensure that each type has a unique name (in
conjunction with its associated XML Schema namespace) and can be used
freely by other XML Schema content.

\[GTD1\] All types MUST be named.

### Simple Type Definitions

\[STD1\] For every datatype whose metadata components map directly onto
the properties of a built-in xsd:DataType, the datatype MUST be defined
as a named xsd:simpleType in the fed:unqualifiedDatatype XML Schema
module.

\[ED. NOTE: Per the 9/12/2005 meeting "Need to fix simple type
definitions under the Simple DE Type\]

### Complex Type Definitions

\[CTD1\] For every complex and simple data element identified in a
Federal or Agency data centric process model, a named xsd:complexType
MUST be defined.

\[CTD2\] Every complex data element xsd:complexType definition content
model for data-centric XML Schema MUST use the xsd:sequence element with
appropriate global element references to reflect each simple data
element (property) that constitute its content model.

\[CTD3\] Every simple data element xsd:complexType definition content
model MUST use the xsd:simpleContent element.

\[CTD4\] Every simple data element xsd:complexType content model
xsd:simpleContent element MUST consist of an xsd:extension element.

\[CTD5\] Every simple data element xsd:complexType content model
xsd:base attribute value MUST be an unqualified or qualified federal
datatype as appropriate.

\[CTD6\] For every datatype used in a data model, a named
xsd:complexType or xsd:simpleType MUST be defined.

\[CTD7\] All defined or used unqualified datatypes MUST either be those
defined in the Unqualified Datatype XML Schema Module from UN/CEFACT,
the federal Unqualified Datatype XML Schema Module, or an Agency
Unqualified Datatype XML Schema Module.

\[CTD8\] Each unqualified Datatype xsd:complexType must be based on its
corresponding source xsd:complexType. [Note: If we don't use CTD7, then
we need CTD8. If we use CTD7, then we don't need CTD8.]{.mark}

\[CTD9\] Every qualified Datatype whose corresponding unqualified
datatype is defined as an xsd:complexType MUST also be defined as an
xsd:complexType and MUST be based on the same xsd:simpleType.

\[CTD10\] Every qualified Datatype whose corresponding unqualified
datatype is defined as an xsd:simpleType MUST also be defined as an
xsd:simpleType and MUST be based on the same xsd:simpleType.

\[CTD11\] Each unqualified Datatype xsd:complexType definition must
contain one xsd:simpleContent element.

\[CTD12\] For every datatype whose metadata components are not
equivalent to the properties of a built-in xsd:Datatype, it MUST be
defined as a named xsd:complexType in the Unqualified Datatype XML
Schema module.

\[CTD13\] The Unqualified Datatype xsd:complexType definition
xsd:simpleContent element MUST contain one xsd:extension element. This
xsd:extension element MUST include an xsd:base attribute that defines
the specific xsd:Built-inDatatype required.

\[CTD14\] Each metadata component xsd:attribute \"type\" MUST define the
specific xsd:Built-in Datatype or the user defined xsd:simpleType for
the metadata component of the unqualified Datatype.

\[CTD15\] Each metadata component xsd:attribute \"use\" MUST define the
occurrence of that metadata component as either \"required\", or
\"optional\".

#### Content Models

##### Sequence

##### xsd:all

\[GXS8\] The xsd:all element MUST NOT be used in data centric XML
Schema.

##### xsd:choice

\[GXS9\] The xsd:choice element SHOULD NOT be used where customisation
and extensibility are a concern.

##### xsd:include

\[GXS10\] The xsd:include feature MUST only be used within a root XML
Schema.

##### xsd:union

\[GXS11\] The xsd:union technique MUST NOT be used except for Code and
Identifier Lists. The xsd:union technique MAY be used for Code and
Identifier Lists.

##### xsd:any

To promote data interoperability across government agencies, it is
critical that federal XML Schemna data types be defined in a structured
manner

\[GTD2\] The xsd:any data type MUST NOT be used.

## Element Declarations

### Global and Local Elements

### Elements Bound to Complex Types

\[ELD3\] For every complex data element identified in the data model, a
global element bound to the corresponding xsd:complexType MUST be
declared.

### Elements Bound to Simple Types

### Elements Representing Associations between Complex Data Elements

\[ELD4\] If an association between two complex data elements is
unqualified, the association MUST use the global element declared for
the associated complex data element. If an association between two
complex data elements is qualified, a new global element representing
the qualified association MUST be declared and used.

### Elements Bound to Datatypes

\[ELD5\] For each datatype SimpleType definition, an xsd:restriction
element MUST be declared.

### Elements representing Code Lists and Identifier Lists

\[ELD6\] Code list and Identifier List xsd:import elements MUST contain
the namespace and XML Schema location attributes.

### Empty Elements

The XML Schema language makes it possible to define elements so that
they do not (in the conforming XML instance) contain any content between
the opening and closing tag of the element. Rather, attributes alone are
used to carry data for the element.

Figure -- illustrates how this might appear in an XML instance.

Figure \-\--

[\<ContactInformation\>]{.mark}

[\<PrimaryContact
eMail=[**primary.contact@eMail.com**](mailto:primary.contact@eMail.com)
contactID="1"/\>]{.mark}

[\<SecondaryContact
eMail=[**secondary.contact@eMail.com**](mailto:secondary.contact@eMail.com)
contactID="2"/\>\
\< ContactInformation\>]{.mark}

In this case, it may not make good design sense to place the primary
contact eMail address on the parent element ('EMailAddresses' in this
example). Rather, the eMail address and contact ID of each item within
contact information is carried within the otherwise empty element.

As such, empty elements should be used only when it is not possible for
an XML Schema author to define attributes on a containing element and
the otherwise empty element is used to carry attribute content.

\[ELD7\] Empty elements SHOULD not be declared.

While there may be circumstances in which an otherwise empty element may
be used to carry attribute values, agencies should always avoid the use
of elements that are entirely devoid on any content.

Figure \-\-- illustrates how this would appear in an XML instance
document. The 'PimaryContact' element does not contain any data content
whatsoever.

Figure \-\--

[\<ContactInformation\>]{.mark}

[\<PrimaryContact/\>\
\< ContactInformation\>]{.mark}

\[IND5\] Data centric instance documents MUST NOT contain an element
devoid of content or null values.

Conversely, XML Schema implementation guides must not indicate that if
data is not present, a particular meaning is conveyed.

\[IND6\] The absence of a construct or data in an instance document MUST
NOT carry meaning.

###  {#section-1 .unnumbered}

###  {#section-2 .unnumbered}

###  {#section-3 .unnumbered}

###   {#section-4 .unnumbered}

### XSD:Any Elements

Since the goal of this document is to decrease the effort required to
achieve interoperability, it is important that clear guidance be
established regarding the use of the xsd:any element. The xsd:any
element makes it possible for XML Schema authors to allow any type of
XML content to be passed within a specific part of an XML instance
document that conforms to the relevant XML Schema.

As such, the any element should be used with caution and only in those
circumstances in which the XML content it is meant to control will not
need to be validated by the receiving system(s).

\[ELD8\] The xsd:any element SHOULD NOT be used.

## Attribute Declarations

### User Defined Attributes

\[ATD1\] User defined attributes SHOULD NOT be used in data centric XML
Schema. When used, user defined attributes MUST only convey supplemental
metadata information from table XX not intended for storage or
application processing.

### Metadata Attributes

A general discussion here on the role of metadata attributes and their
importance. Explain how metadata attributes convey data that is not
normally stored. Identify the table in the back that will convey the
approved list of metadata attributes (taken from table 8-2 in ISO
15000-5).

### Global Attributes

\[ATD2\] If a XML Schema Expression contains one or more common
attributes that apply to all elements contained or included or imported
therein, the common attributes MUST be declared as part of a global
attribute group.

Description here.

### Attribute Groups

\[ATD2\] If a XML Schema Expression contains one or more common
attributes that apply to all elements contained or included or imported
therein, the common attributes MUST be declared as part of a global
attribute group.

Description here.

### XML Schema Location

\[ATD3\] Each xsd:XML SchemaLocation attribute declaration MUST contain
a system-resolvable URL. This system resolvable URL SHOULD be persistent
and accessable from any query. If the system resolvable URL is not made
publicly available, it SHOULD be a relative URL referencing the location
of the XML Schema or XML Schema module in the release package.

### XSD:Nil

\[ATD4\] The xsd built in nillable attribute MUST NOT be used for data
centric XML Schema that require authentication and nonrepudiation

### XSD:anyAttribute

\[ATD5\] The xsd:anyAttribute MUST NOT be used for data centric XML
Schema. The xsd:anyAttribute MAY be used for document-centric XML Schema
if consistency in not an issue.

# Extending and Restricting Types

\[GXS13\] Complex Type extension or restriction MAY be used where
appropriate.

## Guidelines for Extension

## Guidelines for Restriction

## Xsd:SubstitutionGroup

\[GXS5\] The xsd:SubstitutionGroups feature Should NOT be used In data
centric XML Schema. If used, it should only be used in user defined
customization XML Schema or when extending Agency or Federal XSD
components.

## xsd:final

\[GXS6\] The xsd:final attribute SHOULD be used where appropriate to
control undesireable extensions.

# Code Lists and Identifier Lists

\[CIL1\] All Codes and Identifiers MUST be part of an Agency or
externally maintained Code List.

\[CIL2\] Agency Libraries MUST identify and use external standardized
code and Identifier lists when available rather than develop their own
native code lists.

\[CIL3\] Agency Libraries MAY design and use an internal code or
identifier list where an existing external code or identifier list needs
to be extended, or where no suitable external code or identifier list
exists.

\[CIL4\] All Federal or Agency maintained or used Code and Identifier
Lists MUST be enumerated using the Federal Code and Identifier List XML
Schema Module Template.

\[CIL5\] The name of each Federal or Agency Code or Identifier List XML
Schema Module MUST be of the form: {Owning Organization}{Code or
Identifier List Name}{Code List XML Schema Module}

\[CIL6\] An xsd:import element MUST be declared for every code or
identifier list required in a root XML Schema.

\[CIL7\] Users of the Federal or Agency Library MAY identify any subset
they wish from an identified code or identifier list for their own
trading community conformance requirements.

\[CIL8\] The xsd:XML SchemaLocation declaration for code and identifier
list XML Schema modules MUST include the complete URI used to identify
the relevant XML Schema.

# Using XML Schematron

# Miscellaneous XSD Rules

## xsd:simpleType

\[GXS3\] Built-in xsd:simpleType SHOULD be used wherever possible.

## Namespace Declaration

\[GXS4\] All W3C XML Schema constructs in federal and Agency XML Schema
and XML Schema modules MUST contain the following namespace declaration
on the xsd XML Schema element: xmlns:xsd=\"http://www.w3.org/2001/XMLXML
Schema\"

## xsd:notation

\[GXS7\] xsd:notations MUST NOT be used.

## xsd:appinfo

\[GXS12\] Federal or Agency XML Schema MUST NOT use xsd:appinfo.

## xsd:key and xsd:keyRef

# XML Instances

## Validation

An XML instance is well-formed if it conforms to XML 1.0 It is valid if
it conforms to a supporting DTD or XML Schema. To ensure consistency,
federal XML must necessarily be well formed and valid. As XSD is defined
as the normative form for XML Schema expressions for the federal
government, by default, every federal XML instance must have a
supporting fully conformant XSD XML Schema.

\[IND1\] All instance documents MUST validate to a corresponding XSD XML
Schema.

## Character Encoding

XML Instances can be expressed in several different character encodings.
To ensure consistency, Federal XML instances should clearly identify the
character encoding being used.

\[IND2\] Instance documents MUST always identify their character
encoding with the XML declaration

At the International level, consensus has been reached between the four
de jure standards bodies as the preferred character set encoding for XML
instance documents to facilitate interoperability. This consensus is
expressed in ISO/IETF/ITU/UNCEFACT Memorandum of Understanding
Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) which calls for
the use of UTF-8. Federal XML instances should follow these guidelines.

\[IND3\] In conformance with ISO/IETF/ITU/UNCEFACT Memorandum of
Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83),
all federal or Agency XML SHOULD be expressed using UTF-8.

## Root Element

\[RED1\] Every instance document must use the global element defined as
the root element in the XML Schema as its root element.

## XML Schema Instance Attribute Namespace Declaration

The XML Schema Specification provides for attributes that are commonly
used in instance documents but that do not appear in a XML Schema. These
attributes belong to a specific namespace. To ensure consistency, this
namespace will be declared in each Federal XML instance.

\[IND4\] All instance documents MUST contain the following namespace
declaration in the root element:
xmlns:xsi=\"http://www.w3.org/2001/XMLXML Schema-instance

# Federal XML Naming and Design Rules Checklist {#federal-xml-naming-and-design-rules-checklist .AppendixHeading1}

This Appendix contains a checklist of all Fedral XML Naming and Design
rules in rule category alphabetical order as follows:

-   Attribute Declaration Rules (ATD)

-   Attribute Naming Rules (ATN)

-   Code and Identifier List Rules (CIL)

-   ComplexType Definition Rules (CTD)

-   ComplexType Naming Rules (CTN)

-   Data Element Dictionary Entry Names and Definitions (DEN)

-   Documentation Rules (DOC)

-   Element Declaration Rules (ELD)

-   General Naming Rules (GNR)

-   General Type Definition Rules (GTD)

-   General XML Schema Rules (GXS)

-   Instance Document Rules (IND)

-   Modeling Constraints Rules (MDC)

-   Naming Constraints Rules (NMC)

-   Namespace Rules (NMS)

-   Root Element Declaration Rules (RED)

-   XML Schema Structure Modularity Rules (SSM)

-   Standards Adherence Rules (STA)

-   SimpleType Naming Rules (STN)

-   SimpleType Definition Rules (STD)

-   Versioning Rules (VER)

+---------+------------------------------------------------------------+
| ##      |                                                            |
|  Attrib |                                                            |
| ute Dec |                                                            |
| laratio |                                                            |
| n Rules |                                                            |
+---------+------------------------------------------------------------+
| \       | User defined attributes SHOULD NOT be used in data centric |
| [ATD1\] | XML Schema. When used, user defined attributes MUST only   |
|         | convey supplemental metadata information from table XX not |
|         | intended for storage or application processing.            |
+---------+------------------------------------------------------------+
| \       | If a XML Schema Expression contains one or more common     |
| [ATD2\] | attributes that apply to all elements contained or         |
|         | included or imported therein, the common attributes MUST   |
|         | be declared as part of a global attribute group.           |
+---------+------------------------------------------------------------+
| \       | Each xsd:XML SchemaLocation attribute declaration MUST     |
| [ATD3\] | contain a system-resolvable URL. This system resolvable    |
|         | URL SHOULD be persistent and accessable from any query. If |
|         | the system resolvable URL is not made publicly available,  |
|         | it SHOULD be a relative URL referencing the location of    |
|         | the XML Schema or XML Schema module in the release         |
|         | package.                                                   |
+---------+------------------------------------------------------------+
| \       | The xsd built in nillable attribute MUST NOT be used for   |
| [ATD4\] | data centric XML Schema that require authentication and    |
|         | nonrepudiation                                             |
+---------+------------------------------------------------------------+
| \       | The xsd:anyAttribute MUST NOT be used for data centric XML |
| [ATD5\] | Schema. The xsd:anyAttribute MAY be used for               |
|         | document-centric XML Schema if consistency in not an       |
|         | issue.                                                     |
+---------+------------------------------------------------------------+

+---------+------------------------------------------------------------+
| ## A    |                                                            |
| ttribut |                                                            |
| e Namin |                                                            |
| g Rules |                                                            |
+---------+------------------------------------------------------------+
| \       | Each xsd:attribute \"name\" MUST be an ISO 11179           |
| [ATN1\] | conformant dictionary entry name object class, property    |
|         | term and representation term with any separators removed.  |
+---------+------------------------------------------------------------+

+----------+-----------------------------------------------------------+
| #        |                                                           |
| # Code a |                                                           |
| nd Ident |                                                           |
| ifier Li |                                                           |
| st Rules |                                                           |
+==========+===========================================================+
| \[CIL1\] | All Codes and Identifiers MUST be part of an Agency or    |
|          | externally maintained Code List.                          |
+----------+-----------------------------------------------------------+
| \[CIL2\] | Agency Libraries MUST identify and use external           |
|          | standardized code and Identifier lists when available     |
|          | rather than develop their own native code lists.          |
+----------+-----------------------------------------------------------+
| \[CIL3\] | Agency Libraries MAY design and use an internal code or   |
|          | identifier list where an existing external code or        |
|          | identifier list needs to be extended, or where no         |
|          | suitable external code or identifier list exists.         |
+----------+-----------------------------------------------------------+
| \[CIL4\] | All Federal or Agency maintained or used Code and         |
|          | Identifier Lists MUST be enumerated using the Federal     |
|          | Code and Identifier List XML Schema Module Template.      |
+----------+-----------------------------------------------------------+
| \[CIL5\] | The name of each Federal or Agency Code or Identifier     |
|          | List XML Schema Module MUST be of the form: {Owning       |
|          | Organization}{Code or Identifier List Name}{Code List XML |
|          | Schema Module}                                            |
+----------+-----------------------------------------------------------+
| \[CIL6\] | An xsd:import element MUST be declared for every code or  |
|          | identifier list required in a root XML Schema.            |
+----------+-----------------------------------------------------------+
| \[CIL7\] | Users of the Federal or Agency Library MAY identify any   |
|          | subset they wish from an identified code or identifier    |
|          | list for their own trading community conformance          |
|          | requirements.                                             |
+----------+-----------------------------------------------------------+
| \[CIL8\] | The xsd:XML SchemaLocation declaration for code and       |
|          | identifier list XML Schema modules MUST include the       |
|          | complete URI used to identify the relevant XML Schema.    |
+----------+-----------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ## Comp  |                                                           |
| lexType  |                                                           |
| Definiti |                                                           |
| on Rules |                                                           |
+==========+===========================================================+
| \[CTD1\] | For every complex and simple data element identified in a |
|          | Federal or Agency data centric process model, a named     |
|          | xsd:complexType MUST be defined.                          |
+----------+-----------------------------------------------------------+
| \[CTD2\] | Every complex data element xsd:complexType definition     |
|          | content model for data-centric XML Schema MUST use the    |
|          | xsd:sequence element with appropriate global element      |
|          | references to reflect each simple data element (property) |
|          | that constitute its content model.                        |
+----------+-----------------------------------------------------------+
| \[CTD3\] | Every simple data element xsd:complexType definition      |
|          | content model MUST use the xsd:simpleContent element.     |
+----------+-----------------------------------------------------------+
| \[CTD4\] | Every simple data element xsd:complexType content model   |
|          | xsd:simpleContent element MUST consist of an              |
|          | xsd:extension element.                                    |
+----------+-----------------------------------------------------------+
| \[CTD5\] | Every simple data element xsd:complexType content model   |
|          | xsd:base attribute value MUST be an unqualified or        |
|          | qualified federal datatype as appropriate.                |
+----------+-----------------------------------------------------------+
| \[CTD6\] | For every datatype used in a data model, a named          |
|          | xsd:complexType or xsd:simpleType MUST be defined.        |
+----------+-----------------------------------------------------------+
| \[CTD7\] | All defined or used unqualified datatypes MUST either be  |
|          | those defined in the Unqualified Datatype XML Schema      |
|          | Module from UN/CEFACT, the federal Unqualified Datatype   |
|          | XML Schema Module, or an Agency Unqualified Datatype XML  |
|          | Schema Module.                                            |
+----------+-----------------------------------------------------------+
| \[CTD8\] | Each unqualified Datatype xsd:complexType must be based   |
|          | on its corresponding source xsd:complexType. [Note: If we |
|          | don't use CTD7, then we need CTD8. If we use CTD7, then   |
|          | we don't need CTD8.]{.mark}                               |
+----------+-----------------------------------------------------------+
| \[CTD9\] | Every qualified Datatype whose corresponding unqualified  |
|          | datatype is defined as an xsd:complexType MUST also be    |
|          | defined as an xsd:complexType and MUST be based on the    |
|          | same xsd:simpleType.                                      |
+----------+-----------------------------------------------------------+
| \        | Every qualified Datatype whose corresponding unqualified  |
| [CTD10\] | datatype is defined as an xsd:simpleType MUST also be     |
|          | defined as an xsd:simpleType and MUST be based on the     |
|          | same xsd:simpleType.                                      |
+----------+-----------------------------------------------------------+
| \        | Each unqualified Datatype xsd:complexType definition must |
| [CTD11\] | contain one xsd:simpleContent element.                    |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| \        | For every datatype whose metadata components are not      |
| [CTD12\] | equivalent to the properties of a built-in xsd:Datatype,  |
|          | it MUST be defined as a named xsd:complexType in the      |
|          | Unqualified Datatype XML Schema module.                   |
+----------+-----------------------------------------------------------+
| \        | The Unqualified Datatype xsd:complexType definition       |
| [CTD13\] | xsd:simpleContent element MUST contain one xsd:extension  |
|          | element. This xsd:extension element MUST include an       |
|          | xsd:base attribute that defines the specific              |
|          | xsd:Built-inDatatype required.                            |
+----------+-----------------------------------------------------------+
| \        | Each metadata component xsd:attribute \"type\" MUST       |
| [CTD14\] | define the specific xsd:Built-in Datatype or the user     |
|          | defined xsd:simpleType for the metadata component of the  |
|          | unqualified Datatype.                                     |
+----------+-----------------------------------------------------------+
| \        | Each metadata component xsd:attribute \"use\" MUST define |
| [CTD15\] | the occurrence of that metadata component as either       |
|          | \"required\", or \"optional\".                            |
+----------+-----------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ##       |                                                           |
| ComplexT |                                                           |
| ype Nami |                                                           |
| ng Rules |                                                           |
+==========+===========================================================+
| \[CTN1\] | An xsd:complexType name based on a class MUST be the      |
|          | Dictionary Entry Name with the separators removed and     |
|          | with with the suffix \"Type\" appended following the      |
|          | upper camel case convention.                              |
+----------+-----------------------------------------------------------+
| \[CTN2\] | An xsd:complexType name based on a Simple Data Element    |
|          | MUST be the Simple Data Element Dictionary Entry Name     |
|          | with the separators removed and with the \"Type\" suffix  |
|          | appended after the representation term.                   |
+----------+-----------------------------------------------------------+
| \[CTN3\] | An xsd:complexType for a unqualified datatype MUST have   |
|          | the name of the corresponding ccts:CoreComponentType,     |
|          | with the separators removed and with the \"Type\" suffix  |
|          | appended.                                                 |
+----------+-----------------------------------------------------------+

+-----------+----------------------------------------------------------+
| ## Data E |                                                          |
| lement Di |                                                          |
| ctionary  |                                                          |
| Entry Nam |                                                          |
| es and De |                                                          |
| finitions |                                                          |
+-----------+----------------------------------------------------------+
| \[DEN1\]  | The dictionary content, with the exception of *Business  |
|           | Terms*, shall be in the *English Language* following the |
|           | primary *Oxford English Dictionary* American spellings   |
|           | to assure unambiguous spelling.                          |
+-----------+----------------------------------------------------------+
| \[DEN2\]  | The definition shall be consistent with the requirements |
|           | of ISO 11179-4 Section 4 and will provide an             |
|           | understandable meaning, which should also be             |
|           | translatable to other languages.                         |
+-----------+----------------------------------------------------------+
| \[DEN3\]  | The definition shall take into account the fact that the |
|           | users of the Data Elements are not necessarily native    |
|           | English speakers. It shall therefore contain short       |
|           | sentences, using normal words. Wherever synonym terms    |
|           | are possible, the definition shall use the preferred     |
|           | term as identified in the Controlled Vocabulary.         |
+-----------+----------------------------------------------------------+
| \[DEN4\]  | The definition of a Simple Data Element shall use a      |
|           | structure that is based on the existence of the Object   |
|           | Class Term, the Property Term, the Data Type, and any    |
|           | Qualifiers.                                              |
+-----------+----------------------------------------------------------+
| \[DEN5\]  | The definition of an Association between Complex Data    |
|           | Elements shall use a structure that is based on the      |
|           | existence of the Object Class Term of the associating    |
|           | Complex Data Element, the Property (nature of the        |
|           | association), and the Object Class Term of the           |
|           | associated Complex Data Element and any Qualifiers.      |
+-----------+----------------------------------------------------------+
| \[DEN6\]  | Whenever both the definite (i.e. the) and indefinite     |
|           | article (i.e. a) are possible in a definition,           |
|           | preference shall be given to an indefinite article (i.e. |
|           | a).                                                      |
+-----------+----------------------------------------------------------+
| \[DEN7\]  | The *Dictionary Entry Name* shall be unique.             |
+-----------+----------------------------------------------------------+
| \[DEN8\]  | The *Dictionary Entry Name* shall be extracted from the  |
|           | definition.                                              |
+-----------+----------------------------------------------------------+
| \[DEN9\]  | The *Dictionary Entry Name* shall be concise and shall   |
|           | not contain consecutive redundant words.                 |
+-----------+----------------------------------------------------------+
| \[DEN10\] | The *Dictionary Entry Name* and all its components shall |
|           | be in singular form unless the concept itself is plural. |
+-----------+----------------------------------------------------------+
| \[DEN11\] | The *Dictionary Entry Name* shall not use                |
|           | non-alphanumeric characters unless required by language  |
|           | rules. Numeric characters should not be used for         |
|           | sequencing.                                              |
+-----------+----------------------------------------------------------+
| \[DEN12\] | The *Dictionary Entry Name* shall only contain verbs,    |
|           | nouns and adjectives (i.e. no words like *and, of, the*, |
|           | etc.).                                                   |
+-----------+----------------------------------------------------------+
| \[DEN13\] | Abbreviations and acronyms that are part of the          |
|           | *Dictionary Entry Name* shall be expanded or explained   |
|           | in the definition.                                       |
+-----------+----------------------------------------------------------+
| \[DEN14\] | The *Object Class Term, Property Term*, and              |
|           | *Representation Term* components of a *Dictionary Entry  |
|           | Name* shall be separated by dots. The space character    |
|           | shall separate words in multi-word *Object Class Terms*  |
|           | and/or multiword *Property Terms,* including their       |
|           | *Qualifier Terms*. Every word shall start with a capital |
|           | letter. *Qualifier Terms* shall be separated from their  |
|           | associated *Object Class* or *Property Term* by an       |
|           | underscore (\_) followed by a space to separate each     |
|           | qualifier. To allow spell checking of the words in the   |
|           | *Dictionary Entry Nam*e, a space character shall follow  |
|           | the dots after *Object Class Term(s)* and *Property      |
|           | Term(s)*.                                                |
+-----------+----------------------------------------------------------+
| \[DEN15\] | *Qualifier Terms* shall precede the associated *Object   |
|           | Class Term* or *Property Term.* The order of qualifiers  |
|           | shall not be used to differentiate *Dictionary Entry     |
|           | Names*.                                                  |
+-----------+----------------------------------------------------------+
| \[DEN16\] | The *Dictionary Entry Name* of a Simple Data Element     |
|           | shall consist of the following parts in the order        |
|           | specified: the Object Class Term of the owning the       |
|           | corresponding Basic Core Component Property, the         |
|           | *Property Term* of the corresponding class property, and |
|           | the Representation Term of the Data Type any Qualfiying  |
|           | Terms                                                    |
+-----------+----------------------------------------------------------+
| \[DEN17\] | The *Dictionary Entry Name* of an Complex Data Element   |
|           | *Association* shall consist of the following components  |
|           | in the specified order:the Object Class Term of the      |
|           | Complex Data Element owning the corresponding            |
|           | Association Property,the Property Term of the            |
|           | corresponding Association Property, the Object Class     |
|           | Term of the Complex Data Element on which the            |
|           | corresponding Association Core Component Property is     |
|           | based, and Any Qualifying Terms.                         |
+-----------+----------------------------------------------------------+
| \[DEN18\] | The components of a *Dictionary Entry Name* shall be     |
|           | separated by dots. The space character shall separate    |
|           | words in multi-word *Object Class Terms* and/or          |
|           | multi-word *Property Terms*. Every word shall start with |
|           | a capital letter. To allow spell checking of the         |
|           | *Directory Entry Names*' words, the dots after *Object   |
|           | Class Terms* and *Property Terms* shall be followed by a |
|           | space character.                                         |
+-----------+----------------------------------------------------------+
| \[DEN19\] | The name of an *Object Class* shall always have the same |
|           | semantic meaning throughout the dictionary and may       |
|           | consist of more than one word.                           |
+-----------+----------------------------------------------------------+
| \[DEN20\] | The name of a *Property Term* shall occur naturally in   |
|           | the definition and may consist of more than one word. A  |
|           | name of a *Property Term* shall be unique within the     |
|           | *Context* of an *Object Class* but may be reused across  |
|           | different *Object Classes*.                              |
+-----------+----------------------------------------------------------+
| \[DEN21\] | The *Dictionary Entry Name* of an *Complex Data Type*    |
|           | shall consist of a meaningful *Object Class Term*. The   |
|           | *Object Class Term* may consist of more than one word.   |
+-----------+----------------------------------------------------------+

+-----------+-----------------------------------------------------------+
| ## D      |                                                           |
| ocumentat |                                                           |
| ion Rules |                                                           |
+===========+===========================================================+
| \[DOC1\]  | The xsd:documentation element for every Datatype MUST     |
|           | contain a structured set of annotations in the following  |
|           | sequence and pattern:                                     |
|           |                                                           |
|           | -   ComponentType (mandatory): The type of component to   |
|           |     which the object belongs. For Datatypes this must be  |
|           |     "DT".                                                 |
|           |                                                           |
|           | -   DictionaryEntryName (mandatory): The official name of |
|           |     a Datatype.                                           |
|           |                                                           |
|           | -   Version (optional): An indication of the evolution    |
|           |     over time of the Datatype.                            |
|           |                                                           |
|           | -   Definition(mandatory): The semantic meaning of a      |
|           |     Datatype.                                             |
|           |                                                           |
|           | -   ObjectClassQualifier (optional): The qualifier for    |
|           |     the object class.                                     |
|           |                                                           |
|           | -   ObjectClass(optional): The Object Class represented   |
|           |     by the Datatype.                                      |
|           |                                                           |
|           | -   RepresentationTerm (mandatory): A Representation Term |
|           |     is an element of the name which describes the form in |
|           |     which the property is represented.                    |
|           |                                                           |
|           | -   DataTypeQualifier (optional): semantically meaningful |
|           |     name that differentiates the Datatype from its        |
|           |     underlying Core Component Type.                       |
|           |                                                           |
|           | -   DataType (optional): Defines the underlying Core      |
|           |     Component Type.                                       |
+-----------+-----------------------------------------------------------+
| \[DOC2\]  | A Datatype definition MAY contain one or more Content     |
|           | Component Restrictions to provide additional information  |
|           | on the relationship between the Datatype and its          |
|           | corresponding Core Component Type. If used the Content    |
|           | Component Restrictions must contain a structured set of   |
|           | annotations in the following patterns:                    |
|           |                                                           |
|           | -   RestrictionType (mandatory): Defines the type of      |
|           |     format restriction that applies to the Content        |
|           |     Component.                                            |
|           |                                                           |
|           | -   RestrictionValue (mandatory): The actual value of the |
|           |     format restriction that applies to the Content        |
|           |     Component.                                            |
|           |                                                           |
|           | -   ExpressionType (optional): Defines the type of the    |
|           |     regular expression of the restriction value.          |
+-----------+-----------------------------------------------------------+
| \[DOC3\]  | A Qualified Datatype definition MAY contain one or more   |
|           | allowed metadata attribute restrictions to provide        |
|           | additional information on the relationship between the    |
|           | Datatype and its corresponding unqualified Datatype. If   |
|           | used the metadata Restrictions must contain a structured  |
|           | set of annotations in the following patterns:             |
|           |                                                           |
|           | -   MetadataAttributeName (mandatory): Identifies the     |
|           |     metadata attribute on which the restriction applies.  |
|           |                                                           |
|           | -   RestrictionValue (mandatory, repetitive): The actual  |
|           |     value(s) that is (are) valid for the metadata         |
|           |     attribute                                             |
+-----------+-----------------------------------------------------------+
| \[DOC4\]  | The xsd:documentation element for every simple data       |
|           | element MUST contain a structured set of annotations in   |
|           | the following sequence and pattern:                       |
|           |                                                           |
|           | -   DictionaryEntryName (mandatory): The ISO 11179        |
|           |     conformant name.                                      |
|           |                                                           |
|           | -   Version (optional): An indication of the evolution    |
|           |     over time of the simple data element.                 |
|           |                                                           |
|           | -   Definition(mandatory): The semantic meaning of the    |
|           |     simple data element.                                  |
|           |                                                           |
|           | -   Cardinality(mandatory): Indication whether the simple |
|           |     data element represents a not-applicable, optional,   |
|           |     mandatory and/or repetitive characteristic of higher  |
|           |     level aggregates.                                     |
|           |                                                           |
|           | -   ObjectClassQualifier (optional): The qualifier for    |
|           |     the object class.                                     |
|           |                                                           |
|           | -   ObjectClass(mandatory): The Object Class of which the |
|           |     simple data element is a property of.                 |
|           |                                                           |
|           | -   PropertyTermQualifier (optional): The qualifier for   |
|           |     the property term.                                    |
|           |                                                           |
|           | -   PropertyTerm(mandatory): Property Term represents the |
|           |     distinguishing characteristic or Property of the      |
|           |     Object Class and shall occur naturally in the         |
|           |     definition of the simple data element.                |
|           |                                                           |
|           | -   RepresentationTerm (mandatory): A Representation Term |
|           |     describes the form in which the simple data element   |
|           |     is represented.                                       |
|           |                                                           |
|           | -   DataTypeQualifier (optional): semantically meaningful |
|           |     name that differentiates the Qualified Datatype of    |
|           |     the simple data element from its underlying           |
|           |     Unqualified Datatype.                                 |
|           |                                                           |
|           | -   DataType (mandatory): Defines the Datatype used for   |
|           |     the simple data element.                              |
|           |                                                           |
|           | -   AlternativeBusinessTerms (optional): Any synonym      |
|           |     terms under which the Simple data element is commonly |
|           |     known and used in the business.                       |
|           |                                                           |
|           | -   Examples (optional): Examples of possible values for  |
|           |     the Simple data element.                              |
+-----------+-----------------------------------------------------------+
| \[DOC5\]  | The xsd:documentation element for every complex data      |
|           | element representing a class MUST contain a structured    |
|           | set of annotations in the following sequence and pattern: |
|           |                                                           |
|           | -   ComponentType (mandatory): The type of component to   |
|           |     which the object belongs. For classes, this must be   |
|           |     "complex data element".                               |
|           |                                                           |
|           | -   DictionaryEntryName (mandatory): The official name of |
|           |     the complex data element.                             |
|           |                                                           |
|           | -   Version (optional): An indication of the evolution    |
|           |     over time of the complex data element.                |
|           |                                                           |
|           | -   Definition(mandatory): The semantic meaning of the    |
|           |     complex data element.                                 |
|           |                                                           |
|           | -   ObjectClassQualifier (optional): The qualifier for    |
|           |     the object class.                                     |
|           |                                                           |
|           | -   ObjectClass(mandatory): The Object Class represented  |
|           |     by the complex data element.                          |
|           |                                                           |
|           | -   AlternativeBusinessTerms (optional): Any synonym      |
|           |     terms under which the Complex data element is         |
|           |     commonly known and used in the business.              |
+-----------+-----------------------------------------------------------+
| \[DOC6\]  | The xsd:documentation element for every Association       |
|           | Property element declaration MUST contain a structured    |
|           | set of annotations in the following sequence and pattern: |
|           |                                                           |
|           | -   AssociationType (mandatory): The nature of the        |
|           |     association to which the object belongs.              |
|           |                                                           |
|           | -   DictionaryEntryName (mandatory): The official name of |
|           |     the Association Property.                             |
|           |                                                           |
|           | -   Version (optional): An indication of the evolution    |
|           |     over time of the Association Property.                |
|           |                                                           |
|           | -   Definition(mandatory): The semantic meaning of the    |
|           |     Association Property.                                 |
|           |                                                           |
|           | -   Cardinality(mandatory): Indication whether the        |
|           |     Association Property represents an optional,          |
|           |     mandatory and/or repetitive assocation.               |
|           |                                                           |
|           | -   ObjectClass(mandatory): The Object Class containing   |
|           |     the Association Property.                             |
|           |                                                           |
|           | -   PropertyTermQualifier (optional): A qualifier is a    |
|           |     word or words which help define and differentiate the |
|           |     Association Property.                                 |
|           |                                                           |
|           | -   PropertyTerm(mandatory): The nature of the            |
|           |     association between the two complex data elements.    |
|           |                                                           |
|           | -   AssociatedObjectClassQualifier (optional): Associated |
|           |     Object Class Qualifiers describe the \'context\' of   |
|           |     the relationship with another complex data element.   |
|           |                                                           |
|           | -   AssociatedObjectClass (mandatory); Associated Object  |
|           |     Class is the Object Class at the other end of this    |
|           |     association. It represents the child Class contained  |
|           |     by the property of the parent class.                  |
+-----------+-----------------------------------------------------------+

+-----------+----------------------------------------------------------+
| #         |                                                          |
| # Element |                                                          |
|  Declarat |                                                          |
| ion Rules |                                                          |
+===========+==========================================================+
| \[ELD1\]  | Each XML Schema MUST identify one and only one global    |
|           | element declaration that defines the document level      |
|           | container being conveyed in the XML Schema expression.   |
|           | That global element MUST include an xsd:annotation child |
|           | element which MUST further contain an xsd:documentation  |
|           | child element that declares \"*This element MUST be      |
|           | conveyed as the root element in any instance document    |
|           | based on this XML Schema expression.*\"                  |
+-----------+----------------------------------------------------------+
| \[ELD2\]  | All data-centric element declarations MUST be global.    |
|           | All document-centric element declarations SHOULD be      |
|           | global.                                                  |
+-----------+----------------------------------------------------------+
| \[ELD3\]  | For every complex data element identified in the data    |
|           | model, a global element bound to the corresponding       |
|           | xsd:complexType MUST be declared.                        |
+-----------+----------------------------------------------------------+
| \[ELD4\]  | If an association between two complex data elements is   |
|           | unqualified, the association MUST use the global element |
|           | declared for the associated complex data element. If an  |
|           | association between two complex data elements is         |
|           | qualified, a new global element representing the         |
|           | qualified association MUST be declared and used.         |
+-----------+----------------------------------------------------------+
| \[ELD5\]  | For each datatype SimpleType definition, an              |
|           | xsd:restriction element MUST be declared.                |
+-----------+----------------------------------------------------------+
| \[ELD6\]  | Code list xsd:import elements MUST contain the namespace |
|           | and XML Schema location attributes.                      |
+-----------+----------------------------------------------------------+
| \[ELD7\]  | Empty elements MUST not be declared.                     |
+-----------+----------------------------------------------------------+
| \[ELD8\]  | The xsd:any element MUST NOT be used.                    |
+-----------+----------------------------------------------------------+

+---------------+------------------------------------------------------+
| ## General    |                                                      |
|  Naming Rules |                                                      |
+---------------+------------------------------------------------------+
| \[GNR1\]      | XML element, attribute and type names MUST be in the |
|               | English language, using the primary American         |
|               | spellings provided in the Oxford English Dictionary  |
|               | for writers and editors.                             |
+---------------+------------------------------------------------------+
| \[GNR2\]      | XML element, attribute and type names MUST be        |
|               | consistently derived from ISO 11179 conformant       |
|               | dictionary entry names.                              |
+---------------+------------------------------------------------------+
| \[GNR3\]      | XML element, attribute and type names constructed    |
|               | from dictionary entry names MUST NOT include         |
|               | periods, spaces, other separators, or characters not |
|               | allowed by W3C XML 1.0 for XML names.                |
+---------------+------------------------------------------------------+
| \[GNR4\]      | XML element, attribute, and simple and complex type  |
|               | names MUST NOT use acronyms, abbreviations, or other |
|               | word truncations, except those in the list of        |
|               | exceptions published in Appendix XX.                 |
+---------------+------------------------------------------------------+
| \[GNR5\]      | Acronyms and abbreviations MUST only be added to the |
|               | federal approved acronym and abbreviation list after |
|               | careful consideration for maximum understanding and  |
|               | reuse.                                               |
+---------------+------------------------------------------------------+
| \[GNR6\]      | The acronyms and abbreviations listed in Appendix XX |
|               | MUST always be used.                                 |
+---------------+------------------------------------------------------+
| \[GNR7\]      | XML element, attribute and type names MUST be in     |
|               | singular form unless the concept itself is plural.   |
+---------------+------------------------------------------------------+
| \[GNR8\]      | The UpperCamelCase (UCC) convention MUST be used for |
|               | naming elements and types.                           |
+---------------+------------------------------------------------------+
| \[GNR9\]      | The lowerCamelCase (LCC) convention MUST be used for |
|               | naming attributes.                                   |
+---------------+------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ## Gener |                                                           |
| al Type  |                                                           |
| Definiti |                                                           |
| on Rules |                                                           |
+----------+-----------------------------------------------------------+
| \[GTD1\] | All types MUST be named.                                  |
+----------+-----------------------------------------------------------+
| \[GTD2\] | The xsd:anyType MUST NOT be used.                         |
+----------+-----------------------------------------------------------+

+--------+-------------------------------------------------------------+
| ##     |                                                             |
| Genera |                                                             |
| l XML  |                                                             |
| Schema |                                                             |
|  Rules |                                                             |
+========+=============================================================+
| \[     | Data-centric XML Schema MUST conform to the following       |
| GXS1\] | physical layout as applicable:                              |
|        |                                                             |
|        | -   XML Declaration                                         |
|        |                                                             |
|        | -   \<!\-- ===== Copyright Notice ===== \--\>               |
|        |                                                             |
|        | -   Any applicable copyright notice                         |
|        |                                                             |
|        | -   \<!\-- ===== xsd:XML Schema Element With Namespaces     |
|        |     Declarations ===== \--\>                                |
|        |                                                             |
|        | -   xsd:XML Schema element to include version attribute and |
|        |     namespace declarations in the following order:          |
|        |                                                             |
|        | -   xmlns:xsd                                               |
|        |                                                             |
|        | -   Target namespace                                        |
|        |                                                             |
|        | -   Default namespace                                       |
|        |                                                             |
|        | -   CommonComplexElements                                   |
|        |                                                             |
|        | -   CommonSimpleElements                                    |
|        |                                                             |
|        | -   Datatypes                                               |
|        |                                                             |
|        | -   Identifier Schemes                                      |
|        |                                                             |
|        | -   Code Lists                                              |
|        |                                                             |
|        | -   Attribute Declarations --                               |
|        |     elementFormDefault="qualified"                          |
|        |     attributeFormDefault="unqualified"                      |
|        |                                                             |
|        | -   \<!\-- ===== Imports ===== \--\>                        |
|        |                                                             |
|        | -   CommonComplexElements XML Schema module(s)              |
|        |                                                             |
|        | -   CommonSimpleElements XML Schema module(s)               |
|        |                                                             |
|        | -   Unqualified Datatypes XML Schema module(s)              |
|        |                                                             |
|        | -   Qualified Datatypes XML Schema module(s)                |
|        |                                                             |
|        | -   Code and Identifier List XML Schema module(s)           |
|        |                                                             |
|        | -   \<!\-- ===== Global Attributes ===== \--\>              |
|        |                                                             |
|        | -   Global Attributes and Attribute Groups                  |
|        |                                                             |
|        | -   \<!\-- ===== Root Element ===== \--\>                   |
|        |                                                             |
|        | -   Root Element Declaration                                |
|        |                                                             |
|        | -   Root Element Type Definition                            |
|        |                                                             |
|        | -   \<!\-- ===== Element Declarations ===== \--\>           |
|        |                                                             |
|        | -   alphabetized order                                      |
|        |                                                             |
|        | -   \<!\-- ===== Type Definitions ===== \--\>               |
|        |                                                             |
|        | -   All type definitions segregated by simple and complex   |
|        |     as follows                                              |
|        |                                                             |
|        | -   \<!\-- ===== Complex Data Element Type Definitions      |
|        |     ===== \--\>                                             |
|        |                                                             |
|        | -   alphabetized order of Complex Data Element              |
|        |     xsd:complexType definitions                             |
|        |                                                             |
|        | -   \<!\-- =====Simple Data Element Type Definitions =====  |
|        |     \--\>                                                   |
|        |                                                             |
|        | -   alphabetized order of simple data element               |
|        |     xsd:complexType definitions                             |
|        |                                                             |
|        | -   \<!\-- ===== Copyright Notice ===== \--\>               |
|        |                                                             |
|        | -   Required copyright notice.                              |
+--------+-------------------------------------------------------------+
| \[     | Federal and Agency XML Schema should provide two normative  |
| GXS2\] | XML Schemas for each transaction. One XML Schema shall be   |
|        | fully annotated. One XML Schema shall be a run-time XML     |
|        | Schema devoid of documentation.                             |
+--------+-------------------------------------------------------------+
| \[     | Built-in xsd:simpleType SHOULD be used wherever possible.   |
| GXS3\] |                                                             |
+--------+-------------------------------------------------------------+
| \[     | All W3C XML Schema constructs in federal and Agency XML     |
| GXS4\] | Schema and XML Schema modules MUST contain the following    |
|        | namespace declaration on the xsd XML Schema element:        |
|        | xmlns:xsd=\"http://www.w3.org/2001/XMLXML Schema\"          |
+--------+-------------------------------------------------------------+
| \[     | The xsd:SubstitutionGroups feature Should NOT be used In    |
| GXS5\] | data centric XML Schema. If used, it should only be used in |
|        | user defined customization XML Schema or when extending     |
|        | Agency or Federal XSD components.                           |
+--------+-------------------------------------------------------------+
| \[     | The xsd:final attribute SHOULD be used where appropriate to |
| GXS6\] | control undesireable extensions.                            |
+--------+-------------------------------------------------------------+
| \[     | xsd:notations MUST NOT be used.                             |
| GXS7\] |                                                             |
+--------+-------------------------------------------------------------+
| \[     | The xsd:all element MUST NOT be used in data centric XML    |
| GXS8\] | Schema.                                                     |
+--------+-------------------------------------------------------------+
| \[     | The xsd:choice element SHOULD NOT be used where             |
| GXS9\] | customisation and extensibility are a concern.              |
+--------+-------------------------------------------------------------+
| \[G    | The xsd:include feature MUST only be used within a root XML |
| XS10\] | Schema.                                                     |
+--------+-------------------------------------------------------------+
| \[G    | The xsd:union technique MUST NOT be used except for Code    |
| XS11\] | and Identifier Lists. The xsd:union technique MAY be used   |
|        | for Code and Identifier Lists.                              |
+--------+-------------------------------------------------------------+
| \[G    | Federal or Agency XML Schema MUST NOT use xsd:appinfo.      |
| XS12\] |                                                             |
+--------+-------------------------------------------------------------+
| \[G    | Complex Type extension or restriction MAY be used where     |
| XS13\] | appropriate.                                                |
+--------+-------------------------------------------------------------+

+--------+-------------------------------------------------------------+
| ##     |                                                             |
|  Insta |                                                             |
| nce Do |                                                             |
| cument |                                                             |
|  Rules |                                                             |
+--------+-------------------------------------------------------------+
| \[     | All instance documents MUST validate to a corresponding XML |
| IND1\] | Schema.                                                     |
+--------+-------------------------------------------------------------+
| \[     | Instance documents MUST always identify their character     |
| IND2\] | encoding with the XML declaration.                          |
+--------+-------------------------------------------------------------+
| \[     | In conformance with ISO/IETF/ITU/UNCEFACT Memorandum of     |
| IND3\] | Understanding Management Group (MOUMG) Resolution 01/08     |
|        | (MOU/MG01n83), all federal or Agency XML SHOULD be          |
|        | expressed using UTF-8.                                      |
+--------+-------------------------------------------------------------+
| \[     | All instance documents MUST contain the following namespace |
| IND4\] | declaration in the root element:                            |
|        | xmlns:xsi=\"http://www.w3.org/2001/XMLXML Schema-instance\" |
+--------+-------------------------------------------------------------+
| \[     | Data centric instance documents MUST NOT contain an element |
| IND5\] | devoid of content or null values.                           |
+--------+-------------------------------------------------------------+
| \[     | The absence of a construct or data in an instance document  |
| IND6\] | MUST NOT carry meaning.                                     |
+--------+-------------------------------------------------------------+

+---------+------------------------------------------------------------+
| #       |                                                            |
| # Model |                                                            |
| ing Con |                                                            |
| straint |                                                            |
| s Rules |                                                            |
+---------+------------------------------------------------------------+
| \       | Libraries and XML Schemas MUST only use approved           |
| [MDC1\] | datatypes.                                                 |
+---------+------------------------------------------------------------+
| \       | Mixed content MUST NOT be used in data centric XML Schema  |
| [MDC2\] | except where contained in an xsd:documentation element.    |
+---------+------------------------------------------------------------+

+---------+------------------------------------------------------------+
| ## Nam  |                                                            |
| ing Con |                                                            |
| straint |                                                            |
| s Rules |                                                            |
+---------+------------------------------------------------------------+
| \       | Each dictionary entry name MUST define one and only one    |
| [NMC1\] | fully qualified path (FQP) for an element or attribute.    |
+---------+------------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ##       |                                                           |
|  Namespa |                                                           |
| ce Rules |                                                           |
+==========+===========================================================+
| \[NMS1\] | Every XML Schema module, except internal XML Schema       |
|          | modules, MUST have a namespace declared using the         |
|          | xsd:targetNamespace attribute.                            |
+----------+-----------------------------------------------------------+
| \[NMS2\] | Every defined or used XML Schema set version MUST have    |
|          | its own unique namespace                                  |
+----------+-----------------------------------------------------------+
| \[NMS3\] | Federal Namespaces MUST only contain federally developed  |
|          | XML Schema modules                                        |
+----------+-----------------------------------------------------------+
| \[NMS4\] | Agency Namespaces MUST only contain agency developed XML  |
|          | Schema modules                                            |
+----------+-----------------------------------------------------------+
| \[NMS5\] | The namespace names for XML Schemas holding draft status  |
|          | MUST be of the form:                                      |
|          |                                                           |
|          | urn:                                                      |
+----------+-----------------------------------------------------------+
| \[NMS6\] | The namespace names for XML Schemas holding Approved      |
|          | status MUST be of the form:                               |
|          |                                                           |
|          | urn:                                                      |
+----------+-----------------------------------------------------------+
| \[NMS7\] | Published namespaces MUST never be changed.               |
+----------+-----------------------------------------------------------+
| \[NMS8\] | Each Federal and Agency Common Complex Data Elements XML  |
|          | Schema Module MUST reside in its own namespace.           |
+----------+-----------------------------------------------------------+
| \[NMS9\] | Each Federal and Agency Common Complex Data Elements XML  |
|          | Schema Module MUST be represented by the token            |
|          | \"CCD\[agencyid\]\[majorversion\]\[minorversion\]\".      |
+----------+-----------------------------------------------------------+
| \        | Each Federal and Agency Common Simple Data Elements XML   |
| [NMS10\] | Schema Module MUST reside in its own namespace.           |
+----------+-----------------------------------------------------------+
| \        | Each Common Simple Data Elements XML Schema module MUST   |
| [NMS11\] | be represented by the token                               |
|          | \"csd\[agencyid\]\[majorversion\]\[minorversion\]\".      |
+----------+-----------------------------------------------------------+
| \        | Each Federal and Agency Unqualified Datatype XML Schema   |
| [NMS12\] | module MUST reside in its own namespace.                  |
+----------+-----------------------------------------------------------+
| \        | Each Federal and Agency Unqualified Datatype XML Schema   |
| [NMS13\] | module namespace MUST be represented by the token         |
|          | \"udt\[agencyid\]\[majorversion\]\[minorversion\]\".      |
+----------+-----------------------------------------------------------+
| \        | Each Federal and Agency Qualified Datatypes XML Schema    |
| [NMS14\] | module MUST reside in its own namespace.                  |
+----------+-----------------------------------------------------------+
| \        | Each Federal and Agency Qualified Datatypes XML Schema    |
| [NMS15\] | module namespace MUST be represented by the token         |
|          | \"qdt\[agencyid\]\[majorversion\]\[minorversion\]\".      |
+----------+-----------------------------------------------------------+
| \        | Each CodeList XML Schema module MUST be maintained in a   |
| [NMS16\] | separate namespace.                                       |
+----------+-----------------------------------------------------------+

+----------+-----------------------------------------------------------+
| #        |                                                           |
| # Root E |                                                           |
| lement D |                                                           |
| eclarati |                                                           |
| on Rules |                                                           |
+----------+-----------------------------------------------------------+
| \[RED1\] | Every instance document must use the global element       |
|          | defined as the root element in the XML Schema as its root |
|          | element.                                                  |
+----------+-----------------------------------------------------------+

+-------+--------------------------------------------------------------+
| ## XM |                                                              |
| L Sch |                                                              |
| ema S |                                                              |
| truct |                                                              |
| ure M |                                                              |
| odula |                                                              |
| rity  |                                                              |
| Rules |                                                              |
+=======+==============================================================+
| \[S   | Root XML Schema expressions MAY be split into multiple XML   |
| SM1\] | Schema modules.                                              |
+-------+--------------------------------------------------------------+
| \[S   | A root XML Schema in one namespace that is dependent upon    |
| SM2\] | type definitions or element declarations defined in another  |
|       | namespace MUST only import the root XML Schema from that     |
|       | namespace.                                                   |
+-------+--------------------------------------------------------------+
| \[S   | A root XML Schema in one namespace that is dependant upon    |
| SM3\] | type definitions or element declarations defined in another  |
|       | namespace MUST NOT import internal XML Schema modules from   |
|       | that namespace.                                              |
+-------+--------------------------------------------------------------+
| \[S   | All imported XML Schema modules MUST be fully conformant     |
| SM4\] | with the Federal XML naming and design rules.                |
+-------+--------------------------------------------------------------+
| \[S   | XML Schema modules MUST either be treated as external XML    |
| SM5\] | Schema modules or as internal XML Schema modules of the root |
|       | XML Schema.                                                  |
+-------+--------------------------------------------------------------+
| \[S   | All internal XML Schema modules MUST be in the same          |
| SM6\] | namespace as their corresponding root XML Schema.            |
+-------+--------------------------------------------------------------+
| \[S   | Each internal XML Schema module MUST be named ParentXML      |
| SM7\] | SchemaModuleName}{InternalXML SchemaModuleFunction}{XML      |
|       | Schema module}                                               |
+-------+--------------------------------------------------------------+
| \[S   | A XML Schema module defining all Federal Common Complex Data |
| SM8\] | Elements MUST be created.                                    |
+-------+--------------------------------------------------------------+
| \[S   | The Federal Common Complex Data Elements XML Schema module   |
| SM9\] | MUST be named \"fed:Common Complex Data Elements XML Schema  |
|       | Module\"                                                     |
+-------+--------------------------------------------------------------+
| \[SS  | A XML Schema module defining all Federal Common Simple Data  |
| M10\] | Elements MUST be created.                                    |
+-------+--------------------------------------------------------------+
| \[SS  | The Federal Common Simple Data Elements XML Schema module    |
| M11\] | MUST be named \"fed:CommonSimpleDataElements XML Schema      |
|       | Module\"                                                     |
+-------+--------------------------------------------------------------+
| \[SS  | The Federal Qualified Datatypes XML Schema module MUST be    |
| M15\] | named \"fed:Qualified Datatypes XML Schema module\"          |
+-------+--------------------------------------------------------------+
| \[SS  | Agencies MAY create Agency level XML Schema modules for      |
| M16\] | reusable components not included in Federal level XML        |
|       | Schema. Agencies SHOULD submit all Agency reusable           |
|       | components for consideration as Federal level reusable       |
|       | components.                                                  |
+-------+--------------------------------------------------------------+
| \[SS  | A XML Schema module defining Agency **Common Complex Data    |
| M17\] | Elements** MAY be created.                                   |
+-------+--------------------------------------------------------------+
| \[SS  | Agency **Common Complex Data Element** XML Schema modules    |
| M18\] | MUST be named \"**\<agencyToken\>:\<AgencyName\>\            |
|       | CommonComplexDataElements Schema Module**\"                  |
+-------+--------------------------------------------------------------+
| \[SS  | A XML Schema module defining all Agency **Common Simple Data |
| M19\] | Elements** MAY be created.                                   |
+-------+--------------------------------------------------------------+
| \[SS  | Agency **Common Simple Data Elements** XML Schema modules    |
| M20\] | MUST be named \"**fed: \<agencyToken\>:\<AgencyName\>\       |
|       | Common Simple Data Elements Schema Module**\"                |
+-------+--------------------------------------------------------------+
| \[SS  | A XML Schema module defining all Agency Unqualified          |
| M21\] | Datatypes MAY be created.                                    |
+-------+--------------------------------------------------------------+
| \[SS  | Agency Unqualified Datatype XML Schema modules MUST be named |
| M22\] | \"**\<agencyToken\>:\<AgencyName\> Unqualified Datatype      |
|       | Schema Module**\"                                            |
+-------+--------------------------------------------------------------+
| \[SS  | A XML Schema module defining all Agency Qualified Datatypes  |
| M23\] | MAY be created.                                              |
+-------+--------------------------------------------------------------+
| \[SS  | Agency Qualified Datatypes XML Schema modules MUST be named  |
| M24\] | **\<agencyToken\>:\<AgencyName\> Qualified Datatypes schema  |
|       | module**\"                                                   |
+-------+--------------------------------------------------------------+

+---------+------------------------------------------------------------+
| ## Stan |                                                            |
| dards A |                                                            |
| dherenc |                                                            |
| e rules |                                                            |
+---------+------------------------------------------------------------+
| \       | All XML Schema design rules MUST be based on the W3C XML   |
| [STA1\] | Schema Recommendations: XML Schema Part 1: Structures and  |
|         | XML Schema Part 2: Datatypes.                              |
+---------+------------------------------------------------------------+
| \       | All XML Schema and messages MUST be based on the W3C suite |
| [STA2\] | of technical specifications holding recommendation status. |
+---------+------------------------------------------------------------+
| \       | Proprietary extensions to the W3C specifications MUST      |
| [STA3\] | never be used.                                             |
+---------+------------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ##       |                                                           |
|  SimpleT |                                                           |
| ype Nami |                                                           |
| ng Rules |                                                           |
+----------+-----------------------------------------------------------+
| \[STN1\] | Each xsd:simpleType definition name MUST be the datatype  |
|          | dictionary entry name with the separators removed.        |
+----------+-----------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ## Sim   |                                                           |
| pleType  |                                                           |
| Definiti |                                                           |
| on Rules |                                                           |
+----------+-----------------------------------------------------------+
| \[STD1\] | For every datatype whose metadata components map directly |
|          | onto the properties of a built-in xsd:DataType, the       |
|          | datatype MUST be defined as a named xsd:simpleType in the |
|          | fed:unqualifiedDatatype XML Schema module.                |
+----------+-----------------------------------------------------------+

+-----------+----------------------------------------------------------+
| ##        |                                                          |
|  Standard |                                                          |
| s Rquirem |                                                          |
| ents Rule |                                                          |
+-----------+----------------------------------------------------------+
| \[STR1\]  | To ensure conformance with both statutory and policy     |
|           | requirements contained in Public Law 104-113 and Office  |
|           | of Management and Budget Circular A-119, all Federal XML |
|           | implementations must adhere to the following hierarchy   |
|           | of standards in creating and using XML                   |
|           |                                                          |
|           | -   De jure Voluntary Consensus Standards                |
|           |                                                          |
|           | -   Cross-sector Voluntary Consensus Standards           |
|           |                                                          |
|           | -   Sector specific Voluntary Consensus Standards        |
|           |                                                          |
|           | -   Federal Enterprise Wide Standards                    |
|           |                                                          |
|           | -   Agency specific standards                            |
+-----------+----------------------------------------------------------+
| \[STR2\]  | Agencies SHOULD create Agency level policy, procedures   |
|           | and guidance to ensure XML is developed and governed at  |
|           | an enterprise level                                      |
+-----------+----------------------------------------------------------+
| \[STR3\]  | Agencies SHOULD promote Agency level XML components to   |
|           | candidate federal level components and candidate         |
|           | Voluntary Consensus Standards Bodies                     |
+-----------+----------------------------------------------------------+

+----------+-----------------------------------------------------------+
| ##       |                                                           |
| Versioni |                                                           |
| ng Rules |                                                           |
+==========+===========================================================+
| \[VER1\] | Every federal and Agency XML Schema and XML Schema module |
|          | major version committee draft MUST have a document-id of  |
|          | the form                                                  |
|          |                                                           |
|          | \<name\>-\<major\>.0\[.\<revision\>\]                     |
+----------+-----------------------------------------------------------+
| \[VER2\] | Every federal and Agency XML Schema and XML Schema module |
|          | major version Standard MUST have a document-id of the     |
|          | form                                                      |
|          |                                                           |
|          | \<name\>-\<major\>.0                                      |
+----------+-----------------------------------------------------------+
| \[VER3\] | Every minor version XML Schema or XML Schema module draft |
|          | MUST have a document-id of the form                       |
|          |                                                           |
|          | \<name\>-\<major \>.\<non-zero\>\[.\<revision\>\]         |
+----------+-----------------------------------------------------------+
| \[VER4\] | Every minor version XML Schema or XML Schema module       |
|          | Standard MUST have an document-id of the form             |
|          |                                                           |
|          | \<name\>-\<major \>.\<non-zero\>                          |
+----------+-----------------------------------------------------------+
| \[VER5\] | For minor version changes, the name of the version        |
|          | construct MUST NOT change.                                |
+----------+-----------------------------------------------------------+
| \[VER6\] | Every XML Schema and XML Schema module major version      |
|          | number MUST be a sequentially assigned, incremental       |
|          | number greater than zero.                                 |
+----------+-----------------------------------------------------------+
| \[VER7\] | Every XML Schema and XML Schema module minor version      |
|          | number MUST be a sequentially assigned, incremental       |
|          | non-negative integer.                                     |
+----------+-----------------------------------------------------------+
| \[VER8\] | A minor version document XML Schema MUST import its       |
|          | immediately preceding version document XML Schema.        |
+----------+-----------------------------------------------------------+
| \[VER9\] | XML Schema and XML Schema module minor version changes    |
|          | MUST be limited to the use of xsd:extension or            |
|          | xsd:restriction to optionally alter existing types or add |
|          | new constructs.                                           |
+----------+-----------------------------------------------------------+
| \        | XML Schema and XML Schema module minor version changes    |
| [VER10\] | MUST not break semantic compatibility with prior          |
|          | versions.                                                 |
+----------+-----------------------------------------------------------+

# Approved Acronyms and Abbreviations {#approved-acronyms-and-abbreviations .AppendixHeading1}

The following Acronyms and Abbreviations have been approved for Federal
and Agency use:

-   A Dun & Bradstreet Data Universal Numbering System (DUNS) number
    *must* appear as \"DUNS\".

-   \"Identifier\" *must* appear as \"ID\".

-   \"Uniform Resource Identifier\" *must* appear as \"URI\"

-   \[Example\] the \"Uniform Resource. Identifier\" portion of the
    Binary Object. Uniform Resource. Identifier attribute becomes
    \"URI\" in the resulting XML name). The use of URI for Uniform
    Resource Identifier takes precedence over the use of \"ID\" for
    \"Identifier\".

This list will henceforth be maintained by XXX, and additions included
in current and future versions will be maintained and published
separately.

# Metadata Components  {#metadata-components .AppendixHeading1}

Table B-1. Approved Core Component Type Content and Supplementary
Components

  -----------------------------------------------------------------------------
  Name             Primitive   Definition           Remarks
                   data-type                        
  ---------------- ----------- -------------------- ---------------------------
  Amount Currency. String      The Currency Code    Reference UN/ECE Rec. 9,
  Code List.                   List being used.     using 3-letter alphabetic
  Identifier                                        codes. The UN/ECE Rec. 9 is
                                                    also published as ISO 4217,
                                                    but is available in
                                                    electronic form and free of
                                                    charge.

  Amount Currency. string      The *Version* of the 
  Code List                    code list.           
  Version.                                          
  Identifier                                        

  Amount Currency. string      The currency of the  The code identifying the
  Identifier                   amount               currency

  Binary Object.   string      The format of the    
  Format. Text                 binary content.      

  Binary Object.   string      The mime type of the Reference IETF RFC 2045,
  Mime.Code                    binary object.       2046, 2047

  Binary Object.   string      The character set of Reference IETF RFC 2045,
  Character Set.               the binary object if 2046, 2047
  Code                         the mime type is     
                               text.                

  Binary Object.   string      Specifies the        Reference IETF RFC 2045,
  Encoding. Code               decoding algorithm   2046, 2047
                               of the binary        
                               object.              

  Binary Object.   string      The Uniform Resource 
  Uniform                      Identifier that      
  Resource.                    identifies where the 
  Identifier                   Binary Object is     
                               located.             

  Binary Object.   String      The filename of the  Reference IETF RFC 2045,
  Filename. Text               binary object.       2046, 2047

  Code List.       string      An agency that       Defaults to the UN/EDIFACT
  Agency.                      maintains one or     data element 3055 code
  Identifier                   more code lists.     list.

  Code List.       string      The name of the      
  Agency Name.                 agency that          
  Text                         maintains the code   
                               list.                

  Code List. Name. string      The name of a list   
  Text                         of codes.            

  Code List.       string      The identification   Can be used to identify the
  Identifier                   of a list of codes   URL of a source that
                                                    defines the set of
                                                    currently approved
                                                    permitted values

  Code List        string      The Uniform Resource 
  Scheme. Uniform              Identifier that      
  Resource.                    identifies where the 
  Identifier                   code list scheme is  
                               located.             

  Code List.       string      The Uniform Resource 
  Uniform                      Identifier that      
  Resource.                    identifies where the 
  Identifier                   code list is         
                               located.             

  Code List.       string      The *Version* of the Identifies the *Version* of
  Version.                     code list.           the UN/EDIFACT data element
  Identifier                                        3055 code list.

  Code. Name. Text string      The textual          If no code content exists,
                               equivalent of the    the code name can be used
                               code content         on its own

  Date Time.       string      The format of the    Reference ISO 8601 and W3C
  Format. Text                 date/time content    note on date time

  Identification   string      The identification   Defaults to the UN/EDIFACT
  Scheme Agency.               of the agency that   data element 3055 code
  Identifier                   maintains the        list.
                               identification       
                               scheme.              

  Identification   string      The name of the      
  Scheme Agency.               agency that          
  Name. Text                   maintains the        
                               identification       
                               scheme               

  Identification   string      The Uniform Resource 
  Scheme Data.                 Identifier that      
  Uniform                      identifies where the 
  Resource.                    identification       
  Identifier                   scheme data is       
                               located              

  Identification   string      The identification   
  Scheme.                      of the               
  Identifier                   identification       
                               scheme.              

  Identification   string      The name of the      
  Scheme. Name.                identification       
  Text                         scheme.              

  Identification   string      The Uniform Resource 
  Scheme. Uniform              Identifier that      
  Resource.                    identifies where the 
  Identifier                   identification       
                               scheme is located.   

  Identification   string      The *Version* of the Identifies the *Version* of
  Scheme. Version.             identification       the UN/EDIFACT data element
  Identifier                   scheme.              3055 code list.

  Indicator.       String      Whether the          
  Format. Text                 indicator is         
                               numeric, textual or  
                               binary               

  Language.        string      The identifier of    Reference ISO 639: 1998
  Identifier                   the language used in 
                               the corresponding    
                               text string          

  Language.        string      The identification   
  Locale.                      of the locale of the 
  Identifier                   language.            

  Measure Unit.    string      The type of unit of  Reference UN/ECE Rec. 20
  Code                         measure              and X12 355.

  Measure Unit.    string      The *Version* of the 
  Code List                    measure unit code    
  Version.                     list.                
  Identifier                                        

  Numeric. Format. string      Whether the number   
  Text                         is an integer,       
                               decimal, real number 
                               or percentage        

  Quantity. Unit.  string      The unit of the      May use UN/ECE Rec. 20
  Code                         quantity             

  Quantity Unit.   string      The identification   
  Code List                    of the agency which  
  Agency.                      maintains the        
  Identifier                   quantity unit code   
                               list                 

  Quantity Unit.   string      The quantity unit    Defaults to the UN/EDIFACT
  Code List.                   code list.           data element 3055 code
  Identifier                                        list.

  Quantity Unit.   string      The name of the      
  Code List Agency             agency which         
  Name. Text                   maintains the        
                               quantity unit code   
                               list.                
  -----------------------------------------------------------------------------

# Permissible Representation Terms {#permissible-representation-terms .AppendixHeading1}

Table C-1. Permissible Representation Terms

+-----------+---------------------------+-------------+---------------+
| Primary   | Definition                | Related\    | Secondary     |
| Repre     |                           | Unqualified | R             |
| sentation |                           | Datatype    | epresentation |
| Term      |                           |             | Terms         |
+===========+===========================+=============+===============+
| Amount    | A number of monetary      | Amount.     |               |
|           | units specified in a      | Type        |               |
|           | currency where the unit   |             |               |
|           | of currency is explicit   |             |               |
|           | or implied.               |             |               |
+-----------+---------------------------+-------------+---------------+
| Binary    | A set of finite-length    | Binary      | Graphic,      |
| Object    | sequences of binary       | Object.     | Picture,      |
|           | octets.                   | Type        | Sound, Video  |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | *Data Types* representing |             |               |
|           | graphics (i.e. diagram,   |             |               |
|           | graph, mathematical       |             |               |
|           | curves, or similar        |             |               |
|           | representation), pictures |             |               |
|           | (i.e. visual              |             |               |
|           | representation of a       |             |               |
|           | person, object, or        |             |               |
|           | scene), sound, video,     |             |               |
|           | etc.\]                    |             |               |
+-----------+---------------------------+-------------+---------------+
| Code      | A character string        | Code. Type  |               |
|           | (letters, figures or      |             |               |
|           | symbols) that for brevity |             |               |
|           | and / or language         |             |               |
|           | independence may be used  |             |               |
|           | to represent or replace a |             |               |
|           | definitive value or text  |             |               |
|           | of a *Property*.          |             |               |
|           |                           |             |               |
|           | \[Note: The term \'Code\' |             |               |
|           | should not be used if the |             |               |
|           | character string          |             |               |
|           | identifies an instance of |             |               |
|           | an *Object Class* or an   |             |               |
|           | object in the real world, |             |               |
|           | in which case the         |             |               |
|           | *Representation Term*     |             |               |
|           | identifier should be      |             |               |
|           | used.\]                   |             |               |
+-----------+---------------------------+-------------+---------------+
| Date Time | A particular point in the | Date Time.  | Date, Time    |
|           | progression of time (ISO  | Type        |               |
|           | 8601).                    |             |               |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | *Data Types* only         |             |               |
|           | representing a Date or a  |             |               |
|           | Time.\]                   |             |               |
+-----------+---------------------------+-------------+---------------+
| I         | A character string used   | Identifier. |               |
| dentifier | to establish the identity | Type        |               |
|           | of, and distinguish       |             |               |
|           | uniquely, one instance of |             |               |
|           | an object within an       |             |               |
|           | identification scheme     |             |               |
|           | from all other objects    |             |               |
|           | within the same scheme.   |             |               |
+-----------+---------------------------+-------------+---------------+
| Indicator | A list of exactly two     | Indicator.  |               |
|           | mutually exclusive        | Type        |               |
|           | Boolean values that       |             |               |
|           | express the only possible |             |               |
|           | states of a *Property*.   |             |               |
|           |                           |             |               |
|           | \[Note: Values typically  |             |               |
|           | indicate a condition such |             |               |
|           | as on/off; true/false     |             |               |
|           | etc.\]                    |             |               |
+-----------+---------------------------+-------------+---------------+
| Measure   | A numeric value           | Measure.    |               |
|           | determined by measuring   | Type        |               |
|           | an object. Measures are   |             |               |
|           | specified with a unit of  |             |               |
|           | measure. The applicable   |             |               |
|           | unit of measure is taken  |             |               |
|           | from UN/ECE Rec. 20.      |             |               |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | measured coefficients     |             |               |
|           | (e.g. m/s).\]             |             |               |
+-----------+---------------------------+-------------+---------------+
| Numeric   | Numeric information that  | Numeric.    | Value, Rate,  |
|           | is assigned or is         | Type        | Percent       |
|           | determined by             |             |               |
|           | calculation, counting or  |             |               |
|           | sequencing. It does not   |             |               |
|           | require a unit of         |             |               |
|           | quantity or a unit of     |             |               |
|           | measure.                  |             |               |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | *Data Types* representing |             |               |
|           | Ratios (i.e. rates where  |             |               |
|           | the two units are not     |             |               |
|           | included or where they    |             |               |
|           | are the same),            |             |               |
|           | Percentages, etc.)        |             |               |
+-----------+---------------------------+-------------+---------------+
| Quantity  | A counted number of       | Quantity.   |               |
|           | non-monetary units.       | Type        |               |
|           | Quantities need to be     |             |               |
|           | specified with a unit of  |             |               |
|           | quantity.                 |             |               |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | counted coefficients      |             |               |
|           | (e.g. flowers/m²).\]      |             |               |
+-----------+---------------------------+-------------+---------------+
| Text      | A character string (i.e.  | Text. Type  | Name          |
|           | a finite set of           |             |               |
|           | characters) generally in  |             |               |
|           | the form of words of a    |             |               |
|           | language.                 |             |               |
|           |                           |             |               |
|           | \[Note: This              |             |               |
|           | *Representation Term*     |             |               |
|           | shall also be used for    |             |               |
|           | names (i.e. word or       |             |               |
|           | phrase that constitutes   |             |               |
|           | the distinctive           |             |               |
|           | designation of a person,  |             |               |
|           | place, thing or           |             |               |
|           | concept).\]               |             |               |
+-----------+---------------------------+-------------+---------------+

Secondary Representation Terms will also be defined as unqualified
datatypes.

# Technical Terminology {#technical-terminology .AppendixHeading1}

+-------------------------+--------------------------------------------+
| Ad hoc XML Schema       | Doing partial XML Schema processing, but   |
| processing              | not with official XML Schema validator     |
|                         | software; e.g., reading through XML Schema |
|                         | to get the default values out of it.       |
+-------------------------+--------------------------------------------+
| Aggregated Data         | A collection of related pieces of data.    |
| Elements                | Expressed in modeling terms, it is the     |
|                         | representation of an Object Class, in a    |
|                         | specific Business Context.                 |
+-------------------------+--------------------------------------------+
| Application-level       | Adherence to business requirements, such   |
| validation              | as valid account numbers.                  |
+-------------------------+--------------------------------------------+
| Assembly                | Using parts of the library of reusable     |
|                         | components to create a new kind of         |
|                         | business document type.                    |
+-------------------------+--------------------------------------------+
| Business Context        | Defines a context in which a business has  |
|                         | chosen to employ an information entity.    |
+-------------------------+--------------------------------------------+
| Business Object         | An unambiguously identified, specified,    |
|                         | referenceable, registerable and re-useable |
|                         | scenario or scenario component of a        |
|                         | business transaction.                      |
|                         |                                            |
|                         | The term business object is used in two    |
|                         | distinct but related ways, with slightly   |
|                         | different meanings for each usage:         |
|                         |                                            |
|                         | In a business model, business objects      |
|                         | describe a business itself, and its        |
|                         | business context. The business objects     |
|                         | capture business concepts and express an   |
|                         | abstract view of the business's "real      |
|                         | world". The term "modeling business        |
|                         | object" is used to designate this usage.   |
|                         |                                            |
|                         | In a design for a software system or in    |
|                         | program code, business objects reflects    |
|                         | how business concepts are represented in   |
|                         | software. The abstraction here reflects    |
|                         | the transformation of business ideas into  |
|                         | a software realization. The term "systems  |
|                         | business objects" is used to designate     |
|                         | this usage.                                |
+-------------------------+--------------------------------------------+
| business semantic(s)    | A precise meaning of words from a business |
|                         | perspective.                               |
+-------------------------+--------------------------------------------+
| Business Term           | This is a synonym under which a data       |
|                         | element is commonly known and used in the  |
|                         | business. A data element or data element   |
|                         | aggregation may have several business      |
|                         | terms or synonyms.                         |
+-------------------------+--------------------------------------------+
| Class                   | A description of a set of objects that     |
|                         | share the same attributes, operations,     |
|                         | methods, relationships, and semantics. A   |
|                         | class may use a set of interfaces to       |
|                         | specify collections of operations it       |
|                         | provides to its environment. See           |
|                         | interface.                                 |
+-------------------------+--------------------------------------------+
| class diagram           | Shows static structure of concepts, types, |
|                         | and classes. Concepts show how users think |
|                         | about the world; types show interfaces of  |
|                         | software components; classes show          |
|                         | implementation of software components.     |
|                         | (OMG Distilled)                            |
|                         |                                            |
|                         | A diagram that shows a collection of       |
|                         | declarative (static) model elements, such  |
|                         | as classes, types, and their contents and  |
|                         | relationships. (Rational Unified Process)  |
+-------------------------+--------------------------------------------+
|                         |                                            |
+-------------------------+--------------------------------------------+
| Common attribute        | An attribute that has identical meaning on |
|                         | the multiple elements on which it appears. |
|                         | A common attribute might or might not      |
|                         | correspond to an XSD global attribute.     |
+-------------------------+--------------------------------------------+
| Component               | One of the individual entities             |
|                         | contributing to a whole.                   |
+-------------------------+--------------------------------------------+
| Context                 | Defines the circumstances in which a       |
|                         | Business Process may be used.              |
+-------------------------+--------------------------------------------+
| context category        | A group of one or more related values used |
|                         | to express a characteristic of a business  |
|                         | circumstance.                              |
+-------------------------+--------------------------------------------+
| data centric            |                                            |
+-------------------------+--------------------------------------------+
| data element            |                                            |
+-------------------------+--------------------------------------------+
| De facto Standard       |                                            |
+-------------------------+--------------------------------------------+
| De jure VCS             |                                            |
+-------------------------+--------------------------------------------+
| document centric        |                                            |
+-------------------------+--------------------------------------------+
| Root XML Schema         | A XML Schema document corresponding to a   |
|                         | single namespace, which is likely to pull  |
|                         | in (by including or importing) XML Schema  |
|                         | modules.                                   |
+-------------------------+--------------------------------------------+
|                         |                                            |
+-------------------------+--------------------------------------------+
|                         |                                            |
+-------------------------+--------------------------------------------+
| Datatype                | A descriptor of a set of values that lack  |
|                         | identity and whose operations do not have  |
|                         | side effects. Datatypes include primitive  |
|                         | pre-defined types and user-definable       |
|                         | types. Pre-defined types include numbers,  |
|                         | string and time. User-definable types      |
|                         | include enumerations. (XSD)                |
|                         |                                            |
|                         | (ISO 11179)                                |
+-------------------------+--------------------------------------------+
| Generic BIE             | A semantic model that has a "zeroed"       |
|                         | context. We are assuming that it covers    |
|                         | the requirements of 80% of business uses,  |
|                         | and therefore is useful in that state.     |
+-------------------------+--------------------------------------------+
| Instance                | An individual entity satisfying the        |
|                         | description of a class or type.            |
+-------------------------+--------------------------------------------+
| Instance constraint     | Additional validation checking of an       |
| checking                | instance, beyond what XSD makes available, |
|                         | that relies only on constraints            |
|                         | describable in terms of the instance and   |
|                         | not additional business knowledge; e.g.,   |
|                         | checking co-occurrence constraints across  |
|                         | elements and attributes. Such constraints  |
|                         | might be able to be described in terms of  |
|                         | XML Schematron.                            |
+-------------------------+--------------------------------------------+
|                         |                                            |
+-------------------------+--------------------------------------------+
| Intermediate element    | An element not at the top level that is of |
|                         | a complex type, only containing other      |
|                         | elements and attributes.                   |
+-------------------------+--------------------------------------------+
| Internal XML Schema     | A XML Schema module that does not declare  |
| module:                 | a target namespace.                        |
+-------------------------+--------------------------------------------+
| Leaf element            | An element containing only character data  |
|                         | (though it may also have attributes). Note |
|                         | that, because of the XSD mechanisms        |
|                         | involved, a leaf element that has          |
|                         | attributes must be declared as having a    |
|                         | complex type, but a leaf element with no   |
|                         | attributes may be declared with either a   |
|                         | simple type or a complex type.             |
+-------------------------+--------------------------------------------+
| Lower-level element     | An element that appears inside a business  |
|                         | message. Lower-level elements consist of   |
|                         | intermediate and leaf level.               |
+-------------------------+--------------------------------------------+
| Object Class            | The logical data grouping (in a logical    |
|                         | data model) to which a data element        |
|                         | belongs (ISO11179). The *Object Class* is  |
|                         | the part of a *simple or complex data      |
|                         | elements* *Dictionary Entry Name* that     |
|                         | represents an activity or object in a      |
|                         | specific *Context*.                        |
+-------------------------+--------------------------------------------+
| Namespace XML Schema    | A XML Schema module that declares a target |
| module:                 | namespace and is likely to pull in (by     |
|                         | including or importing) XML Schema         |
|                         | modules.                                   |
+-------------------------+--------------------------------------------+
| Naming Convention       | The set of rules that together comprise    |
|                         | how the dictionary entry name for simple   |
|                         | data elements; complex data elements; and  |
|                         | XSD elements, attributes and types are     |
|                         | constructed.                               |
+-------------------------+--------------------------------------------+
| (XML) XML Schema        | An XML Schema consists of components such  |
|                         | as type definitions and element            |
|                         | declarations. These can be used to assess  |
|                         | the validity of well-formed element and    |
|                         | attribute information items (as defined in |
|                         | [\[XML-Infoset                             |
|                         | \]](http://www.w3.org/TR/2004/REC-xmlschem |
|                         | a-1-20041028/#ref-xmlinfo%23ref-xmlinfo)), |
|                         | and furthermore may specify augmentations  |
|                         | to those items and their descendants.      |
+-------------------------+--------------------------------------------+
| XML Schema module       | A collection of XML constructs that        |
|                         | together constitute an XSD conformant XML  |
|                         | Schema. XML Schema modules are intended to |
|                         | be used in combination with other XSD      |
|                         | conformant XML Schema.                     |
+-------------------------+--------------------------------------------+
| XML Schema Processing   | XML Schema validation checking plus        |
|                         | provision of default values and provision  |
|                         | of new infoset properties.                 |
+-------------------------+--------------------------------------------+
| XML Schema Validation   | Adherence to an XSD XML Schema.            |
+-------------------------+--------------------------------------------+
| Semantic                | Relating to meaning in language; relating  |
|                         | to the connotations of words.              |
+-------------------------+--------------------------------------------+
| Top-level element       | An element that encloses a whole business  |
|                         | message. Note that business messages might |
|                         | be carried by messaging transport          |
|                         | protocols that themselves have             |
|                         | higher-level XML structure. Thus, a        |
|                         | top-level element is not necessarily the   |
|                         | root element of the XML document that      |
|                         | carries it.                                |
+-------------------------+--------------------------------------------+
| Type                    | Description of a set of entities that      |
|                         | share common characteristics, relations,   |
|                         | attributes, and semantics.                 |
|                         |                                            |
|                         | A stereotype of class that is used to      |
|                         | specify an area of instances (objects)     |
|                         | together with the operations applicable to |
|                         | the objects. A type may not contain any    |
|                         | methods. See class, instance. Contrast     |
|                         | interface.                                 |
+-------------------------+--------------------------------------------+
| VCS                     | Voluntary Consensus Standards are          |
|                         | standards developed or adopted by          |
|                         | voluntary consensus standards bodies, both |
|                         | domestic and international. These          |
|                         | standards include provisions requiring     |
|                         | that owners of relevant intellectual       |
|                         | property have agreed to make that          |
|                         | intellectual property available on a       |
|                         | non-discriminatory, royalty-free or        |
|                         | reasonable royalty basis to all interested |
|                         | parties. For purposes of this Circular,    |
|                         | \"technical standards that are developed   |
|                         | or adopted by voluntary consensus standard |
|                         | bodies\" is an equivalent term.[^7]        |
+-------------------------+--------------------------------------------+

[^1]: http://colab.cim3.net/cgi-bin/wiki.pl?Enterprise_Architecture_Glossary_Of_Terms#nid2PS5
    http://en.wikipedia.org/wiki/XML_XML SchemaData Reference Model Wiki
    http://colab.cim3.net/cgi-bin/wiki.pl?Enterprise_Architecture_Glossary_Of_Terms#nid2PS5

[^2]: National Technology Transfer and Advancement Act, Public Law
    104-113, March 1996

[^3]: Office of Management and Budget, Circular A119,

[^4]: ebXML, Core Components Technical Specification -- Part 8 of the
    ebXML Technical Framework, V2.0, 11 August 2003

[^5]: http://www.xml.com/pub/a/2001/08/22/uml.html

[^6]: http://xml.gov/documents/completed/lmi/GS301L1_namespace.pdf

[^7]: http://www.whitehouse.gov/omb/circulars/a119/a119.html#4