National Information 
Exchange Model 
Naming and Design Rules 
 
NIEM Technical Architecture Committee (NTAC) 
October 31, 2008 
Version 1.3 


Editors: 

 Webb Roberts, Georgia Tech Research Institute 

 Susan Liebeskind, Georgia Tech Research Institute 

 Mark Kindl, Georgia Tech Research Institute 

Abstract: 

 This document specifies the data model, XML components, and XML data for use with 
the National Information Exchange Model (NIEM) version 2.0. 

Status: 

 This document is a specification for NIEM-conformant XML Schema documents, 
components, and instances. It represents the design that has evolved from the 
collaborative work of the NIEM Business Architecture Committee (NBAC) and the NIEM 
Technical Architecture Committee (NTAC) and their predecessors. 

 This specification is a product of the NIEM Program Management Office (PMO). 

 Send comments on this specification via email to 
nisshelp@ijis.org. 


Record of Changes 

No. 

Date 

Reference: All, Page, 
Table, Figure, 
Paragraph 

A = Add. 
M = Mod. 
D = Del. 

 
Revised By 

Change Description 

1.0 

06/08/2007 

All 

A 

Webb Roberts, 
Susan Liebeskind, 
Mark Kindl 

Initial version 
Internal draft 

1.1 

06/27/2007 

All 

M 

Webb Roberts, 
Susan Liebeskind, 
Mark Kindl 

Internal draft 

1.2 

08/07/2007 

All 

M 

Webb Roberts, 
Susan Liebeskind, 
Mark Kindl 

Public draft 

1.3 

10/31/2008 

All 

M 

NTAC, 
Webb Roberts, 
Mark Kindl 

Final 




Contents 
1 Introduction .............................................................................................................................. 1 
1.1 Scope ............................................................................................................................... 1 
1.2 Audience .......................................................................................................................... 2 
1.3 Document Conventions ................................................................................................... 2 
1.3.1 Document References ......................................................................................... 2 
1.3.2 Normative and Informative Content ................................................................... 2 
1.3.3 Formatting ........................................................................................................... 3 
1.4 Terminology ..................................................................................................................... 4 
1.4.1 RFC 2119 Terminology ........................................................................................ 4 
1.4.2 XML Information Set Terminology ...................................................................... 4 
1.4.3 XML Schema Terminology ................................................................................... 5 
1.4.4 XML Namespace Terminology ............................................................................. 5 
1.5 Document Organization ................................................................................................... 5 
2 NIEM Conformance ................................................................................................................... 6 
2.1 Conformance Targets Overview ...................................................................................... 7 
2.2 Reference Schemas .......................................................................................................... 7 
2.3 IEPD Subset Schemas ....................................................................................................... 8 
2.4 IEPD Extension Schemas and Exchange Schemas............................................................ 9 
2.5 IEPD Constraint Schemas ............................................................................................... 11 
2.6 NIEM-Conformant XML Documents and Elements ....................................................... 12 
3 The NIEM Conceptual Model .................................................................................................. 13 
3.1 NIEM and the RDF Model .............................................................................................. 14 
3.2 NIEM Properties ............................................................................................................. 16 
3.3 Unique Identification of Data Objects ........................................................................... 17 
3.4 NIEM Data Model Is Explicit, Not Implicit ...................................................................... 17 
3.5 NIEM Data Model Implementation in XML Schema ...................................................... 17 
4 Guiding Principles ................................................................................................................... 19 
4.1 Specification Guidelines ................................................................................................. 19 
4.1.1 Keep Specification to a Minimum ..................................................................... 19 
4.1.2 Focus on Rules for Schemas .............................................................................. 20 
4.1.3 Use Specific, Concise Rules ............................................................................... 20 
4.2 XML Schema Design Guidelines ..................................................................................... 20 
4.2.1 Disallow Content Modification With XML Processors ...................................... 20 
4.2.2 Use XML Validating Parsers for Content Validation .......................................... 21 
4.2.3 Validate for Conformance to Reference Schemas ............................................ 21 
4.2.4 Allow Multiple Schemas for XML Constraints ................................................... 21 
4.2.5 Define One Reference Schema Per Namespace ............................................... 22 
4.2.6 Disallow Mixed Content .................................................................................... 22 
4.2.7 Specify Types for All Constructs ........................................................................ 22 
4.2.8 Avoid Wildcards in Reference Schemas ............................................................ 22 
4.2.9 Provide Default Reference Schema Locations .................................................. 23 
4.2.10 Use Open Standards .......................................................................................... 23 
4.3 Modeling Design Guidelines .......................................................................................... 23 
4.3.1 Namespaces Enhance Reuse ............................................................................. 23 
4.3.2 Design NIEM for Extensibility ............................................................................ 24 
4.4 Implementation Guidelines ........................................................................................... 24 
4.4.1 Avoid Displaying Raw XML Data ........................................................................ 24 
4.4.2 Leave Implementation Decisions to Implementers .......................................... 25 
4.5 Modeling Guidelines ...................................................................................................... 25 
4.5.1 Documentation .................................................................................................. 25 
4.5.2 Consistent Naming ............................................................................................ 26 
4.5.3 Reflect the Real World ...................................................................................... 26 
4.5.4 Be Consistent ..................................................................................................... 26 
4.5.5 Reserve Inheritance for Specialization .............................................................. 26 
4.5.6 Do Not Duplicate Definitions............................................................................. 27 
4.5.7 Keep It Simple .................................................................................................... 27 
4.5.8 Be Aware of Scope............................................................................................. 27 
4.5.9 Be Mindful of Namespace Cohesion ................................................................. 28 
5 Relation to Standards.............................................................................................................. 28 
5.1 XML 1.0 .......................................................................................................................... 28 
5.2 XML Namespaces ........................................................................................................... 28 
5.3 XML Schema ................................................................................................................... 29 
5.4 ISO 11179, Part 4 ........................................................................................................... 29 
5.5 ISO 11179, Part 5 ........................................................................................................... 31 
6 XML Schema Design Rules ...................................................................................................... 32 
6.1 Restrictions on XML Schema Constructs ....................................................................... 32 
6.1.1 No Mixed Content ............................................................................................. 33 
6.1.2 No Notations ..................................................................................................... 33 
6.1.3 No Schema Inclusion ......................................................................................... 33 
6.1.4 No Schema Redefinition .................................................................................... 34 
6.1.5 Wildcard Restrictions ........................................................................................ 34 
6.1.5.1 No Unconstrained Type Substitution .................................................... 34 
6.1.5.2 No Unconstrained Text Substitution ..................................................... 34 
6.1.5.3 Untyped Elements Must Be Abstract .................................................... 35 
6.1.5.4 No Untyped Attributes .......................................................................... 35 
6.1.5.5 No Unconstrained Element Substitution .............................................. 35 
6.1.5.6 No Unconstrained Attribute Substitution ............................................. 35 
6.1.6 Component Naming Restrictions ...................................................................... 36 
6.1.6.1 No Anonymous Type Definitions .......................................................... 36 
6.1.6.2 No Local Element Declarations ............................................................. 36 
6.1.6.3 No Local Attribute Definitions .............................................................. 36 
6.1.7 No Uniqueness Constraints ............................................................................... 37 
6.1.8 Model Group Restrictions ................................................................................. 37 
6.1.8.1 Restrictions on Particle Ordering .......................................................... 37 
6.1.8.2 No Recursively Defined Model Groups ................................................. 38 
6.1.8.3 Restrictions on Named Groups ............................................................. 38 
6.1.8.4 Particle Cardinality Restrictions ............................................................ 39 
6.1.9 Block Substitution Restrictions.......................................................................... 39 
6.1.10 Final Value Restrictions ..................................................................................... 40 
6.1.11 Default Value Restrictions ................................................................................. 40 
6.2 xsd:schema Document Element ............................................................................... 41 
6.3 Namespace Imports ....................................................................................................... 42 
6.3.1 xsd:import Element Restrictions ................................................................ 43 
6.3.2 Including XML Content From Other Namespaces ............................................. 44 
6.4 Annotations.................................................................................................................... 45 
6.4.1 Human-Readable Documentation..................................................................... 45 
6.4.2 Machine-Readable Annotations ........................................................................ 46 
6.5 Type Definitions ............................................................................................................. 47 
6.5.1 Complex Type Definitions ................................................................................. 47 
6.5.2 Simple Content (CSC) Restrictions .................................................................... 47 
6.5.3 Complex Content (CCC) Restrictions ................................................................. 49 
6.6 Additional Definitions and Declarations ........................................................................ 50 
6.6.1 Element Declarations ........................................................................................ 50 
6.6.2 Attribute Declarations ....................................................................................... 51 
6.6.3 Attribute Group Definitions .............................................................................. 51 
7 Modeling Rules ....................................................................................................................... 51 
7.1 xsd:schema Document Element Restrictions ........................................................... 52 
7.2 Annotations.................................................................................................................... 53 
7.2.1 Human-Readable Documentation..................................................................... 53 
7.2.2 Machine-Readable Annotations ........................................................................ 57 
7.2.2.1 Deprecation ........................................................................................... 58 
7.2.2.2 Indicating Conformance ........................................................................ 58 
7.2.2.3 Bases of Derived Components .............................................................. 58 
7.2.2.4 Application of Constructs ...................................................................... 60 
7.2.2.5 Targets of References ........................................................................... 61 
7.3 Simple Type Definitions ................................................................................................. 62 
7.4 Complex Type Definitions .............................................................................................. 63 
7.4.1 Object Types ...................................................................................................... 64 
7.4.2 Role Types ......................................................................................................... 64 
7.4.3 Association Types .............................................................................................. 66 
7.4.4 Metadata Types ................................................................................................. 69 
7.4.5 Augmentation Types ......................................................................................... 70 
7.5 Component Usage ......................................................................................................... 72 
7.6 NIEM Structural Facilities ............................................................................................... 73 
7.6.1 Sequence ID ....................................................................................................... 74 
7.6.2 Reference Elements .......................................................................................... 75 
7.7 Using External Schemas ................................................................................................. 78 
7.8 NIEM Subset Schemas ................................................................................................... 81 
7.9 Container Elements ....................................................................................................... 81 
8 XML Instance Rules ................................................................................................................. 83 
8.1 Instance Validation ........................................................................................................ 83 
8.2 Instance Meaning .......................................................................................................... 83 
8.3 Component Representation .......................................................................................... 84 
8.4 Component Ordering ..................................................................................................... 85 
8.5 Instance Metadata ......................................................................................................... 86 
9 Naming Rules .......................................................................................................................... 89 
9.1 Extension of XSD Namespace Simple Types .................................................................. 89 
9.2 Usage of English ............................................................................................................. 90 
9.3 Characters in Names ...................................................................................................... 90 
9.4 Character Case ............................................................................................................... 91 
9.5 Use of Acronyms and Abbreviations ............................................................................. 91 
9.6 Word Forms ................................................................................................................... 93 
9.7 Name Generation .......................................................................................................... 94 
9.8 Object-Class Term .......................................................................................................... 94 
9.9 Property Term ................................................................................................................ 95 
9.10 Qualifier Terms ............................................................................................................. 95 
9.11 Representation Term .................................................................................................... 96 
9.12 NIEM Type Names ....................................................................................................... 100 
9.12.1 All Type Components ...................................................................................... 100 
9.12.2 Simple Type Components ................................................................................ 100 
9.12.3 Code Type Components .................................................................................. 101 
9.12.4 Association Type Components ........................................................................ 101 
9.12.5 Augmentation Type Components ................................................................... 102 
9.12.6 Metadata Type Components ........................................................................... 102 
9.13 NIEM Property Names ................................................................................................ 102 
9.13.1 Attribute Group Names ................................................................................... 102 
9.13.2 Reference Names ............................................................................................ 102 
9.13.3 Association Names .......................................................................................... 103 
9.13.4 Augmentation Names ..................................................................................... 103 
9.13.5 Metadata Names ............................................................................................. 103 
9.13.6 Role Names ...................................................................................................... 103 
Appendix A: NIEM Overview ........................................................................................................ A-1 
Appendix B: Name Syntax for Special Components .................................................................... B-1 
Appendix C: Supporting Schemas ................................................................................................ C-1 
Appendix D: References ............................................................................................................... D-1 
Appendix E: List of Principles ....................................................................................................... E-1 
Appendix F: List of Definitions ..................................................................................................... F-1 
Appendix G: List of Rules ............................................................................................................. G-1 
Appendix H: Index ........................................................................................................................ H-1 
Appendix I: Notices ....................................................................................................................... I-1 

Figures 
Figure 1-1: Example of an XML fragment ...................................................................................... 4 
Figure 3-1: Conceptual class rendered as XML Schema complex type........................................ 17 
Figure 3-2: Conceptual property rendered as element declaration ............................................ 18 
Figure 3-3: Sample fragment of NIEM-conformant data ............................................................. 18 
Figure 3-4: Schema declaration for element nc:ActivityReference .............................. 18 
Figure 3-5: Valid instance for above schema that does NOT conform to NIEM rules ................. 19 
Figure 4-1: Example of the use of a namespace .......................................................................... 24 
Figure 5-1: Example of data definition of MeasureMetadataType ...................................... 30 
Figure 6-1: Example of CSC derived from a simple type .............................................................. 49 
Figure 7-1: A definition that describes mathematical representation ........................................ 55 
Figure 7-2: A definition that describes syntactic representation ................................................ 55 
Figure 7-3: An element definition that constitutes a role without the use of a role type .......... 64 
Figure 7-4: A definition of a role type .......................................................................................... 65 
Figure 7-5: A role type used in an instance.................................................................................. 66 
Figure 7-6: An association in an instance .................................................................................... 67 
Figure 7-7: A definition of an association type ............................................................................ 68 
Figure 7-8: An instance of a name type ....................................................................................... 74 
Figure 7-9: An instance of a name type that uses structures:sequenceID .................... 75 
Figure 7-10: Use of external components to create a NIEM-conformant type ........................... 78 
Figure 8-1: Example of element containment ............................................................................. 84 
Figure 8-2: Example of element reference .................................................................................. 84 
Figure 8-3: Example of metadata used in an instance ................................................................. 87 
Figure 8-4: A metadata type that describes applicability using structures:AppliesTo .. 88 
Figure A-1: The NIEM XML Reference Architecture ................................................................... A-1 
Figure C-1: Schema document element ...................................................................................... C-1 
Figure C-2: Element appinfo:Resource ............................................................................. C-1 
Figure C-3: Element appinfo:Deprecated ......................................................................... C-2 
Figure C-4: Element appinfo:Base ....................................................................................... C-2 
Figure C-5: Element appinfo:ReferenceTarget ............................................................. C-2 
Figure C-6: Element appinfo:AppliesTo ........................................................................... C-3 
Figure C-7: Element appinfo:ConformantIndicator ................................................... C-3 
Figure C-8: Element appinfo:ExternalAdapterTypeIndicator ............................. C-3 
Figure C-9: Full XML Schema for Appinfo Namespace ............................................................... C-4 
Figure C-10: Schema document element ................................................................................... C-5 
Figure C-11: Import of appinfo ............................................................................................... C-5 
Figure C-12: Resource structures:Object ....................................................................... C-5 
Figure C-13: Resource structures:Association ........................................................... C-5 
Figure C-14: Attribute structures:id ................................................................................. C-6 
Figure C-15: Attribute structures:linkMetadata ......................................................... C-6 
Figure C-16: Attribute structures:metadata ................................................................... C-6 
Figure C-17: Attribute structures:ref ............................................................................... C-6 
Figure C-18: Attribute structures:sequenceID .............................................................. C-6 
Figure C-19: Attribute group structures:SimpleObjectAttributeGroup ............. C-7 
Figure C-20: Element structures:Augmentation ........................................................... C-7 
Figure C-21: Element structures:Metadata .................................................................... C-7 
Figure C-22: Complex type structures:AugmentationType ........................................ C-8 
Figure C-23: Type structures:ComplexObjectType .................................................... C-8 
Figure C-24: Type structures:MetadataType ................................................................ C-8 
Figure C-25: Type structures:ReferenceType .............................................................. C-9 
Figure C-26: Full XML Schema for Structures Namespace ........................................................ C-10 
Tables 
Table 2-1: Codes Representing Conformance Targets ................................................................... 7 
Table 7-1: Standard Opening Phrases .......................................................................................... 55 
Table 9-1: Abbreviations Used in NIEM Core Names .................................................................. 92 
Table 9-2: Representation Terms................................................................................................. 97 


 


1 Introduction 

This Naming and Design Rules (NDR) document specifies XML Schema documents for use with 
the National Information Exchange Model (NIEM). NIEM is an information sharing framework 
based on the World Wide Web Consortium (W3C) Extensible Markup Language (XML) Schema 
standard. In February 2005, the U.S. Departments of Justice (DOJ) and Homeland Security (DHS) 
signed a cooperative agreement to jointly develop NIEM by leveraging and expanding the Global 
Justice XML Data Model (GJXDM) into multiple domains. NIEM is a result of a combined 
government and industry effort to improve informationinteroperability and exchange within the 
United States at federal, state, tribal, and local levels of government. 
NIEM specifies a set of reusable information components for defining standard information 
exchange messages, transactions, and documents on a large scale: across multiple communities 
of interest and lines of business. These reusable components are rendered in XML Schema 
documents as type, element, and attribute definitions that comply with the W3C XML Schema 
specification. The resulting reference schemas are available to government practitioners and 
developers at http://niem.gov/. 
The W3C XML Schema standard enables information interoperability and sharing by providing a 
common language for describing data precisely. The constructs it defines are basic metadata 
building blocks � baseline data types and structural components. Users employ these building 
blocks to describe their own domain-oriented data semantics and structures, as well as 
structures for specific information exchanges and components for reuse across multiple 
information exchanges. Rules that profile allowable XML Schema constructs and describe how 
to use them help ensure that those components are consistent and reusable. 
This document specifies principles and enforceable rules for NIEM data components and 
schemas. Schemas and components that obey the rules set forth here are considered to be 
NIEM-conformant. 

1.1 Scope 

This document was developed to specify NIEM 2.0. Later releases of NIEM may be specified by 
later versions of this document. The document covers the following issues in depth: 

� The underlying NIEM data model 

� Guiding principles behind the design of NIEM 

� Rules for using XML Schema constructs in NIEM 

� Rules for modeling and structuring NIEM-conformant schemas 

� Rules for creating NIEM-conformant instances 

� Rules for naming NIEM components 

� Rules for extending NIEM-conformant components 


This document does NOT address the following: 

� A formal definition of the NIEM data model. 

 Such a definition would focus on the Resource Definition Framework (RDF) and concepts 
not strictly required for interoperability. This document instead focuses on definition of 
schemas that work with the data model, to ensure translatability and interoperability. 

� A detailed discussion of NIEM architecture and schema versioning. 

 Such rules will be addressed in [ARCH]. 

� The artifacts of the NIEM information exchange process. 

 The artifacts of the NIEM information exchange process are discussed in [IEPD]. 

This document is intended as a technical specification. It is not intended to be a tutorial or a 
user guide. A brief NIEM overview is provided in Appendix A:NIEM Overview. 

1.2 Audience 

This document targets practitioners and developers who employ NIEM for information 
exchange and interoperability. Such information exchanges may be between or within 
organizations. The NIEM reference schemas provide system implementers much content on 
which to build specific exchanges. However, there is a need for extended and additional 
content. The purpose of this document is to define the rules for such new content so that it will 
be consistent with the NIEM reference schemas. These rules are intended to establish and, 
more important, enforce a degree of standardization on a national level. 

1.3 Document Conventions 

This document uses formatting and syntactic conventions to clarify meaning and avoid 
ambiguity. 

1.3.1 Document References 

This document relies on references to many outside documents. Such references are noted by 
bold, bracketed inline terms. For example, a reference to RFC 2119 is shown as [RFC2119]. All 
reference documents are recorded in Appendix D:References. 

1.3.2 Normative and Informative Content 

This document includes a variety of content. Some content is normative (binding and 
enforceable in implementations), while other content is informative (explanatory, but not part 
of the NIEM specification). In general, the informative material appears as supporting text and 
specific rationales for the normative material. 

Conventions used within this document include: 

[Definition: <term>] 
A formal definition of a term associated with NIEM. 


 Definitions are normative. 

[Principle<number>] 
A guiding principle for NIEM. 
The principles represent the requirements, concepts, and goals that have helped shape the 
NIEM. Principles are informative, not normative, but act as the basis on which the rules are 
defined. 
Accompanying each principle is a short discussion section that justifies the application of the 
principle to NIEM design. 
Principles are numbered in the order in which they appear in the document. 

[Rule<section>-<number>] (<applicability>) 
An enforceable rule for NIEM. 
Rules state specific requirements on artifacts, such as schemas and instances. Most rules 
apply to conformant schemas, while others apply to instances. The rules are normative. 

 Rules are stated using both XML InfoSet terminology (elements and attributes) and XML 
Schema terminology (schema components). The choice of terminology is driven by which 
standard best expresses the rule. Certain concepts are more clearly expressed using XML 
InfoSet information items, others using the XML Schema data model; still others are best 
expressed using a combination of terminology drawn from both standards. 
Rules have rationales that justify the need for the rule. For clarity, there may be multiple 
rules that have the same rationale. 

 Rules and supporting text may use Extended Backus-Naur Form (EBNF) notation as defined 
by [XML]. 
Rules are numbered according to the section in which they appear and the order in which 
they appear within that section. For example, Rule 5-1 is the first rule in Section 5. 

 Each rule is accompanied by a description of its applicability. This identifies the type of 
schema to which the rule applies or indicates whether the rule is applicable to XML 
documents or element information items. Each entry in the list is a code from Table 2-1: 
Codes Representing Conformance Targets. If a code appears in the applicability list for a 
rule, then the rule applies to the corresponding conformance target. The conformance 
targets are defined in Section 2, NIEM Conformance. 

1.3.3 Formatting 

In addition to special formatting for definitions, principles, and rules, this document uses 
consistent formatting to identify NIEM components. 
Courier: All words appearing in Courier font are values, objects, keywords, or literal XML 
text. 


Italics: All words appearing in italics, when not titles or used for emphasis, are special terms 
with definitions appearing in this document. 
Keywords: Keywords reflect concepts or constructs expressed in the language of their source 
standard. Keywords have been given an identifying prefix to reflect their source. The following 
prefixes are used: 

� xsd:identifieskeywords from the W3C XML Schema Definition Language specification. 

� xsi:identifieskeywords from the W3C XML Schema's XML Schema Instance 
specification. 

� structures:identifieskeywords from the NIEM structures namespace. 

� appinfo: identifieskeywords from the NIEM appinfo namespace. 

Throughout the document, fragments of XML Schema or XML instances are used to clarify a 
principle or rule. These fragments are specially formatted in Courier font and appear in text 
boxes. An example of such a fragment follows: 

Figure 1-1: Example of an XML fragment 
<xsd:complexType name="PersonType"> 
... 
</xsd:complexType> 

1.4 Terminology 

This document uses standard terminology to explain the principles and rules that describe 
NIEM. 

1.4.1 RFC 2119 Terminology 

Within normative content (rules and definitions), 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 [RFC2119]. 

1.4.2 XML Information Set Terminology 

This document uses the concepts of element information items (�element�), attribute 
information items (�attribute�), and their associated properties as defined by [XMLInfoSet] with 
clarifications as discussed below. Note that in the clarification that follows, the abstract 
property names appear in square brackets adjacent to the information items to which they 
belong. For example, �Element*parent+� discusses the abstract property �parent� of the 
element information item. 

� parent of an element (Element[parent]) 

 child of an element (Element[children]) 

 Note that the InfoSet properties �Element[parent]� and �Element[children]� correspond 
to a direct, immediate relationship with an element. Children of an element and 


theirchildren, and so on, are collectively referred to as descendants of that element. 
Parents of an element and their parents, and so on, are collectively referred to as 
ancestors of that element. 

� element owning an attribute (Attribute[owner element]) 

 The owner of an attribute is the element that possesses or contains the attribute. 

The use of the term document element from [XMLInfoSet] to describe the root of all elements 
in an XML document is preferred over the informal and nonstandard term root element. 

1.4.3 XML Schema Terminology 

The terms W3C XML Schema, XML Schema (upper case �Schema�), and XSD all refer to the XML 
Schema definition language, as specified in the two-part XML Schema specification: 

� XML Schema Part 1: Structures [XMLSchemaStructures] 

� XML Schema Part 2: Datatypes[XMLSchemaDatatypes] 

The term XML schema (lower case �schema�) refers to specific XML schema documents that 
conform to the XML Schema specifications listed above. 
The terms XML instance and XML document refer to an XML instance document, which is 
defined by and validates to a particular XML schema. 

The term schema component is defined in [XMLSchemaStructures]as a building block for XML 
Schema. This document refers to, rather than restates, the definitions of the different schema 
components associated with the XML Schema Abstract Data Model, which are defined in the 
XML Schema specification. In this document, the name of the referenced schema component 
may appear without the suffix �schema component� (e.g., the term �complex type definition� 
may be used instead of �complex type definition schema component�) to enhance readability of 
the text. 

The term NCName is defined in [XMLSchemaDatatypes] and refers to XML noncolonized names, 
which are XML name strings that do not contain the �:� character. 

1.4.4 XML Namespace Terminology 

This document uses the concept of an XML Namespace as defined by [XMLNamespaces] and 
[XMLNamespacesErrata]. 

1.5 Document Organization 

This remainder of this document is organized into sections as follows: 

� NIEM Conformance describes terminology, requirements, and artifacts related to NIEM 
conformance. 

� The NIEM Conceptual Model discusses the underlying semantic model for NIEM. 

� Guiding Principles discusses the principles that serve as the foundation of and guidelines 
for the rules. 


� Relation to Standards discusses the use of the key standards used in the development of 
NIEM. 

� XML Schema Design Rulesdiscusses the rules for using XML Schema constructs in NIEM-
conformant schemas. 

� Modeling Rules discusses the rules for the additional structures and constraints needed 
to build NIEM-conformant schemas. 

� XML Instance Rulesdiscusses the rules for NIEM-conformant XML instance documents. 

� Naming Rules discusses the rules used in naming NIEM-conformant data components. 

NOTE: The ordering of the sections is intended to minimize the number of forward references in 
the document. For this reason, the naming rules appear as the last section of the document, so 
that the concepts being named have already been discussed. 
This document also contains appendices of reference material as follows: 

� A brief, non-normative overview of NIEM. 

� Indexes of principles, rules, and definitions. 

� Discussion and full listings of the NIEM 2.0 supporting schemas (structures and 
appinfo). 

� An itemized listing of the NIEM 2.0 reference schemas. 

� References to external standard documents. 

2 NIEM Conformance 

This Naming and Design Rules defines NIEM conformance. This definition is performed through 
terminology definitions and rules. Together, these define several classes of schemas, as well as 
defining conformance for XML instances of NIEM-conformant schemas. These classes of 
schemas are defined, along with the definition of NIEM conformance for XML documents, in 
Section 2.1, Conformance Targets, below. The schemas defined therein are NIEM-conformant 
schemas: 

[Definition: NIEM-conformant schema] 
An XML Schema document is a NIEM-conformant schema if and only if it is a reference 
schema, a subset schema, an extension schema, an exchange schema, or a constraint 
schema. 
Neither constraint schemas nor subset schemas serve as the primary (cardinal) definitions for 
components they define. The primary definitions come from reference schemas, exchange 
schemas, and extension schemas. The XML Schema components defined by these schemas are 
NIEM-conformant components. 


[Definition: NIEM-conformant component] 
A NIEM-conformant component is an XML Schema component that is defined by a 
reference schema, an extension schema, or an exchange schema. 
The NIEM support schemas, structuresand appinfo, are considered part of the 
infrastructure of NIEM schemas and are not themselves considered to be NIEM-conformant 
schemas. 

2.1 Conformance Targets Overview 

The sections below define the conformance targets for this document. Each rule in this 
document is applicable to one or more of the conformance targets. 

Throughout the document, each rule definition contains a list of applicable conformance targets 
(as described in Section 1.3.2, Normative and Informative Content, above). The rule is binding 
for the targets on this list. This list is normative. This list uses the following codes: 

Table 2-1: Codes Representing Conformance Targets 

Code 

Conformance target 

REF 

Reference schemas 

SUB 

Subset schemas 

EXT 

Extension and exchange schemas 

CON 

Constraint schemas 

INS 

XML instance data 



Each section below provides a list of rules that apply to its conformance target. These lists are 
informative, not normative. The applicability of a rule to a conformance target is normatively 
specified by the applicability list contained in the rule definition. 
These conformance targets define the scope of the NDR. Anything not on this list of 
conformance targets is explicitly not addressed. 

2.2 Reference Schemas 

A NIEM reference schema is a schema that is intended to be the authoritative definition schema 
for a NIEM namespace. This includes the reference schemas for the NIEM Core schema and 
NIEM domain schemas. 

[Definition: reference schema] 
A reference schema is an XML Schema document that meets all of the following criteria: 

� It is explicitly designated as a reference schema. This may be declared by an IEPD 
catalog or by a tool-specific mechanism outside the schema. 

� It provides the broadest, most fundamental definitions of components in its 
namespace. 


� It provides the authoritative definition of business semantics for components in its 
namespace. 

� It is intended to serve as the basis for components in IEPD schemas, including subset 
schemas, constraint schemas, extension schemas, and exchange schemas. 

� It satisfies all rules specified in the Naming and Design Rules for reference schemas. 

Any schema that defines components that are intended to be incorporated into NIEM Core or a 
NIEM domain may be defined as a reference schema. 
The rules for reference schemas are more stringent than are the rules for other classes of NIEM-
conformant schemas. Reference schemas are intended to support the broadest reuse. They are 
very uniform in their structure. As they are the primary definitions for data components, they 
do not need to restrict other data definitions, and they are not allowed to use XML Schema's 
restriction mechanisms. Reference schemas are intended to be as regular and simple as 
possible. 
The following rules apply to reference schemas: 

� All rules in Section 5 

� All rules in Section 6, except [Rule 6-20] through [Rule 6-22] and [Rule 6-57] 

� All rules in Section 7, except [Rule 7-69] and [Rule 7-70] 

� [Rule 8-7] 

� All rules in Section 9 

2.3 IEPD Subset Schemas 

[Definition: subset schema] 
A subset schema is an XML Schema document that meets all of the following criteria: 

� It is explicitly designated as a subset schema. This may be declared by an IEPD 
catalog or by a tool-specific mechanism outside the schema. 

� It has a target namespace previously defined by a reference schema. That is, it does 
not provide original definitions for schema components, but instead provides an 
alternate schema representation of components that are defined by a reference 
schema. 

� It does not alter the business semantics of components in its namespace. The 
reference schema defines these business semantics. 

� It is intended to express the limited vocabulary necessary for an IEPD and to support 
XML Schema validation for an IEPD. 

� It satisfies all rules specified in the Naming and Design Rules for subset schemas. 

A subset schema is based on another NIEM-conformant schema: a reference schema. A subset 
schema is defined such that any valid instance of the subset schema is also a valid instance of 


the base (reference) schema. This means that a subset schema is not allowed to introduce new 
content, nor is it allowed to extend the data content defined by a component of the reference 
schema. 
For example, a subset schema would not be allowed to introduce a new U.S. state (e.g., "West 
Michigan") into a list of states defined by the reference schema. Any XML instance that 
included the new state would validate against the supposed subset schema but would not 
validate against the reference schema. This would violate the basic premise underlying the use 
of subsets: subsets must be as restrictive as or more restrictive than the reference schema. 
A subset schema may omit any construct of the base schema that has no effect on schema 
validation, including xsd:documentation and xsd:appinfo annotations. The reference 
schema on which a subset schema is based is considered the authoritative source of such 
annotations. 
The following rules apply to subset schemas: 

� All rules in Section 5, except [Rule 5-4] 

� All rules in Section 6, except [Rule 6-16], [Rule 6-20] through [Rule 6-22], [Rule 6-26], 
[Rule 6-27], [Rule 6-46], [Rule 6-47], [Rule 6-49] through [Rule 6-51], [Rule 6-53], [Rule 6-
55], and [Rule 6-57] 

� In Section 7, [Rule 7-2], [Rule 7-3], [Rule 7-37], [Rule 7-38], [Rule 7-40], [Rule 7-42] 
through [Rule 7-44], [Rule 7-47], [Rule 7-48], [Rule 7-51] through [Rule 7-53], [Rule 7-55] 
through [Rule 7-59], [Rule 7-64], [Rule 7-65], [Rule 7-68] through [Rule 7-70] 

� All rules in Section 9 

2.4 IEPD Extension Schemas and Exchange Schemas 

[Definition: extension schema] 
An extension schema is an XML Schema document that meets all of the following criteria: 

� It is explicitly designated as an extension schema. This may be declared by an IEPD 
catalog or by a tool-specific mechanism outside the schema. 

� It provides the broadest, most fundamental definitions of components in its 
namespace. 

� It provides the authoritative definition of business semantics for components in its 
namespace. 

� It contains components that, when appropriate, use or are derived from the 
components in reference schemas or exchange schemas. When a reference schema 
contains relevant components, it is preferred to an exchange schema. 

� It is intended to express the additional vocabulary required for an IEPD, above and 
beyond the vocabulary available from reference schemas, and to support XML 
Schema validation for an IEPD. 


� It satisfies all rules specified in the Naming and Design Rules for extension schemas. 

[Definition: exchange schema] 
An exchange schema is an XML Schema document that meets all of the following criteria: 

� It is explicitly designated as an exchange schema. This may be declared by an IEPD 
catalog or by a tool-specific mechanism outside the schema. 

� It provides the broadest, most fundamental definitions of components in its 
namespace. 

� It provides the authoritative definition of business semantics for components in its 
namespace. 

� It contains components that use or are derived from the components in reference 
schemas or exchange schemas. 

� It is intended to identify and define the document element information item for a 
particular information exchange that is described by an IEPD. 

� It satisfies all rules specified in the Naming and Design Rules for exchange schemas. 

An extension schema in an IEPD serves several functions. First, it defines new content within a 
new namespace, which may be an IEPD-specific namespace or a namespace shared by several 
IEPDs. This content is NIEM-conformant but has fewer restrictions on it than do NIEM reference 
schemas. Second, the extension schema bases its content on content from NIEM reference 
schemas, where appropriate. Methods of deriving content include using (by reference) existing 
components, as well as creating extensions and restrictions of existing components. 
For example, an IEPD may create a type for an IEPD-specific phone number and base that type 
on a type defined by the NIEM Core reference schema. This IEPD-specific phone number type 
may restrict the NIEM Core type to limit those possibilities that are permitted of the base type. 
IEPD extensions and restrictions must include annotations and documentation to be 
conformant, but they are allowed to use restriction, choice, and some other constructs that are 
not allowed in NIEM reference schemas. 
Note that IEPDs may define schemas that meet the criteria of reference schemas for those 
components that the IEPD wishes to nominate for inclusion in NIEM Core or in domains. 
The following rules apply to extensions and exchange schemas: 

� All rules in Section 5 

� All rules in Section 6, except [Rule 6-11], [Rule 6-18], [Rule 6-19], [Rule 6-29] through 
[Rule 6-31], [Rule 6-53], and [Rule 6-55] 

� All rules in Section 7, except [Rule 7-69] and [Rule 7-70] 

� [Rule 8-7] 

� All rules in Section 9 


2.5 IEPD Constraint Schemas 

[Definition: constraint schema] 
A constraint schema is an XML Schema document that meets all of the following criteria: 

� It is explicitly designated as a constraint schema. This may be declared by an IEPD 
catalog or by a tool-specific mechanism outside the schema. 

� It contains XML Schema components that exist for the purpose of (1) determining 
schema-validity of XML documents according to some criteria not easily expressed in 
other classes of schema documents, and (2) expressing those criteria in the XML 
Schema definition language. 

� It has a target namespace previously defined by a reference schema, extension 
schema, or exchange schema, or it is intended to support a constraint schema that 
does have such a target namespace. 

� It is intended to express business rules for a class of XML documents, not the 
semantics of those XML documents. 

� It satisfies all rules specified in the Naming and Design Rules for constraint schemas. 

Constraint schemas provide a mechanism within an IEPD by which the IEPD may use the XML 
Schema definition language to describe business rules for NIEM-conformant reference schemas. 
A constraint schema need not express the complete syntax for any class of XML documents. 
Schema-validity should be assessed using reference or subset schemas as well as constraint 
schemas. 
A constraint schema is not assumed to be a definitive definition for the components it 
describes. Instead, a constraint schema uses the XML Schema definition language to add 
constraints and restrictions to components defined by other schemas. 
A constraint schema may be used in tandem with a reference schema, extension schema, or 
exchange schema to enable validation of specific business rules. Or, a broader constraint 
schema, which adds constraints to the rules defined by the reference schemas, may be defined 
for an IEPD. Such a schema may be used as the sole yardstick for validation of the namespace, 
but combining IEPD constraints with the base schemas may make those constraints harder to 
understand and reuse later. 
Constraint schemas have far fewer requirements than other forms of schema. As they are 
expected to work in tandem with normative schemas, they are allowed to use the XML Schema 
language however necessary to express business rules. 
The following rules apply to constraint schemas: 

� In Section 5, [Rule 5-1] through [Rule 5-3] 

� In Section 6, [Rule 6-33], [Rule 6-34], and [Rule 6-35] through [Rule 6-38] 

� In Section 7, [Rule 7-2] and [Rule 7-3] 


2.6 NIEM-Conformant XML Documents and Elements 

This document has specific rules about how NIEM content should be used in XML documents. 
As well as containing rules for XML Schema documents, this NDR contains rules for NIEM-
conformant XML content at a finer granularity than the XML document. 

[Definition: NIEM-conformant XML document] 
A NIEM-conformant XML document is an XML document that satisfies all of the following 
criteria: 

� The document element is locally schema-valid. 

� Each element information item within the XML document that has a namespace 
name matching the target namespace of a reference schema, extension schema, or 
exchange schema is a NIEM-conformant element information item. 

In this definition and the next definition below, the term XML document is as specified in [XML]. 
The terms document information item, document element, element information item, 
namespace name, and local name are as specified in [XMLInfoSet]. The term valid is as 
specified in [XMLSchemaStructures]. 
Schema-validity may be assessed against a single set of schemas or against multiple sets of 
schemas. Assessment against schemas is as directed by an IEPD, other instructions, or tools. 
Note that the document element (root element) of a NIEM-conformant XML document is not 
required to be a NIEM-conformant element information item. Other specifications, such as the 
IEPD specification, may add additional constraints to these to specify IEPD or exchange 
conformance. 

[Definition: NIEM-conformant element information item] 
A NIEM-conformant element information item is an element information item that satisfies 
all of the following criteria: 

� Its namespace name and local name matches an element declared by a reference 
schema, extension schema, or exchange schema. 

� It occurs within a NIEM-conformant XML document. 

� It is locally schema-valid. 

� It satisfies all rules specified in the Naming and Design Rules for NIEM-conformant 
element information items. 

Because each NIEM-conformant element information item must be locally schema-valid, each 
element must validate against the schema definition of the element, even if the element 
information item is allowed within the document because of a wildcard with 
processContents of "skip". Within a NIEM-conformant XML document, each element 
that is from a NIEM namespace conforms to its schema specification. 

NDR rules apply to element information items with respect to the reference schemas for the 
relevant namespaces. For example, when applying a rule concerning the applicability of an 


augmentation element to a type, the definitions as specified in the reference schema are 
relevant, but definitions in other schemas, such as subset and constraint schemas, are not 
considered. Such applicability is likely not indicated by subset and constraint schemas, but 
extension schemas are required to contain sufficient definitions for proper validation of NIEM-
conformant instances. 
The following rules apply to NIEM-conformant element information items: 

� In Section 7, [Rule 7-55] 

� All rules in Section 8 

3 The NIEM Conceptual Model 

The NIEM provides a concrete data model, in the form of a set of XML Schema documents. 
These schemas may be used to build messages and information exchanges. The schemas spell 
out what kinds of objects exist and how those objects may be related. XML data that follows 
the rules of NIEM imply specific meaning. The varieties of XML Schema components used 
within NIEM-conformant schemas are selected to clarify the meaning of XML data. That is, 
schema components that do not have a clear meaning have been avoided. NIEM provides a 
framework within which XML data has a specific meaning. 
One limitation of XML and XML Schema is that they do not describe the meaning of an XML 
document. The XML specification defines XML documents and defines their syntax but does not 
address the meaning of those documents. The XML Schema specification defines the XML 
Schema definition language, which describes the structure and constrains the contents of XML 
documents (schemas). 
In a schema, the meaning of a schema component (e.g., element, attribute, or type) may be 
described using the xsd:documentation element. Or, additional information may be 
included via the xsd:appinfo element. Although this may enable humans to understand 
XML data, more information is needed to support the machine-understandable meaning of XML 
data. In addition, inconsistency among the ways that schema components may be put together 
may be a source of confusion. 

The RDF Core Working Group of the World Wide Web consortium has developed a simple, 
consistent conceptual model, the RDF model. The RDF model is described and specified 
through a set of W3C Recommendations, the Resource Description Framework (RDF) 
specifications, making it a very well-defined standard. The NIEM model and the rules contained 
in this NDR are based on the RDF model. This provides numerous advantages: 

� NIEM's conceptual model is defined by a recognized standard. 

� NIEM's conceptual model is very well defined. 

� NIEM's conceptual model provides a consistent basis for relating attributes, elements, 
types, and other XML Schema components. 


� NIEM's use of the RDF model defines what a set of NIEM data means. The RDF 
specification provides a detailed description of what a statement means (see 
[RDFSemantics]), and this is leveraged by NIEM. 

� NIEM's use of the RDF model provides a basis for inferencing and reasoning about XML 
data that uses NIEM. That is, using the rules defined for the RDF model, programs can 
determine implications of relationships between NIEM-defined objects. 

With the exception of Section 2, NIEM rules are explained in this document without reference 
to RDF or RDF concepts. Understanding RDF is not required to understand NIEM-conformant 
schemas or data based on NIEM. However, understanding RDF concepts may deepen 
understanding of NIEM. 
The goal of this section is to clarify the meaning of XML data that is NIEM-conformant and to 
outline the implications of various modeling constructs in NIEM. The rules for NIEM-
conformant schemas and instances are in place to ensure that a specific meaning can be derived 
from data. That is, the data makes specific assertions, which are well understood since they are 
derived from the rules for NIEM. 
The key concepts underpinning the NIEM conceptual model are discussed in the remainder of 
this section: 

� NIEM and the RDF Model 

� NIEM Properties 

� Unique Identification of Data Objects 

� NIEM Data Model Is Explicit, Not Implicit 

� NIEM Data Model Implementation in XML Schema 

3.1 NIEM and the RDF Model 

NIEM has its foundation in the RDF model. This helps to ensure that NIEM-conformant data has 
precise meaning. The RDF view of what data means is clarified by [RDFSemantics]: 
... asserting a sentence makes a claim about the world. . . an assertion amounts to 
stating a constraint on the possible ways the world might be. 
The RDF view of the meaning of data carries into NIEM: NIEM elements form statements that 
make claims about the world: that a person has a name, a residence location, a spouse, etc. 
The assertion of one set of facts does not necessarily rule out other statements: A person could 
have multiple names, could have moved, or could be divorced. Each statement is a claim 
asserted to be true by the originator of the statement. 

This NDR discusses NIEM data in terms of objects, a term more accessible than the word used 
by RDF, resources. RDF defines the world in terms of resources. [RDFSemantics] describes 
what may constitute a resource: 


 ...no assumptions are made here about the nature of resources; "resource"is treated 
here as synonymous with "entity," i.e., as a generic term for anything in the universe of 
discourse. 
RDF resources coincide with NIEM objects and associations. That is, both objects and 
associations in NIEM are RDF resources with the additional constraints: 

� A NIEM object or association is an instance of a complex type defined by an XML Schema 
document. 

� The XML Schema document that defines a NIEM object is a NIEM-conformant schema. 

NIEM associations are defined as n-ary properties as described in [N-ary], use case 3. NIEM 
object types are defined in Section 7.4.1, Object Types. NIEM associations are defined in 
Section 7.4.3, Association Types. Assertions are made via NIEM-conformant XML data, 
described by Section 8, XML Instance Rules. 

The XML Schema types that define NIEM objects and associations are related to each other via 
elements and attributes. That is, a type contains elements and attributes, and an element or 
attribute has a value that is an instance of an XML Schema type. In NIEM, these elements and 
attributes are XML Schema representations of RDF properties, which are described by 
[RDFPrimer], "2.1 Basic Concepts": 
"RDF is based on the idea that the things being described have properties which have 
values, and that resources can be described by making statements. . .that specify those 
properties and values." 
This describes how NIEM works: schemas describe things and their properties. NIEM-
conformant data specifies objects, the values of their properties, and the relationships between 
them. 

There are several kinds of assertions that may be made with NIEM-conformant data. Examples 
include: 

� An assertion that an object exists. An occurrence of an element commonly establishes 
the existence of an object. Such an object may be tangible or intangible. For example, 
the element nc:Personin an exchange implies that a person does or did exist. An 
element may also express that an object does not exist (e.g., the license plate ABC123 
was never issued), but this is an uncommon case. 

 Descriptions of objects may carry an implicit assumption that objects exist. Such an 
assumption is dependent on the message in which such descriptions are made. If an 
object that is described does not exist, it should be made explicit in the definition of an 
element containing or referring to the object. 

� An assertion that an object has a characteristic. A feature or quality of an object is 
commonly represented by an element appearing within the element that establishes the 
object. For example, the height of a person is described by the 
nc:PersonHeightMeasure element. The nc:PersonHeightMeasureelement 


occurs as XML content of the nc:Person element. In some cases, a characteristic may 
be represented by an attribute owned by an element. 

� An assertion that an object participates in a relationship. A relationship between 
objects may be established in any of several ways: 

� Both objects may be referenced from an association that establishes the 
relationship. Associations are also useful for expressing n-ary relationships, as well 
as relationships supported by additional data. 

� An element may occur within one object that indicates the relationship with the 
other object. This element may be either a content element or a reference element. 

 The NIEM Core schema and some domain schemas have been normalized such that 
a minimum number of reference or content elements establish relationships. In 
these cases, use of an association is the more common method for establishing a 
relationship. However, in an exchange, using a reference or content element to 
express a relationship may be the simpler, preferred method for expressing a 
relationship. 

3.2 NIEM Properties 

NIEM-conformant data describes characteristics of objects and relationships between objects. 
In RDF, these characteristics and relationships are called properties of objects, which is also how 
NIEM refers to them. NIEM represents properties with element declarations and attribute 
declarations. 
Within data, a property relates XML data much as a verb relates nouns in a sentence: a verb has 
a subject and an object. 

� The property itself: What relationship is being asserted? For example, the property may 
say that a weapon has a user, or that someone has hair of a particular color. 

� The subject: About what object is the property being asserted? This would be the 
weapon that has the user, or the person whose hair is being described. 

� The object: What is the value of the property, or with what other object does the 
relationship exist? This would be the person who is the user of the weapon or the 
person whose hair has the color brown. 

A property relates two objects. Data will describe an object having a characteristic with a 
specific value or will describe an object with a particular relationship to another object. All 
properties are pair-wise: between two objects, or between an object and a value. 
In theory, any relationship that involves more than two objects may be modeled as a set of 
binary properties. In NIEM, such relationships may be expressed either as a set of properties 
(i.e., as element and attribute declarations) or as a complex type defining an association. 


3.3 Unique Identification of Data Objects 

In NIEM, an exchange is generally adhoc. That is, a message may be generated without any 
persistence. It exists only to exchange data and may not have any universal meaning beyond 
that specific exchange. As such, a message may or may not have a URI as an identifier. NIEM 
was designed with the assumption that a given exchange need not have any unique identifier; 
NIEM does not require a unique identifier. NIEM also does not require any object (data 
instance) to be identified by a URI. This differs from RDF, in which all entities (other than literal 
values) are identified by globally meaningful URIs. 
A NIEM-conformant instance uses XML IDsto identify objects within an XML document; The 
NIEM XML ID is an attribute structures:id of type xsd:ID. These IDs are not assumed by 
NIEM to have any universal significance; they need only be unique within the XML document. 
The use of an ID is required only when an object must be referenced within the document. 
NIEM recognizes no correlation between these local IDs and any URI. 
Any given implementation, message, or IEPD may be defined to apply a URI or other universally 
meaningful identifier to an object or message. However, NIEM has no such requirement. 

3.4 NIEM Data Model Is Explicit, Not Implicit 

In NIEM data, that which is not stated is not implied. If data says a person's name is "John," it is 
not implicitly saying that he does not have other names, or that �John� is his legal name, or that 
he is different from a person known as �Bob.� The only assertion being made is that one of the 
names by which this person is known is "John." 
This is one reason that definitions of NIEM content are so important. The definitions must state 
exactly what any given statement implies. The concept of "legal name" may be defined that 
makes additional assertions about a name of a person. Such assertions must be made explicit in 
the definition of the relationship. 

3.5 NIEM Data Model Implementation in XML Schema 

NIEM defines rules for XML Schema documents that enforce the NIEM conceptual model. The 
schemas that follow these rules are referred to as NIEM-conformant schemas. 
As discussed above, NIEM classes and properties are mapped onto XML Schema components. 
The following is an example of how a NIEM class for �Person� is rendered as an XML Schema 
complex type definition: 

Figure 3-1: Conceptual class rendered as XML Schema 
complex type 
<xsd:complexType name="PersonType"> 
... 
</xsd:complexType> 


The following is an example of how a NIEM property for �ImageOperator� is rendered as an 
element declaration: 

Figure 3-2: Conceptual property rendered as element 
declaration 
<xsd:element name="ImageOperator" type="nc:PersonType" nillable="true"> 
... 
</xsd:element> 

NIEM also defines rules for XML documents that enforce the NIEM conceptual model. An XML 
document is called a NIEM-conformant XML document if it follows the rules specified by the 
NIEM-conformant schema, as well as additional rules that are NIEM-specific. For example, in a 
NIEM-conformant XML document, a reference element must refer to a data element that is of 
an appropriate XML Schema type. If this is not the case, the document may be valid according 
to the schema, but it will not be NIEM-conformant. 

Figure 3-3: Sample fragment of NIEM-conformant data 
<nc:Person> 
<nc:PersonHairColorCode>BRN</nc:PersonHairColorCode> 
</nc:Person> 
Based on an element declaration from NIEM Core, the following example illustrates a valid 
XML instance that does not conform to NIEM. Per the appinfo:ReferenceTarget 
element in the schema declaration, nc:ActivityReference may ONLY refer to an 
nc:ActivityType. However, within the instance, 
my:ActivityList/nc:ActivityReference refers to �Bill,� which is an 
nc:PersonType. 

Figure 3-4: Schema declaration for element 
nc:ActivityReference 
<xsd:element name="ActivityReference" type="structures:ReferenceType"> 
<xsd:annotation> 
<xsd:documentation> 
A single or set of related actions, events, or process steps. 
</xsd:documentation> 
<xsd:appinfo> 
<appinfo:ReferenceTarget appinfo:name="ActivityType"/> 
</xsd:appinfo> 
</xsd:annotation> 
</xsd:element 


Figure 3-5: Valid instance for above schema that does 
NOT conform to NIEM rules 
<nc:Person structures:id=�Bill�> 
<nc:PersonFullName>William Tell</nc:PersonFullName> 
<nc:PersonSexCode>M</nc:PersonSexCode> 
</nc:Person> 
<nc:Activity structures:id=�Pie�> 
<nc:ActivityDescriptionText> 
County fair pie-eating contest 
</nc:ActivityDescriptionText> 
</nc:Activity> 
<my:ActivityList> 
<nc:ActivityReference structures:ref=�Pie�/> 
<nc:ActivityReference structures:ref=�Bill�/> 
</my:ActivityList> 

4 Guiding Principles 

Principles in this specification provide a foundation for the rules. These principles are generally 
applicable in most cases. They should not be used as a replacement for common sense or 
appropriate special cases. 
The principles are not operationally enforceable; they do not specify constraints on XML 
Schema documents and instances. The rules are the normative and enforceable manifestation 
of the principles. 
The principles discussed in this section are categorized as follows: 

� Specification Guidelines 

� XML Schema Design Guidelines 

� Modeling Design Guidelines 

� Implementation Guidelines 

4.1 Specification Guidelines 

The principles in this section address what material should be included in this NDR and how it 
should be represented. 

4.1.1 Keep Specification to a Minimum 

This specification should state what is required for interoperability, not all that could be 
specified. Certain decisions (such as normative XML comments) could create roadblocks for 
interoperability, making heavy demands on systems for very little gain. The goal is not 
standardization for standardization�s sake. The goal is to maximize interoperability and reuse. 


[Principle 1] 

 This specification SHOULD specify what is necessary for semantic interoperability and no 
more. 

The term semantic interoperability is here defined as "the ability of two or more computer 
systems to exchange information and have the meaning of that information automatically 
interpreted by the receiving system accurately enough to produce useful results." 

4.1.2 Focus on Rules for Schemas 

This specification should try, as much as is possible, to specify schema-level content. This is a 
specification for schemas, and so it should specify schemas. It should avoid specifying complex 
data models or data dictionaries. 

[Principle 2] 

 This specification SHOULD focus on providing rules for specifying schemas. 

4.1.3 Use Specific, Concise Rules 

A rule should be as precise and specific as possible to avoid broad, hard-to-modify rules. 
Putting multiple clauses in a rule makes it harder to enforce. Using separate rules allows 
specific conditions to be clearly stated. 

[Principle 3] 

 This specification SHOULD feature rules thatare as specific, precise, and concise as 
possible. 

4.2 XML Schema Design Guidelines 

The principles in this section address how XML Schema technology should be used in designing 
NIEM-conformant schemas and instances. 

4.2.1 Disallow Content Modification With XML Processors 

XML Schema has constructs that can make the data provided by XML processors different 
before and after schema processing. Anexample of this is the use of XML Schema attribute 
declarations with default values. Before schema validation, there may be no attribute value, but 
after processing, the attribute value exists. 
Within NIEM, the purpose of processing instances against schemas is solely validation: testing 
that data instances match desired constraints and guidelines. It should not be used to change 
the content of data instances. 

[Principle 4] 

 The content of a NIEM-conformant data instance SHOULD NOT be modified by 
processing against XML Schema documents. 


4.2.2 Use XML Validating Parsers for Content Validation 

NIEM is designed for XML Schema validation. A primary goal is to maximize the amount of 
validation that may be performed by XML Schema-validating parsers. 
XML Schema validates content using content models: descriptions of what elements and 
attributes may be contained within an element, and what values are allowable. It is the XML 
element hierarchy (elements with attributes and unstructured content, contained by other 
elements) that the XML Schema definition language specifies and that XML Schema validating 
parsers can validate. 
Mechanisms involving linking using attribute and element values are useful, but they should 
only be relied on when absolutely necessary, as XML Schema-validating parsers cannot readily 
validate them. For example, if a link is established via attribute values, an XML Schema-
validating parser cannot determine that participants have appropriate type definitions. 
Whenever possible, NIEM content should rely on XML syntax that can be validated with XML 
Schema. 

[Principle 5] 

 NIEM-conformant schemas and NIEM-conformant XML documents SHOULD use XML 
Schema validating parsers for validation of XML content. 

4.2.3 Validate for Conformance to Reference Schemas 

Systems that operate on XML data have the opportunity to perform multiple layers of 
processing. Middleware, XML libraries, schemas, and application software may process data. 
The primary purpose of XML Schema validation is to restrict processed data to that data that 
conforms to agreed-upon rules. This restriction is achieved by marking as invalid that data that 
does not conform to the rules defined by the schema. 

[Principle 6] 

 Systems that use NIEM-conformant data SHOULD mark as invalid data that does not 
conform to the rules defined by applicable XML Schema documents. 

4.2.4 Allow Multiple Schemas for XML Constraints 

The NIEM does not attempt to create a one-size-fits-all schema to perform all validation. 
Instead, it creates a set of reference schemas, on which additional constraints may be placed. It 
also does not focus on language-binding XML Schema implementations, which convert XML 
Schema definitions into working programs. It is, instead, focused on normalizing language and 
preserving the meaning of data. 

[Principle 7] 

 Constraints on XML instances MAY be validated by multiple schema validation passes, 
using multiple schemas for a single namespace. 


4.2.5 Define One Reference Schema Per Namespace 

NIEM uses the concept of a reference schema, which defines the structure and content of a 
namespace. For each NIEM-conformant namespace, there is exactly one NIEM reference 
schema. A user may use a subset schema or constraint schema in place of a reference schema, 
but all NIEM-conformant XML documents must validate against a single reference schema for 
each namespace. 

[Principle 8] 

 Each NIEM-conformant namespace SHOULD be defined by exactly one reference 
schema. 

4.2.6 Disallow Mixed Content 

XML data that use mixed content are difficult to specify and complicate the task of data 
processing. Much of the payload carried by mixed content is unchecked and does not facilitate 
data standardization or validation. 

[Principle 9] 

 NIEM-conformant schemas SHOULD NOT specify data that uses mixed content. 

4.2.7 Specify Types for All Constructs 

Schema components within NIEM all have names. This means that there are no anonymous 
types, elements, or other components defined by NIEM. Once an application has determined 
the name (i.e., namespace and local name) of an attribute or element used in NIEM-conformant 
instances, it will also know the type of that attribute or element. 
There are no local attributes or elements defined by NIEM, only global attributes and elements. 
This maximizes the ability of application developers to extend, restrict, or otherwise derive 
definitions of local components from NIEM-conformant components. Using named global 
components in schemas maximizes the capacity for reuse. 

[Principle 10] 

 NIEM-conformant schemas SHOULD NOT use or define local or anonymous components, 
as they adversely affect reuse. 

4.2.8 Avoid Wildcardsin Reference Schemas 

Wildcards in NIEM-conformant schemas work in opposition to standardization. The goal of 
creating harmonized, standard schemas is to standardize definitions of data. The use of 
wildcard mechanisms (such as xsd:any, which allows insertion of an arbitrary number of 
elements from any namespace) allows nonstandard data to be passed via otherwise 
standardized exchanges. 
Avoidance of wildcards in the standard schemas encourages the separation of standardized and 
nonstandardized data. It encourages users to incorporate their data into NIEM in a standardized 
way. It also encourages users to extend in a way that may be readily incorporated into NIEM. 


[Principle 11] 

 NIEM-conformant components SHOULD NOT incorporate wildcards unless absolutely 
necessary, as they hinder standardization by encouraging use of nonstandardized data 
rather than standardized data. 

4.2.9 Provide Default Reference Schema Locations 

[XMLSchemaStructures] provides three ways to specify the physical location of an XML Schema 
document: schemaLocation, an attribute of the element xsd:import, along 
withxsi:schemaLocationandxsi:noNamespaceSchemaLocation, attributes of an 
XML Schema document element. In all of these uses, the specification explicitly maintains that 
the schema location specified is a hint, which may be overridden by applications. 

[Principle 12] 

 Schema locations specified within NIEM-conformant reference schemas SHOULD be 
interpreted as hints and as default values by processing applications. 

4.2.10 Use Open Standards 

The cooperative efforts of many knowledgeable individuals have resulted in many important 
published information standards. Where appropriate and applicable, NIEM ought to leverage 
these standards. 

[Principle 13] 

 NIEM standards and schemas SHOULD leverage and enable use of other open standards. 

4.3 Modeling Design Guidelines 

The principles in this section address the design philosophy used in designing the NIEM 
conceptual model. 

4.3.1 Namespaces Enhance Reuse 

NIEM is designed to maximize reuse of namespaces and the schemas that define them. When 
referring to a concept defined by NIEM, a user should ensure that instances and schemas refer 
to the namespace defined by NIEM. User-defined namespaces should be used for 
specializations and extension of NIEM constructs but should not be used when the NIEM 
structures are sufficient. 

[Principle 14] 

 NIEM-conformant instances and schemas SHOULD reuse components from NIEM 
distribution schemas when possible. 

NIEM relies heavily on XML namespaces to prevent naming conflicts and clashes. Reuse of any 
component is always by reference to both its namespace and its local name. All NIEM 
component names have global scope. Therefore, validation always occurs against the reference 
schemas or subsets thereof. 


Example: 

Figure 4-1: Example of the use of a namespace 
<xsd:element ref="nc:BinaryCaptureDate" 
minOccurs="0" 
maxOccurs="unbounded"/> 
In this example, nc:BinaryCaptureDate is reused by referencing its element declaration 
through both its namespace (which is bound to the prefix nc:) and its local name 
(BinaryCaptureDate). If an element named BinaryCaptureDate is declared in 
another namespace, it is an entirely different element than nc:BinaryCaptureDate. 
There is no implicit relationship to nc:BinaryCaptureDate. 
From a business perspective, the two elements are likely to be related in the sense that they 
may have very similar semantic meanings. They may have essentially the same meaning, but 
slightly different properties. Such a relationship may commonly exist. However, any 
relationship between the two elements must be made explicit using methods outlined in this 
document. 

[Principle 15] 

 A component SHOULD be identified by its local name together with its namespace. A 
namespace SHOULD be a required part of the name of a component. A component's 
local name SHOULD NOT imply a relationship to components with similar names from 
other namespaces. 

4.3.2 Design NIEM for Extensibility 

NIEM is designed to be extended. Numerous methods are considered acceptable in creating 
extended and specialized components. 

[Principle 16] 

 NIEM-conformant schemas and standards SHOULD be designed to encourage and ease 
extension and augmentation by users and developers outside the standardization 
process. 

4.4 Implementation Guidelines 

The principles in this section address issues pertaining to the implementation of applications 
that use NIEM. 

4.4.1 Avoid Displaying Raw XML Data 

XML data should be made human-understandable when possible, but it is not targeted at 
human consumers. HTML is intended for browsers. Browsers and similar technology provide 
human interfaces to XML and other structured content. As such, structured XML content does 


not belong in places targeting humans. Human-targeted information should be of a form 
suitable for presentation. 

[Principle 17] 

 XML data SHOULD be designed for automatic processing. XML data SHOULD NOT be 
designed for literal presentation to people. NIEM standards and schemas SHOULD NOT 
use literal presentation to people as a design criterion. 

4.4.2 Leave Implementation Decisions to Implementers 

NIEM is intended to be an open specification supported by many diverse implementations. It 
was designed from data requirements and not from or for any particular system or 
implementation. Use of NIEM should not depend on specific software, other than XML 
Schema-validating parsers. 

[Principle 18] 

 NIEM SHOULD NOT depend on specific software packages, software frameworks, or 
software systems for interpretation of XML instances. 

[Principle 19] 

 NIEM schemas and standards SHOULD be designed such that software systems that use 
NIEM may be built with a variety of off-the-shelf and free software products. 

4.5 Modeling Guidelines 

The NIEM Naming and Design Rules (NDR) specify NIEM-conformant components, schemas, and 
instances. These guidelines influence and shape the more-specific principles and rules in this 
document. They are derived from best practices and from discussions within the NIEM Business 
Architecture Committee (NBAC) and the NIEM Technical Architecture Committee (NTAC). This 
list may grow and evolve as NIEM matures. 
The principles in this section address decisions that data modelers must face when creating 
NIEM-conformant schema representations of domain data. These guidelines are not absolute 
(the key word is SHOULD). It may not be possible to apply all guidelines in every case. However, 
they should always be considered. 

4.5.1 Documentation 

As will be described in later sections of this document, all NIEM components are documented 
through their definitions and names. Although it is often very difficult to apply, a data 
component definition should be drafted before the data component name is finalized. 

Drafting the definition for a data component first ensures that the author understands the exact 
nature of the entity or concept that the data component represents. The component name 
should subsequently be composed to summarize the definition. Reversing this sequence often 
results in data definitions that very precisely describe the component name but do not 
adequately describe the entity or concept that the component is designed to represent. This 
can lead to the ambiguous use of such components. 


[Principle 20] 

 A data component definition SHOULD be drafted before the associated data element 
name is composed. 

4.5.2 Consistent Naming 

Components in NIEM should be given names that are consistent with names of other NIEM 
components. Having consistent names for components has several advantages: 

1. It is easier to determine the nature of a component when it has a name that conveys the 
meaning and use of the component. 

2. It is easier to find a component when it is named predictably. 

3. It is easier to create a name for a component when clear guidelines exist. 

[Principle 21] 

 Components in NIEM SHOULD be given names that are consistent with names of other 
NIEM components. Such names SHOULD be based on simple rules. 

4.5.3 Reflect the Real World 

NIEM provides a standard for data exchange. To help facilitate unambiguous understanding of 
NIEM reusable components, the names and structures should represent and model the 
informational aspects of objects and concepts that users are most familiar with. Types should 
not simply model collections of data. 

[Principle 22] 

 Component definitions in NIEM-conformant schemas SHOULD reflect real-world 
concepts. 

4.5.4 Be Consistent 

There should be no conflicts of meaning among types. This holds for types within a namespace, 
as well as types in different namespaces. A type should be used consistently in similar 
situations for similar purposes. Types should be defined for clear understanding and ease of 
intended use. 

[Principle 23] 

 Component definitions in NIEM-conformant schemas SHOULD have semantic 
consistency. 

4.5.5 Reserve Inheritance for Specialization 

Specialization should not be applied simply for the sake of achieving property inheritance. 
Specialization should be applied only where it is meaningful and appropriate to model 
permanent sibling subclasses of a base class that are mutually exclusive of one another. 


[Principle 24] 

 Complex type definitions in NIEM-conformant schemas SHOULD use type inheritance 
only for specialization. 

Note that application of type augmentations is a well-defined exception to this guideline. 

4.5.6 Do Not Duplicate Definitions 

A real-world entity should be modeled in only one way. The definition of a type or element 
should appear once and only once. Multiple components of identical or closely similar 
semantics hinder interoperability because too many valid methods exist for representing the 
same data. For each data concept that must be represented, there should be only one 
component (and associated type) to represent it. 
Components with very similar semantics may exist in different contexts. For example, a 
complex type created for a particular exchange may appear to have identical or closely similar 
semantics to a complex type defined in the NIEM Core schema. However, the type defined at 
the exchange level will have much more precise business requirements and syntax, compared 
with the broad definitions that are heavily reused. Specific contextual definitions should be 
considered semantic changes. This includes the application of augmentations to create a 
specialized type for a specific use. 
Two components may have the same definition while having different representations. For 
example, a string may hold the complete name of a person, or the name may be represented by 
a structure that separates the components of the name into first, last, etc. The definition of 
alternative representations should not be considered duplication. 

[Principle 25] 

 Multiple components with identical or undifferentiated semantics SHOULD NOT be 
defined. Component definitions SHOULD have clear, explicit distinctions. 

4.5.7 Keep It Simple 

All NIEM content and structure is fundamentally based on business requirements for 
information exchange. To encourage adoption and use in practice, NIEM must implement 
business requirements in simple, consistent, practical ways. 

[Principle 26] 

 NIEM-conformant schemas SHOULD have the simplest possible structure, content, and 
architecture consistent with real business requirements. 

4.5.8 Be Aware of Scope 

The scope of components defined in NIEM-conformant schemas should be carefully considered. 
Some components represent simple data values, while others represent complex objects with 
many parts and relationships. Components should exist in layers. Components should exist as 
small, narrowly scoped, atomic entities that are used to consistently construct more broadly 
scoped, complex components (and so on). 


[Principle 27] 

 Components defined by NIEM-conformant schemas SHOULD be defined appropriate for 
their scope. 

4.5.9 Be Mindful of Namespace Cohesion 

Namespaces should maximize cohesion. The namespace methodology helps prevent name 
clashes among communities or domains that have different business perspectives and may 
choose identical data names to represent different data concepts. A namespace should be 
designed so that its components are consistent, may be used together, and may be updated at 
the same time. 

[Principle 28] 

 XML namespaces defined by NIEM-conformant schemas SHOULD encapsulate data 
components that are coherent, consistent, and internally related as a set. A namespace 
SHOULD encapsulate components that tend to change together. 

5 Relation to Standards 

This section specifies the standards and specifications to which NIEM conforms. Where NIEM 
differs from public standards, the rationale for those differences is discussed in this section. The 
complete list of standards and specifications referenced in this section appears in Appendix 
D:References. 

5.1 XML 1.0 

[Rule 5-1] (REF, SUB, EXT, CON) 

 The schema MUST conform to XML as specified by [XML]. 

Rationale 

 XML is a well-known, commonly used W3C Recommendation. It is supported by a large 
number of commercial and open-source software tools. It is a simple, well-defined, 
semi-structured data format that is flexible enough to allow for easy extension. XML 
works with many other powerful associated technologies such as XML Schema, XSLT, and 
XPath. Artifacts of NIEM conform to the most recent recommendation for XML. 

5.2 XML Namespaces 

[Rule 5-2] (REF, SUB, EXT, CON) 

 The schema MUST conform to the specification for namespaces in XML, as defined by 
[XMLNamespaces] and [XMLNamespacesErrata]. 

Rationale 

 NIEM is designed to facilitate cross-domain data exchanges and interoperability. The 
ultimate scope of NIEM is anticipated to be quite large. The primary purpose 


ofnamespaces is to avoid naming conflicts, which for NIEM could become quite 
common, since NIEM stakeholders and IEPD developers define and name many of their 
own data components independently. Therefore, in NIEM, XML namespaces are 
employed both to avoid name clashes and to provide a level of independence to 
participating domains. 

5.3 XML Schema 

[Rule 5-3](REF, SUB, EXT, CON) 

 The schema MUST conform to the W3C XML Schema Recommendations: XML Schema 
Part 1: Structures and XML Schema Part 2: Datatypes, as specified by 
[XMLSchemaStructures] and [XMLSchemaDatatypes]. 

Rationale 

 XML Schema has become the generally accepted schema language and is experiencing 
the most widespread adoption. Although other schema languages exist that offer their 
own advantages and disadvantages, the current approach is to base NIEM on XML 
Schema. 

5.4 ISO 11179, Part 4 

Good data definitions are fundamental to data interoperability. You cannot effectively exchange 
what you cannot understand. NIEM employs the guidance of [ISO 11179 Part 4] as a baseline 
for its data component definitions. All NIEM components are documented. 

[Definition: documented component] 

 In a NIEM-conformant schema, a documented component is an XML Schema 
component that has an associated data definition. These schema components have a 
textual definition, so that the component may be well-understood. Schemas that do not 
document their components accordingly are not NIEM-conformant. 

[Definition: data definition] 

 The data definition of a documented component is the content of the first occurrence of 
the element xsd:documentation,which is an immediate child of an occurrence of 
the element xsd:annotation, which is an immediate child of the element that 
defines the component. 


Figure 5-1: Example of data definition of 
MeasureMetadataType 

<xsd:complexType name="MeasureMetadataType"> 
<xsd:annotation> 
<xsd:documentation> 
A data type for metadata about a measurement. 
</xsd:documentation> 
<xsd:appinfo> 
<appinfo:Base 
appinfo:namespace="http://niem.gov/niem/structures/2.0" 
appinfo:name="MetadataType"/> 
<appinfo:AppliesTo appinfo:name="MeasureType"/> 
</xsd:appinfo> 
</xsd:annotation> 
<xsd:complexContent> 
<xsd:extension base="s:MetadataType"> 
<xsd:sequence> 
<xsd:element ref="nc:MeasureDate" 
minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element ref="nc:Measurer" 
minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 

[Rule 5-4] (REF, EXT) 

 Within a NIEM-conformant schema, the data definition provided for each documented 
component SHALL follow the requirements and recommendations for data definitions 
given by [ISO 11179 Part 4]. 

Rationale 

 To advance the goal of creating semantically rich NIEM-conformant schemas, it is 
necessary that data definitions be descriptive, meaningful, and precise. [ISO 11179 Part 
4]provides standard structure and rules for defining data definitions. NIEM uses this 
standard for component definitions. 

Note that the metadata maintained for each NIEM component contains additional details, 
including domain-specific usage examples and keywords. Such metadata is used to enhance 
search and discovery of components in a registry, and therefore, is not included in schemas. 

For convenience and reference,the summary requirements and recommendations in [ISO 11179 
Part 4] are reproduced here: 

ISO 11179 Requirements 

A data definition SHALL: 

. 
Be stated in the singular. 
. 
State what the concept is, not only what it is not. 
. 
Be stated as a descriptive phrase or sentence(s). 
. 
Contain only commonly understood abbreviations. 
. 
Be expressed without embedding definitions of other data or underlying concepts. 



ISO 11179 Recommendations 

A data definition SHOULD: 

. 
State the essential meaning of the concept. 
. 
Be precise and unambiguous. 
. 
Be concise. 
. 
Be able to stand alone. 
. 
Be expressed without embedding rationale, functional usage, or procedural information. 
. 
Avoid circular reasoning. 
. 
Use the same terminology and consistent logical structure for related definitions. 
. 
Be appropriate for the type of metadata item being defined. 


In addition to the requirements and recommendations of [ISO 11179 Part 4], NIEM applies 
additional rules to data definitions. These rules are detailed in Section 7.2.1, Human-Readable 
Documentation. 

5.5 ISO 11179, Part 5 

Names are a simple but incomplete means of providing semantics to data components. Data 
definitions, structure, and context help to fill the gap left by the limitations of naming. The 
goals for data component names should be syntactic consistency, semantic precision, and 
simplicity. In many cases, these goals conflict and it is sometimes necessary to compromise or 
to allow exceptions to ensure clarity and understanding. To the extent possible, NIEM applies 
[ISO 11179 Part 5] to construct NIEM data component names. 
The set of NIEM data components is a collection of data representations for real-world objects 
and concepts, along with their associated properties and relationships. Thus, names for these 
components would consist of the terms (words) for object classes or that describe object 
classes, their characteristic properties, subparts, and relationships. 

[Rule 5-5] (REF, SUB, EXT) 

 A NIEM component name SHALL be formed by applying the informative guidelines and 
examples detailed in Annex A of [ISO 11179 Part 5], with exceptions as specified in this 
document, most notably those specified in Section 9, Naming Rules. 

Rationale 

 The guidelines and examples of [ISO 11179 Part 5] provide a simple, consistent syntax 
for data names that captures context and thereby imparts a reasonable degree of 
semantic precision. 

NIEM uses the guidelines and examples of [ISO 11179 Part 5]as a baseline for normative naming 
rules. However, some NIEM components require bending of these rules. Special naming rules 
for these classes of components are presented and discussed in Section 9. In spite of these 
exceptions, most NIEM component names can be disassembled into their [ISO 11179 Part 5] 
constituent words or terms. 


Example: 

The NIEM component name AircraftFuselageColorCode disassembles as follows: 

. 
Object class term = �Aircraft� 
. 
Qualifier term = �Fuselage� 
. 
Property term = �Color� 
. 
Representation term = �Code� 


Section 9, Naming Rules,details the specific rules for each kind of term and how to construct 
NIEM component names from it. Exceptions for special components are also described in 
Section 9. 

6 XML Schema Design Rules 

The W3C XML Schema Language provides many features that allow a developer to represent a 
logical data model many different ways. This section establishes rules for the use of XML 
Schema constructs within NIEM-conformant schemas. Because the XML Schema specifications 
are flexible, comprehensive rules are needed to achieve a balance between establishing uniform 
schema design and providing developers flexibility to solve novel data modeling problems. 

Note that external schemas (non-NIEM-conformant schemas) do not need to obey the rules set 
forth in this section. So long as schema components from external schemas are adapted for use 
with NIEM, according to the modeling rules in Section 7.7, they may be used as they appear in 
the external standard, even if the schema components violate the rules for NIEM-conformant 
schemas. 
The XML Schema design rules in this section fall into the following categories: 

� Restrictions on XML Schema Constructs 

� xsd:schema Document Element 

� Namespace Imports 

� Annotations 

� Type Definitions 

� Additional Definitions and Declarations 

6.1 Restrictions on XML Schema Constructs 

A number of XML Schema constructs are not used within NIEM-conformant schemas. Many of 
these constructs provide capability that is not currently needed within NIEM. Some of these 
constructs create problems for interoperability, with tool support, or with clarity or precision of 
data model definition. 


6.1.1 No Mixed Content 

[Rule 6-1] (REF, SUB, EXT) 

 Within the schema, an element xsd:complexType SHALL NOT own the attribute 
mixed with the value true. 

[Rule 6-2] (REF, SUB, EXT) 

 Within the schema, an element declaration that is of complex content SHALL NOT own 
the attribute mixed with the value true. 

Rationale 

 Mixed content allows the mixing of data tags with text. Languages such as XHTML use 
this syntax for markup of text. NIEM-conformant schemas define XML that is for data 
exchange, not text markup. Mixed content creates complexity in processing, defining, 
and constraining content. 

 Well-defined markup languages exist outside NIEM and may be used with NIEM data. 
External schemas may include mixed content and may be used with NIEM. However, 
mixed content must not be defined by NIEM-conformant schemas in keeping with 
[Principle 9]. 

6.1.2 No Notations 

[Rule 6-3] (REF, SUB, EXT) 

 The schema SHALL NOT contain a reference to the type definition xsd:NOTATION or 
to a type derived from that type. 

[Rule 6-4] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:notation. 

Rationale 

 XML Schema notations allow the attachment of system and public identifiers on fields of 
data. The notation mechanism does not play a part in validation of instances and is not 
supported by NIEM. 

6.1.3 No Schema Inclusion 

[Rule 6-5] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:include. 

Rationale 

 Element xsd:include brings schemas defined in separate files into the current 
namespace. It breaks a namespace up into arbitrary partial schemas, which needlessly 
complicates the schema structure, making it harder to reuse and process, and also 
increases the likelihood of conflicting definitions. 


 Inclusion of schemas that do not have namespaces also complicates schema 
understanding. This inclusion makes it difficult to find the realization of a specific 
schema artifact and create aliases for schema components that should be reused. 
Inclusion of schemas also violates [Principle 8], as it uses multiple schemas to construct 
a namespace. 

6.1.4 No Schema Redefinition 

[Rule 6-6] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:redefine. 

Rationale 

 The xsd:redefine element allows an XMLSchema documentto restrict and extend 
components from a namespace, in that very namespace. Such redefinition introduces 
duplication of definitions, allowing multiple definitions to exist for components from a 
single namespace. This violates [Principle 8] that a single reference schema defines a 
NIEM-conformant namespace. 

6.1.5 Wildcard Restrictions 

There are many constructs within XML Schema that act as wildcards. That is, they introduce 
buckets that may carry arbitrary or otherwise nonvalidated content. Such constructs violate 
[Principle 11], and as such provide implicit workarounds for the difficult task of agreeing on the 
content of data models. Such workarounds should be made explicitly, outside the core data 
model. 

6.1.5.1 No Unconstrained Type Substitution 

[Rule 6-7] (REF, SUB, EXT) 

 The schema SHALL NOT reference the type xsd:anyType. 

Rationale 

 XML Schema has the concept of the "ur-type," a type that is the root of all other types. 
This type is realized in schemas as xsd:anyType. 

 NIEM-conformant schemas must not use xsd:anyType, because this feature permits 
the introduction of arbitrary content (i.e., untyped and unconstrained data) into an XML 
instance. NIEM intends that the schemas describing that instance describe all constructs 
within the instance. 

6.1.5.2 No Unconstrained Text Substitution 

[Rule 6-8] (REF, SUB, EXT) 

 The schema SHALL NOT reference the type xsd:anySimpleType. 


Rationale 

 XML Schema provides a restriction of the �ur-type,� which contains only simple content. 
This provides a wildcard for arbitrary text. It is realized in XML Schema as 
xsd:anySimpleType. 

 NIEM-conformant schemas must not use xsd:anySimpleType because this feature 
is insufficiently constrained to provide a meaningful starting point for content 
definitions. Instead, content should be based on one of the more specifically defined 
simple types defined by XML Schema. 

6.1.5.3 Untyped Elements Must Be Abstract 

[Rule 6-9] (REF, SUB, EXT) 

 Within the schema, an element declaration with the attribute name and without the 
attribute type MUST carry the attribute abstract with the value true. 

Rationale 

 Untyped element declarations act as wildcards that may carry arbitrary data. By 
declaring such types abstract, NIEM allows the creation of type independent semantics 
without allowing arbitrary content to appear in XML instances. 

6.1.5.4 No Untyped Attributes 

[Rule 6-10] (REF, SUB, EXT) 

 Within the schema, an attribute declaration with attribute name MUST carry the 
attribute type. 

Rationale 

 Untyped XML Schema attributes allow arbitrary content, with no semantics. Attributes 
must have a type so that specific syntax and semantics will be provided. 

6.1.5.5 No Unconstrained Element Substitution 

[Rule 6-11] (REF, SUB) 

 The schema SHALL NOT contain the element xsd:any. 

Rationale 

 The xsd:any particle (see Model Group Restrictions for an informative definition of 
particle) provides a wildcard that may carry arbitrary content. The particle xsd:any 
may appear within constraint schemas, extension schemas, and exchange schemas. 

6.1.5.6 No Unconstrained Attribute Substitution 

[Rule 6-12] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:anyAttribute. 


Rationale 

 The xsd:anyAttribute element provides a wildcard, where arbitrary attributes may 
appear. The element xsd:anyAttribute may appear within constraint schemas or 
within other schemas that are not NIEM-conformant, but it is prohibited in NIEM-
conformant schemas. 

6.1.6 Component Naming Restrictions 

All NIEM components must be named. That is, type definitions, and element and attribute 
declarations must be given explicit names � local and anonymous component definition is not 
allowed. Note that XML Schema enforces the placement of attribute group and model group 
definitions as top-level components, which forces the components to be named. 

6.1.6.1 No Anonymous Type Definitions 

[Rule 6-13] (REF, SUB, EXT) 

 Within the schema, any occurrence of the element xsd:complexType or 
xsd:simpleType MUST appear as an immediate child of the element xsd:schema. 

Rationale 

 NIEM does not support anonymous types in NIEM-conformant schemas. All XML 
Schema "top-level" types (children of the document element) are required by XML 
Schema to be named. By requiring NIEM type definitions to be top level, they are forced 
to be named and are therefore globally reusable. 

6.1.6.2 No Local Element Declarations 

[Rule 6-14] (REF, SUB, EXT) 

 Within the schema, any element declaration carrying the attribute name MUST appear 
as an immediate child of the document element xsd:schema. 

Rationale 

 All schema components defined by NIEM-conformant schemas must be named, 
accessible from outside the defining schema, and reusable across schemas. Local 
element definitions provide named elements that are not reusable outside the context 
in which they are defined.Requiring named NIEM elements to be top level ensures that 
they are globally reusable. 

6.1.6.3 No Local Attribute Definitions 

[Rule 6-15] (REF, SUB, EXT) 

 Within the schema, any attribute declaration owning the attribute name MUST appear 
as an immediate child of the document element xsd:schema. 


Rationale 

 All schema components defined by NIEM-conformant schemas are named, accessible 
from outside the defining schema, and reusable across schemas. Local attribute 
definitions provide named attributes that are not reusable outside the context in which 
they are defined.Requiring named NIEM attributes to be top level ensures that they are 
globally reusable. 

6.1.7 No Uniqueness Constraints 

[Rule 6-16] (REF, EXT) 

 The schema SHALL NOT contain any of the elements xsd:unique, xsd:key, 
xsd:keyref, xsd:selector, or xsd:field. 

Rationale 

 XML Schema provides NIEM with the ability to apply uniqueness constraints to schema-
validated content. These mechanisms, however, establish relationships in a way that is 
very difficult to understand, extend, and keep consisent through schema reuse. These 
elements may be used in subset schemas and constraint schemas. 

6.1.8 Model Group Restrictions 

Complex content definitions in XML Schema use model group schema components. These 
schema components,xsd:all, xsd:choiceandxsd:sequence, also called compositors, 
provide for ordering and selection of particles within a model group. 
XML Schema defines a particle as an occurrence of xsd:element, xsd:sequence, 
xsd:choice, xsd:any (wildcard) and xsd:group (model group) within a content model. 
For example, an xsd:sequence within an XML Schema complex type is a particle. An 
xsd:element occurring within an xsd:sequence is also a particle. 

6.1.8.1 Restrictions on Particle Ordering 

[Rule 6-17] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:all. 

Rationale 

 The element xsd:all provides a set of particles (e.g., elements) that may be included 
in an instance, in no particular order. This can greatly complicate processing and may be 
difficult to comprehend and satisfy. 

[Rule 6-18] (REF) 

 The schema SHALL NOT contain the element xsd:choice. 


Rationale 

 The element xsd:choice provides an exclusive set of particles, one of which may 
appear in an instance. This can greatly complicate processing and may be difficult to 
comprehend, satisfy, and reuse. 

 The element xsd:choice may be used in extension and exchange schemas, as it 
presents a simple way for a schema writer to represent a set of optional content. It may 
also be used in subset schemas and constraint schemas to represent syntactic 
alternatives. 

6.1.8.2 No Recursively Defined Model Groups 

[Rule 6-19] (REF, SUB) 

 Within the schema, any immediate child of a model group xsd:sequence element 
MUST be one of xsd:annotation or xsd:element 

[Rule 6-20] (EXT) 

 Within the schema, any immediate child of a model group xsd:sequence element 
MUST be one of xsd:annotation, xsd:element, xsd:choice, or xsd:any. 

[Rule 6-21] (EXT) 

 Within the schema, any immediate child of a model group xsd:choice element MUST 
be one of xsd:annotation or xsd:element. 

[Rule 6-22] (EXT) 

 The use of xsd:choice SHALL define syntax, structure, grouping, and cardinality of 
instances, but SHALL NOT define semantics. The semantics of a property within an 
xsd:choice SHALL be identical to the semantics of the property within an 
xsd:sequence. 

Rationale 

 XML Schema provides the capability for model groups to be recursively defined. This 
means that a sequence may contain a sequence, and a choice may contain a choice. 
These rules are designed to keep content models simple, comprehensive, and reusable: 
The content of an element should boil down to a simple list of elements, defined in as 
straightforward a manner as is possible to meet requirements. 

6.1.8.3 Restrictions on Named Groups 

[Rule 6-23] (REF, SUB, EXT) 

 The schema SHALL NOT contain the element xsd:group. 

Rationale 

 NIEM does not allow groups of elements to be named other than as named complex 
types. A group in XML Schema creates a named entity that may be included in 


multipletypes, and which consists of a sequence of or choice between element particles. 
The NIEM has not developed a semantic model for these components, and they are not 
integrated into NIEM's design. 

6.1.8.4 Particle Cardinality Restrictions 

[Rule 6-24] (REF, SUB, EXT) 

 Within the schema, if the element xsd:sequence carries the attribute minOccurs, 
it MUST set the value for the attribute to 1. 

[Rule 6-25] (REF, SUB, EXT) 

 Within the schema, if the element xsd:sequence carries the attribute maxOccurs, 
it MUST set the value of the attribute to 1. 

Rationale 

 XML Schema allows each particle to specify cardinality (how many times the particle 
may appear in an instance). NIEM restricts the cardinality of xsd:sequence particles 
to exactly one, to ensure that content model definitions are defined in as 
straightforward a manner as possible. 

Discussion 

 Note that the particle xsd:any is not allowed in reference schemas or subset schemas 
by [Rule 6-11] 

 Note also that element declarations acting as a particle (particles formed by 
xsd:element) may have any cardinality; they are not restricted by this rule. Should a 
user desire the behavior that would be obtained from the use of special cardinalities on 
these particles, he or she should define them within explicitly named elements. 

6.1.9 Block Substitution Restrictions 

XML Schema provides a mechanism that will prevent substitution for an element declaration or 
type definition. That is, an element declaration may declare one or more of the following: 

1. An instance of this element declaration may not substitute an extended type. 

2. An instance of this element declaration may not substitute a restricted type. 

3. An instance of this element declaration may not substitute another element. 

These restriction mechanisms are very useful in instances; they allow restriction of content 
models down to exact types and elements. However, in shared data models, they limit reuse 
and customization options, in opposition to [Principle 14]. 

[Rule 6-26] (REF, EXT) 

 Within the schema, if an element declaration carries the attribute block, it MUST set 
the value for the attribute to the empty string. 


[Rule 6-27] (REF, EXT) 

 Within the schema, if a complex type definition carries the attribute block, it MUST 
set the value for the attribute to the empty string. 

[Rule 6-28] (REF, SUB, EXT) 

 Within the schema, if the document element xsd:schema carries the attribute 
blockDefault, it MUST set the value for the attribute to the empty string. 

Rationale 

 Restriction of substitution options reduces capacity for reuse; thus, it is forbidden within 
NIEM-conformant schemas In particular, setting the block value at the schema level 
complicates understanding of component definitions. 

6.1.10 Final Value Restrictions 

XML Schema provides the capability for type definitions and elements to declare a final value. 
This value prevents the creation of derived components. In shared data models, this capability 
limits reuse and customization options, in opposition to [Principle 14]. 

[Rule 6-29] (REF, SUB) 

 Within the schema, if a simple type definition carries the attribute final, it MUST set 
the value for the attribute to the empty string. 

[Rule 6-30] (REF, SUB) 

 Within the schema, if a complex type definition carries the attribute final, it MUST set 
the value for the attribute to the empty string. 

[Rule 6-31] (REF, SUB) 

 Within the schema, if an element declaration carries the attribute final, it MUST set 
the value for the attribute to the empty string. 

[Rule 6-32] (REF, SUB, EXT) 

 Within the schema, if the document element xsd:schema carries the attribute 
finalDefault, it MUST set the value for that attribute to the empty string. 

Rationale 

 Restriction of derivation options reduces capacity for reuse and so is forbidden within 
reference and subset schemas. As well, the use of finalDefault complicates 
understanding of schemas, so it is only allowed in constraint schemas. 

6.1.11 Default Value Restrictions 

XML Schema provides the capability for element and attribute declarations to provide default 
values when XML instances using those components do not provide values. 


[Rule 6-33] (REF, SUB, EXT, CON) 

 Within the schema, any element xsd:element SHALL NOT carry the attribute 
default. 

[Rule 6-34] (REF, SUB, EXT, CON) 

 Within the schema, any element xsd:attribute SHALL NOT carry the attribute 
default. 

Rationale 

 The use of default values means that the act of validating a schema will insert a value 
into an XML instance where none existed prior to schema validation. Schema validation 
is for rejection of invalid instances, not for modifying instance content, as specified in 
[Principle 4]. 

6.2 xsd:schema Document Element 

The features of XML Schema allow for flexibility of use for many different and varied types of 
implementation. NIEM requires consistent use of these features. 

[Rule 6-35] (REF, SUB, EXT, CON) 

 Within the schema, the document element xsd:schema MUST carry the attribute 
targetNamespace. 

[Rule 6-36] (REF, SUB, EXT, CON) 

 Within the schema, the value of the required attribute targetNamespace on the 
document element xsd:schema MUST match the production <absolute-URI> as 
defined by [RFC3986]. 

Rationale 

 Schemas without defined namespaces provide definitions that are ambiguous, in that 
they are not universally identifiable. 

 Absolute URIs are the only universally meaningful URIs. URIs include both URLs and 
URNs. Finding the target namespace using standard XML Base technology is 
complicated and not specified by XML Schema. Relative URIs are not universally 
identifiable, as they are context-specific. 

Discussion 

 The document element xsd:schema may contain optional attributes 
attributeFormDefaultand elementFormDefault. The values of these 
attributes are immaterial to a NIEM-conformant schema, as each attribute defined by a 
NIEM-conformant schema must be defined at the toplevel and so must be qualified with 
the target namespace of its declaration. 


[Rule 6-37] (REF, SUB, EXT, CON) 

 Within the schema, the document element xsd:schema MUST carry the attribute 
version. 

[Rule 6-38] (REF, SUB, EXT, CON) 

 Within the schema, the value of the required attribute version on the document 
element xsd:schema MUST NOT be an empty string. 

Rationale 

 It is very useful to be able to tell one version of a schema from another. Apart from the 
use of namespaces for versioning, it is sometimes necessary to release multiple versions 
of schema documents. Such use might include: 

� Subset schemas and constraint schemas 

� Error corrections or bug fixes 

� Documentation changes 

� Contact information updates 

 In such cases, a different value for the version attribute implies a different version of 
the schema. No specific meaning is assigned to specific version identifiers. 

 Note that some of the above uses for the version attribute are not employed in 
management of NIEM Core and domain schemas. An author of an application schema 
or exchange may use the version attribute for these purposes within their schemas. 

6.3 Namespace Imports 

XML Schema requires that namespaces used in external references be imported using the 
xsd:import element. The xsd:import element appears as an immediate child of the 
xsd:schema element. A schema must import any namespace which 

1. Is not the local namespace, and 

2. Is referenced from the schema. 

The behavior of import statements is not necessarily intuitive. In short, the import introduces 
namespace into the schema in which the import appears; it has no transitive effect. If the 
namespaces of an import statement are not referenced from the schema, then the import 
statement has no effect. The import statement cannot be used to direct schema locations for 
schemas not referenced from the schema performing the import. The schema location directed 
by the import element may be overridden by user directive at the parser, or by being overridden 
by import elements from other schemas. 

Imports of namespaces should be made as uniform as possible; all schemas in a schema set 
should agree on what schema location goes with a particular namespace. Otherwise, behavior 
may be dependent on the behavior of the parser and the order of components in instance 
documents. 


6.3.1 xsd:import Element Restrictions 

[Rule 6-39] (REF, SUB, EXT) 

 Within the schema, the element xsd:import MUST carry the attribute namespace. 

[Rule 6-40] (REF, SUB, EXT) 

 Within the schema, the value of the required attribute namespaceowned by the 
element xsd:import MUST match the production <absolute-URI> as defined by 
[RFC3986]. 

Rationale 

 An import that does not specify a namespace is enabling reference to non-namespaced 
components. NIEM requires that all components have a defined namespace. It is 
important that the namespace declared by a schema be universally defined and 
unambiguous. Use of the standard XML Base for processing is not specified by XML 
Schema; thus it is not supported here. 

[Rule 6-41] (REF, SUB, EXT) 

 Within the schema, the element xsd:import MUST carry the attribute 
schemaLocation. 

Rationale 

 An import that does not specify a schema location gives no clue to processing 
applications as to where to find an implementation of the namespace. Even though 
such a provided schema location may be overridden, it is important that an initial 
default be provided for processing. 

[Rule 6-42] (REF, SUB, EXT) 

 Within the schema, the value of the required attribute schemaLocation carried by 
the element xsd:import MUST match either the production <absolute-URI>or 
the definition of "relative-path reference," as defined by [RFC3986]. 

Rationale 

 The default value may be specified either as absolute or relative URIs. Since URNs are 
not resolvable, they are inappropriate for use in schemaLocation. The requirement 
for conformance to "relative-path reference" is required to avoid the more obscure 
syntax of "network-path reference" and the system-specific "absolute-path reference." 

[Rule 6-43] (REF, SUB, EXT) 

 Within the schema, the value of the required attribute schemaLocation carried by 
the element xsd:import MUST be resolvable to a XML schema document file that is 
valid according to [XMLSchemaStructures] and [XMLSchemaDatatypes]. 


Rationale 

 The XML Schema specification requires that the object imported via xsd:import must 
be a schema document. This rule reinforces that requirement. 

Discussion 

 Note that relative URI references are dereferenced from the location of the schema 
document performing the import, not from the location of an instance or other schema. 
Although NIEM distribution schemas use only relative URI references, that need not be 
the case for other NIEM-conformant schemas. 

6.3.2 Including XML Content From Other Namespaces 

Within an XML Schema document, there are several mechanisms to include XML content that is 
not from the XML or XML Schema namespaces. Those mechanisms are: 

1. Carrying attributes from other than the XML or XML Schema namespaces on an element 
in the XML Schema namespace. 

 By the rules of XML Schema, any element may have attributes that are from other 
namespaces. These attributes do not participate in validation but may carry information 
useful to tools that process schemas. 

2. Adding content to the elements xsd:appinfo and xsd:documentation. 

 XML Schema allows arbitrary XML content to be included within annotations. Such XML 
does not participate in validation but may communicate useful information to schema 
readers or processors. 

NIEM requires all such XML content to be �schema-valid.� That is, it must have a schema, and it 
must validate against that schema. The schemas must be introduced via xsd:import 
elements within the schema in which the content is used. This is for two reasons: 

1. Some tools require imports of namespaces used within schemas and validate against 
those schemas. 

2. The definition and the validity of content within schemas should be clear. 

[Rule 6-44] (REF, SUB, EXT) 

 Within the schema, when a namespace other than the XML namespace or the XML 
Schema namespace is used, it MUST be imported into the schema using the 
xsd:import element. 

Rationale 

 This rule ensures that used namespaces have recognizable defining sources and that 
they will cooperate with existing tools. 


[Rule 6-45] (REF, SUB, EXT) 

 Within the schema, when a namespace other than the XML namespace or the XML 
Schema namespace is used, its content MUST be valid with respect to the schema 
imported for that namespace. 

Rationale 

 XML Schema does not address the schema-validity of content used for annotations or 
attributes on schema components. This rule ensures that content used in such a 
manner is schema-valid. This encourages interoperable data definitions and schema 
documents. 

6.4 Annotations 

Annotations in XML Schema "provide for human- and machine-targeted annotations of schema 
components." [XMLSchemaStructures] The two types: human-targeted and machine-targeted, 
are kept separate by the use of two separate container elements defined by XML Schema: 
xsd:documentation and xsd:appinfo. 

[Rule 6-46] (REF, EXT) 

 Within the schema, an element SHALL have at most one instance of an element 
xsd:annotation as an immediate child. 

Rationale 

 XML Schema allows annotations to be added to components in a fairly loose manner: 
there may be multiple annotations, each of which may have multiple documentation 
or appinfo elements. This flexibility in the syntax provides no additional expressivity 
but does complicate processing, so it is forbidden in NIEM. 

6.4.1 Human-Readable Documentation 

XML Schema describes the content of xsd:documentation elements as "user information." 
This information is targeted for reading by humans. The XML Schema specification does not say 
what form human-targeted information should take. Within NIEM, user information is plain 
text with no formatting or XML structure. 

[Rule 6-47] (REF, EXT) 

 Within theschema, the content of the xsd:documentation element that constitutes 
the data definition of a component MUST be character information items as specified by 
[XMLInfoSet]. 

Rationale 

 According to the XML Schema specification, the content of xsd:documentation 
elements is intended for human consumption, whereas other structured XML content is 
intended for machine consumption. Therefore, the xsd:documentation element 
MUST NOT contain structured XML data. As such, any XML content appearing within 


adocumentation element is in the context of human-targeted examples and should be 
escaped using &lt; and &gt;. This rule also prohibits comments within 
documentation elements. 

 See [SchemaForXMLSchema], the schema for XML Schema, as an example of 
documentation elements containing properly escaped XML elements. 

XML comments are not XML Schema constructs and are not specifically associated with any 
schema-based components. As such, comments are not considered semantically meaningful by 
NIEM and may not b