From b752f320bae9a559e9603cfd70d41132f3111e2b Mon Sep 17 00:00:00 2001 From: Webb Roberts Date: Tue, 27 Jun 2017 02:57:30 -0400 Subject: [PATCH] NIEM NDR 4.0beta2. Included reference to code lists spec as an option for building code types, code simple types. Fixed typo in rule 10-17. Added crossref from code type to code simple type. Added schematron for component name allowed characters. Expanded rule 10-47 from "hyphen" to "punctuation" to include underscore, hyphen, and period. Added schematron for rule 10-50 and fixed omission of proxy types from the rule. Removed old rule 11-2, 11-5, 11-13, as they are now covered by rule 10-50. Added reference to code lists spec v1.0. eliminated stray 3.0 references Pointed to github repo for updates and errata, and comment submission. Added spelling to Makefile. Stood up initial words file. Revised non-word "birthdate" to OED word "birth-date" Stood up and verified spell checking Addressed @fixed and @default: Updated 6.2.2. from "Disallow content modification with XML processors" to "Prohibit XML parsing from constructing values", clarifying that XML documents aren't modified; it's data passed through a parser. Updated principle 5. Updated Section 8.4 from "Ensure schema processing does not alter processed data" to "Ensure XML parsing does not construct values"" Added description of infoset augmentation by XML Schema validating parsers. Got away from language that sounds like XML files are modified by parsers. Updated rule #no-at-fixed to allow required attribute uses. Prohibited @fixed on simple type facets in reference schemas. Broke up Rule 11-29. "Standard opening phrase for element" and Rule 11-30. "Standard opening phrase for complex type" into component-specific rules. Updated instance rules on ID/REF and URIs. Removed references to the local terminology namespace. Updated NDR to include correct structures and appinfo schemas. Overhauled section 12 & rules about ids, refs, and uris, consistently with NTAC decisions. Removed terminology of "content element" and "reference element". Removed language about "pointing" and instead mapped ids and refs to uris. Added new section on "the meaning of NIEM data". Added table mapping XML data to NIEM meaning of that data. Added new diagram for a simple XML instance. Added toplevel section on identifiers and references, and put id/ref as subsection on local identifiers and references. Indicated that objects can be merged. Added new section on uniform identifiers in niem data. Added new rules defining uri as URI-reference, and id and ref as mapped to uri. Added section on compare-and-contrast of ref-to-id and URIs. Added rule ensuring only one of (id, ref, uri) appears on an instance. Udpated structures.xsd to include @structures:uri. Fixed: NCCT Issue 959 - 10.4 Augmentations - Revise problems with extensions Fixed: NCCT Issue 960 - 10.4 Augmentation - Clarify augmentation type Addressed Issue 961 - 10.4 Augmentation - Expand definition of "augmentation" to include direct elements. Fixed: NCCT Issue 962 - Figure 10-12: "An augmentation that is not an augmentable type" is incomplete. No change, fixed in previous draft. Addressed NNCT Issue 963 - Figures 10-12 and 10-13 An Augmentation that is not an augmentation type. Provided supporting text. Addressed NCCT Issue 863 - NDR [Rule 10-49] (Names use common abbreviations) Violation. OK in current release. Revised that rule to be SHOULD in alignment with relaxation of naming rules to SHOULD. Addressed NCCT Issue 864 - NDR [Rule 11-31] (Standard opening phrase for element) Violation. No change; fixed in 4.0. Addressed NCCT Issue 866 - Duplicate terms in LocalTerminology. No change. Not in 4.0. Fixed NCCT Issue 939 - NDR rule 10-69 applies only to REF, should apply to REF,EXT. Revised as requested. Addressed NCCT Issue 935 - typo in section 5.3. No change. Fixed in previous version. Updated date & version of doc. --- appinfo.xsd | 2 +- list-of-rules-as-java-properties.txt | 238 - ndr-diff.html | 6496 ---------------------- ndr-functions-interface.xsl | 55 - ndr-functions.xsl | 295 +- ndr-id-map.xml | 374 +- ndr-rules-conformance-target-ext.sch | 641 ++- ndr-rules-conformance-target-ext.sch.xsl | 3350 +++++------ ndr-rules-conformance-target-ins.sch | 33 +- ndr-rules-conformance-target-ins.sch.xsl | 137 +- ndr-rules-conformance-target-ref.sch | 692 +-- ndr-rules-conformance-target-ref.sch.xsl | 3596 ++++++------ ndr-rules-conformance-target-set.sch | 35 +- ndr-rules-conformance-target-set.sch.xsl | 165 +- ndr-doc.html => niem-ndr-4.0beta2.html | 619 +-- ndr-doc.txt => niem-ndr-doc.txt | 2276 ++++---- structures.xsd | 7 +- xml-catalog.sch.xsl | 425 -- 18 files changed, 6317 insertions(+), 13119 deletions(-) delete mode 100644 list-of-rules-as-java-properties.txt delete mode 100644 ndr-diff.html delete mode 100644 ndr-functions-interface.xsl rename ndr-doc.html => niem-ndr-4.0beta2.html (50%) rename ndr-doc.txt => niem-ndr-doc.txt (82%) delete mode 100644 xml-catalog.sch.xsl diff --git a/appinfo.xsd b/appinfo.xsd index e631f66..fbec100 100644 --- a/appinfo.xsd +++ b/appinfo.xsd @@ -1,7 +1,7 @@ diff --git a/list-of-rules-as-java-properties.txt b/list-of-rules-as-java-properties.txt deleted file mode 100644 index 478a4e2..0000000 --- a/list-of-rules-as-java-properties.txt +++ /dev/null @@ -1,238 +0,0 @@ -#=Rule 4-1 # Conformance targets defined -#=Rule 4-2 # Conformance targets defined -is-ctas-conformant-document=Rule 4-3 # Conformance target identifiers -req-ct=Rule 4-4 # Conformance target identifiers -req-ct-ref=Rule 4-5 # Conformance target identifiers -req-ct-ext=Rule 4-6 # Conformance target identifiers -well-formed-xml=Rule 7-1 # Conformance to XML -ns-valid=Rule 7-2 # Conformance to XML Namespaces -is-schema-doc=Rule 7-3 # Conformance to XML Schema -rule-doc-element-is-xs-schema=Rule 7-4 # Conformance to XML Schema -#=Rule 7-5 # ISO 11179 Part 5 -rule-base-type-not-xml-ns=Rule 9-1 # Types prohibited as base types -no-base-xs-id=Rule 9-2 # Types prohibited as base types -no-base-xs-idref=Rule 9-3 # Types prohibited as base types -no-base-xs-idrefs=Rule 9-4 # Types prohibited as base types -no-base-xs-anyType=Rule 9-5 # Types prohibited as base types -no-base-xs-anySimpleType=Rule 9-6 # Types prohibited as base types -no-base-xs-NOTATION=Rule 9-7 # Types prohibited as base types -no-base-xs-ENTITY=Rule 9-8 # Types prohibited as base types -no-base-xs-ENTITIES=Rule 9-9 # Types prohibited as base types -st-top-level=Rule 9-10 # Simple type definition -no-st-final=Rule 9-11 # Simple type definition -st-has-dd=Rule 9-12 # Simple type definition -no-itemType-xs-id=Rule 9-13 # Simple types prohibited as list item types -no-itemType-xs-idref=Rule 9-14 # Simple types prohibited as list item types -no-itemType-xs-anySimpleType=Rule 9-15 # Simple types prohibited as list item types -no-itemType-xs-entity=Rule 9-16 # Simple types prohibited as list item types -no-memberTypes-xs-id=Rule 9-17 # Simple types prohibited as union member types -no-memberTypes-xs-idref=Rule 9-18 # Simple types prohibited as union member types -no-memberTypes-xs-idrefs=Rule 9-19 # Simple types prohibited as union member types -no-memberTypes-xs-anySimpleType=Rule 9-20 # Simple types prohibited as union member types -no-memberTypes-xs-entity=Rule 9-21 # Simple types prohibited as union member types -no-memberTypes-xs-entities=Rule 9-22 # Simple types prohibited as union member types -enum-has-dd=Rule 9-23 # Simple type definition -ct-top-level=Rule 9-24 # Complex type definition -ct-has-dd=Rule 9-25 # Complex type definition -ct-not-mixed=Rule 9-26 # No mixed content -cc-not-mixed=Rule 9-27 # No mixed content -ct-has-content-type=Rule 9-28 # Complex type definition -ct-cc-is-extension=Rule 9-29 # Complex content -rule-ref-ccc-base-has-cc=Rule 9-30 # Base type of complex type with complex content has complex content -rule-set-ccc-base-has-cc=Rule 9-31 # Base type of complex type with complex content has complex content -ct-sc-has-extension=Rule 9-32 # Simple content -no-ct-block=Rule 9-33 # Complex type definition -no-ct-final=Rule 9-34 # Complex type definition -el-top-level=Rule 9-35 # Element declaration -el-has-dd=Rule 9-36 # Element declaration -el-with-no-type-is-abstract=Rule 9-37 # Element declaration -el-with-type-xs-anysimpletype-is-abstract=Rule 9-38 # Element declaration -el-type-not-xs=Rule 9-39 # Element declaration -el-type-ns-not-special=Rule 9-40 # Element declaration -el-type-not-st=Rule 9-41 # Element declaration -no-el-block=Rule 9-42 # Element declaration -no-el-final=Rule 9-43 # Element declaration -no-el-default=Rule 9-44 # No element value constraints -no-el-fixed=Rule 9-45 # No element value constraints -el-is-nillable=Rule 9-46 # Element declaration -att-top-level=Rule 9-47 # Attribute declaration -at-has-dd=Rule 9-48 # Attribute declaration -attr-has-type=Rule 9-49 # Attribute declaration -no-type-xs-id=Rule 9-50 # Prohibited attribute types -no-type-xs-idref=Rule 9-51 # Prohibited attribute types -no-type-xs-idrefs=Rule 9-52 # Prohibited attribute types -no-type-xs-entity=Rule 9-53 # Prohibited attribute types -no-type-xs-entities=Rule 9-54 # Prohibited attribute types -no-type-xs-anySimpleType=Rule 9-55 # Prohibited attribute types -no-at-default=Rule 9-56 # No attribute value constraints -no-at-fixed=Rule 9-57 # No attribute value constraints -no-el-notation=Rule 9-58 # Notation declaration -#=Rule 9-59 # Model group -no-all=Rule 9-60 # Model group -seq-in-ext=Rule 9-61 # Sequence -seq-in-restr=Rule 9-62 # Sequence -no-choice=Rule 9-63 # Choice -req-seq-choice=Rule 9-64 # Choice -seq-minOccurs=Rule 9-65 # Sequence cardinality -seq-maxOccurs=Rule 9-66 # Sequence cardinality -choice-minOccurs=Rule 9-67 # Choice cardinality -choice-maxOccurs=Rule 9-68 # Choice cardinality -no-xs-any=Rule 9-69 # Wildcard -no-anyattribute=Rule 9-70 # Wildcard -no-xs-unique=Rule 9-71 # Identity-constraint definition components -no-xs-key=Rule 9-72 # Identity-constraint definition components -no-xs-keyref=Rule 9-73 # Identity-constraint definition components -no-xs-group=Rule 9-74 # Model group definition -no-def-attr-grp=Rule 9-75 # Attribute group definition -no-comments=Rule 9-76 # Annotation components -doc-has-no-els=Rule 9-77 # Annotation components -appinfo-has-els=Rule 9-78 # Application information annotation -appinfo-el-has-ns=Rule 9-79 # Application information annotation -no-xs-in-appinfo=Rule 9-80 # Application information annotation -rule-schema-has-dd=Rule 9-81 # Schema as a whole -req-target-ns=Rule 9-82 # Schema as a whole -target-ns-is-rfc3986=Rule 9-83 # Schema as a whole -has-version=Rule 9-84 # Schema as a whole -no-blockdefault=Rule 9-85 # Schema as a whole -no-finalDefault=Rule 9-86 # Schema as a whole -no-redefine=Rule 9-87 # Schema assembly -no-include=Rule 9-88 # Schema assembly -xs-import-has-ns=Rule 9-89 # Schema assembly -rule-set-is-closed=Rule 9-90 # Schema assembly -xs-import-referenced-namespaces-type=Rule 9-91 # Namespaces for referenced components are imported -xs-import-referenced-namespaces-base=Rule 9-92 # Namespaces for referenced components are imported -xs-import-referenced-namespaces-itemType=Rule 9-93 # Namespaces for referenced components are imported -xs-import-referenced-namespaces-memberTypes=Rule 9-94 # Namespaces for referenced components are imported -xs-import-referenced-namespaces-ref=Rule 9-95 # Namespaces for referenced components are imported -xs-import-referenced-namespaces-sg=Rule 9-96 # Namespaces for referenced components are imported -code-classes=Rule 10-1 # Categories of NIEM type definitions -object-with-cc-derived-from-object=Rule 10-2 # Object types with complex content -rule-roleOf-is-object-type=Rule 10-3 # Role types and roles -rule-ct-has-roleOf-is-object-type=Rule 10-4 # Role types and roles -#=Rule 10-5 # Role types and roles -#=Rule 10-6 # Role types and roles -rule-external-import-has-dd=Rule 10-7 # Import of external namespace -#=Rule 10-8 # External adapter types -rule-adapter-type-structure=Rule 10-9 # External adapter types -el-ref-from-external=Rule 10-10 # External adapter types -rule-ref-extadapt-not-base=Rule 10-11 # External adapter types -rule-set-extadapt-not-base=Rule 10-12 # External adapter types -rule-ext-attr-use-in-eat=Rule 10-13 # External attribute use -ext-attr-use-has-dd=Rule 10-14 # External attribute use -ext-attr-not-id=Rule 10-15 # External attribute use -rule-ext-element-use-has-dd=Rule 10-16 # External element use -rule-code-type-name-suffix=Rule 10-17 # Code types -proxy-type-structure=Rule 10-18 # Proxy types -rule-association-type-derived-from-association-type=Rule 10-19 # Association types -rule-association-el-type-is-association-type=Rule 10-20 # Association element declarations -augmentable-type-has-aug-point=Rule 10-21 # Augmentable types -augmentable-type-has-at-most-one-aug-point=Rule 10-22 # Augmentable types -aug-el-matches-aug-type=Rule 10-23 # Augmentation point element declarations -aug-pt-untyped=Rule 10-24 # Augmentation point element declarations -aug-pt-no-subst-grp=Rule 10-25 # Augmentation point element declarations -aug-el-in-type=Rule 10-26 # Augmentation point element use -aug-el-is-optional=Rule 10-27 # Augmentation point element use -aug-el-is-unbounded=Rule 10-28 # Augmentation point element use -aug-ref-is-last=Rule 10-29 # Augmentation point element use -#=Rule 10-30 # Augmentation types -aug-type-name=Rule 10-31 # Augmentation types -rule-augmentation-type-structure=Rule 10-32 # Augmentation types -rule-type-derived-from-augmentation-type=Rule 10-33 # Augmentation types -rule-augmentation-el-type-is-augmentation-type=Rule 10-34 # Augmentation element declarations -rule-aug-el-not-used=Rule 10-35 # Augmentation element declarations -#=Rule 10-36 # Metadata types -#=Rule 10-37 # Metadata types -rule-metadata-type-derived-from-metadata-type=Rule 10-38 # Metadata types -rule-metadata-el-type-is-metadata-type=Rule 10-39 # Metadata element declarations -rule-metadata-applicable-elements=Rule 10-40 # Metadata element declarations -el-representation-is-abstract=Rule 10-41 # The Representation pattern -#=Rule 10-42 # Rules for NIEM modeling, by NIEM concept -#=Rule 10-43 # Naming rules -#=Rule 10-44 # Naming rules -#=Rule 10-45 # Naming rules -#=Rule 10-46 # Character case -#=Rule 10-47 # Character case -#=Rule 10-48 # Character case -#=Rule 10-49 # Use of acronyms and abbreviations -rule-lt-single-doc=Rule 10-50 # Use of Acronyms, Initialisms, Abbreviations, and Jargon -rule-lt-meaning=Rule 10-51 # Use of Acronyms, Initialisms, Abbreviations, and Jargon -#=Rule 10-52 # Word forms -#=Rule 10-53 # Word forms -#=Rule 10-54 # Word forms -#=Rule 10-55 # Naming rules -#=Rule 10-56 # Object-class term -#=Rule 10-57 # Property term -#=Rule 10-58 # Qualifier terms -#=Rule 10-59 # Qualifier terms -#=Rule 10-60 # Qualifier terms -#=Rule 10-61 # Representation terms -rule-csc-has-rep-term=Rule 10-62 # Representation terms -#=Rule 10-63 # Representation terms -#=Rule 10-64 # Representation terms -#=Rule 10-65 # Machine-readable annotations -#=Rule 10-66 # Deprecation -rule-use-of-deprecated=Rule 10-67 # Deprecation -rule-owner-of-appinfo-conformantindicator=Rule 10-68 # The NIEM appinfo namespace -rule-owner-of-appinfo-externaladaptertypeindicator=Rule 10-69 # The NIEM appinfo namespace -rule-owner-of-appinfo-appliestotypes=Rule 10-70 # appinfo:appliesToTypes annotation -appliestotypes-refs-types=Rule 10-71 # appinfo:appliesToTypes annotation -rule-owner-of-appinfo-appliestoelements=Rule 10-72 # appinfo:appliesToElements annotation -appliestoelements-refs-elements=Rule 10-73 # appinfo:appliesToElements annotation -lt-schema=Rule 10-74 # Local terminology -lt-has-defn=Rule 10-75 # Local terminology -#=Rule 10-76 # NIEM structural facilities -type-name-suffix=Rule 11-1 # Type definition components -type-name-upper-camel-case=Rule 11-2 # Type definition components -type-base-from-ns=Rule 11-3 # Type definition hierarchy -st-name-ends-in-simpletype=Rule 11-4 # Simple type definition -st-name-upper-camel-case=Rule 11-5 # Simple type definition -#=Rule 11-6 # Derivation by list -list-item-type-ns=Rule 11-7 # Derivation by list -union-member-type-ns=Rule 11-8 # Derivation by union -code-st-name=Rule 11-9 # Code simple types -code-st-has-enum=Rule 11-10 # Code simple types -rule-ct-sc-has-soag=Rule 11-11 # Complex type definition -rule-el-upper-camel-case=Rule 11-12 # Element declaration -el-type-name-not-simple-type=Rule 11-13 # Element declaration -el-type-conformant-ns=Rule 11-14 # Element declaration -el-abstract-is-abstract=Rule 11-15 # Element declaration -rule-ref-el-csc-uses-rep-term=Rule 11-16 # Object element declarations -rule-set-el-csc-uses-rep-term=Rule 11-17 # Object element declarations -el-sg-from-ns=Rule 11-18 # Element substitution group -att-type-from-ns=Rule 11-19 # Attribute declaration -att-name-uses-rep-term=Rule 11-20 # Attribute declaration -rule-decl-introduced-once=Rule 11-21 # Element use -el-ref-from-ns=Rule 11-22 # Element use -att-ref-from-ns=Rule 11-23 # Attribute use -rule-known-att-grp-refs=Rule 11-24 # Attribute group use -#=Rule 11-25 # Human-readable documentation -#=Rule 11-26 # Human-readable documentation -#=Rule 11-27 # Human-readable documentation -#=Rule 11-28 # Human-readable documentation -def-11179-4-req=Rule 11-29 # Human-readable documentation -def-11179-4-rec=Rule 11-30 # Human-readable documentation -rule-sop-element=Rule 11-31 # Data definition opening phrases -rule-sop-complex-type=Rule 11-32 # Data definition opening phrases -rule-sop-simple-type=Rule 11-33 # Data definition opening phrases -#=Rule 11-34 # xs:schema document element restrictions -#=Rule 11-35 # xs:schema document element restrictions -xs-import-consistent-with-schema=Rule 11-36 # Schema assembly -rule-ext-imports-ext=Rule 11-37 # Schema assembly -structures-imported-conformant=Rule 11-38 # Supporting namespaces are imported as conformant -schema-for-xml-imported-conformant=Rule 11-39 # Supporting namespaces are imported as conformant -namespace-appears-once=Rule 11-40 # Schema assembly -rule-import-is-consistent=Rule 11-41 # Schema assembly -#=Rule 12-1 # XML instance document rules -rule-ref-refs-id=Rule 12-2 # Reference elements -rule-ref-and-id-have-same-validation-root=Rule 12-3 # Reference elements -#=Rule 12-4 # Reference elements -#=Rule 12-5 # Reference and content elements have same meaning -#=Rule 12-6 # XML instance document rules -#=Rule 12-7 # Instance metadata -#=Rule 12-8 # Instance metadata -#=Rule 12-9 # Instance metadata -#=Rule 12-10 # Instance metadata -#=Rule 12-11 # Instance metadata -rule-attr-metadata-refs-metadata=Rule 12-12 # Instance metadata -rule-attr-rel-metadata-refs-metadata=Rule 12-13 # Instance metadata -#=Rule 12-14 # Instance metadata diff --git a/ndr-diff.html b/ndr-diff.html deleted file mode 100644 index 99d3e1d..0000000 --- a/ndr-diff.html +++ /dev/null @@ -1,6496 +0,0 @@ - - - - - SVN diff - -

Go to first delta

-

From file: dest/ndr-doc.txt (revision 42801)

-

To file: dest/ndr-doc.txt (working copy)

-
-
-National Information Exchange Model Naming and Design Rules
-
-Version 3 4.0
-
-July0beta1
-
-March 31, 2014 2017
-
-NIEM Technical Architecture Committee (NTAC)
-
-Contents
-
-   The table of contents is omitted from this edition.
-
-Table of Figures
-
-   The table of figures is omitted from this edition.
-
-Table of Tables
-
-   The table of tables is omitted from this edition.
-
-Authors
-
-   Webb Roberts, Georgia Tech Research Institute (<webb.roberts@gtri.gatech.edu>), Lead Author
-
-Abstract
-
-   This document specifies the data model, XML Schema components, and XML data for use with the National Information Exchange Model (NIEM) version 3 4.0.
-
-Status
-
-   This document is a an early draft of the specification for XML Schema documents, components, and instances for use with NIEM 4. It represents the design presents a technical architecture that has evolved from through the collaborative work of the NIEM Business Architecture Committee (NBAC), 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 niem-comments@lists.gatech.edu.
-
-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 information interoperability 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 declarations 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. Developers 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 conformant to specific conformance targets. These targets are defined in order that they may be leveraged for comprehensive definitions of NIEM conformance. Such definitions may include more than the level of conformance defined by this NDR, and may include specific patterns of use, additional quality criteria, and requirements to reuse NIEM release schemas.
-
-1.1. Scope
-
-   This document was developed to specify NIEM 3.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.
-
-      *  Aggregate artifacts that define information exchanges and models, including information exchange packages (IEPs) and their specifications, information exchange package descriptions (IEPDs) or other forms of information exchange specifications (IESs), as well as enterprise information exchange models (EIEMs), and other other forms of model package descriptions (MPDs).
-
-      *  Normative guidance for the location of [schema documents] or for schema assembly.
-
-   This document is intended as a technical specification. It is not intended to be a tutorial or a user guide.
-
-1.2. Audience
-
-   This document targets practitioners and developers who employ NIEM for information exchange and interoperability. Such information exchanges may be between organizations or within an organization. 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 importantly, enforce a degree of standardization across a broad set of users.
-
-2. Document conventions and normative content
-
-   This document uses formatting and syntactic conventions to clarify meaning and avoid ambiguity.
-
-2.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 [RFC 2119]. All reference documents are recorded in Appendix A, References, below.
-
-2.2. Clark notation and qualified names
-
-   This document uses both Clark notation and QName notation to represent qualified names.
-
-   QName notation is defined by [XML Namespaces] Section 4, Qualified Names. A QName for the XML Schema string datatype is xs:string. Namespace prefixes used within this specification are listed in Section 2.3, Use of namespaces and namespace prefixes, below.
-
-   This document sometimes uses Clark notation to represent qualified names in normative text. Clark notation is described by [ClarkNS], and provides the information in a QName without the need to first define a namespace prefix, and then to reference that namespace prefix. A Clark notation representation for the qualified name for the XML Schema string datatype is {http://www.w3.org/2001/XMLSchema}string.
-
-   Each Clark notation value usually consists of a namespace URI surrounded by curly braces, concatenated with a local name. The exception to this is when Clark notation is used to represent the qualified name for an attribute with no namespace, which is ambiguous when represented using QName notation. For example, the element targetNamespace, which has no [namespace name] property, is represented in Clark notation as {}targetNamespace.
-
-2.3. Use of namespaces and namespace prefixes
-
-   The following namespace prefixes are used consistently within this specification. These prefixes are not normative; this document issues no requirement that these prefixes be used in any conformant artifact. Although there is no requirement for a schema or XML document to use a particular namespace prefix, the meaning of the following namespace prefixes have fixed meaning in this document.
-
-      *  xs: The namespace for the XML Schema definition language as defined by [XML Schema Structures] and [XML Schema Datatypes], "http://www.w3.org/2001/XMLSchema".
-
-      *  xsi: The XML Schema instance namespace, defined by [XML Schema Structures] Section 2.6, Schema-Related Markup in Documents Being Validated, for use in XML documents, "http://www.w3.org/2001/XMLSchema-instance".
-
-      *  sch: The Schematron namespace, as defined by [Schematron], "http://purl.oclc.org/dsdl/schematron".
-
-      *  nf: The namespace defined by this specification for XPath functions, "http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#NDRFunctions".
-
-      *  ct: The namespace defined by [CTAS] for the conformanceTargets attribute, "http://release.niem.gov/niem/conformanceTargets/3.0/".
-
-      *  appinfo: The namespace for the [appinfo namespace], "http://release.niem.gov/niem/appinfo/34.0/".
-
-      *  structures: The namespace for the [structures namespace], "http://release.niem.gov/niem/structures/3.0/".
-
-      *  term: The namespace for the [local terminology appinfo namespace], "http://release.niem.gov/niem/localTerminology/34.0/".
-
-2.4. Normative and informative content
-
-   This document includes a variety of content. Some content of this document is [normative], while other content is [informative]. In general, the informative material appears as supporting text, description, and rationales for the normative material.
-
-   [Definition: normative]
-
-      The term "normative" is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:
-
-         NORMATIVE -- statements provided for the prescriptive parts of the specification, providing that which is necessary in order to be able to claim conformance to the specification.
-
-   [Definition: informative]
-
-      The term "informative" is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:
-
-         INFORMATIVE (NON-NORMATIVE) -- statements provided for informational purposes, intended to assist the understanding or use of the specification and shall not contain provisions that are required for conformance.
-
-   Conventions used within this document include:
-
-   [Definition: <term>]
-
-      A formal definition of a term associated with NIEM.
-
-   Definitions are [normative]. Uses of these terms are given special formatting, using raised dots to identify the term, for example this use of the term [conformance target].
-
-   [Principle <number>]
-
-      A guiding principle for NIEM.
-
-   The principles represent requirements, concepts, and goals that have helped shape NIEM. Principles are informative, not normative, but act as the basis on which the rules are defined.
-
-   Accompanying each principle is a short discussion that justifies the application of the principle to NIEM design.
-
-   Principles are numbered in the order in which they appear in the document.
-
-2.4.1. Rules
-
-   A rule states a specific requirement on an artifact or on the interpretation of an artifact. The classes of artifacts are identified by [conformance targets] that are enumerated by this document in Section 4.1, Conformance targets defined, below. The rules are normative. Human-readable text in rules uses [RFC 2119] terminology as described in Section 3.1, RFC 2119 terminology, below, for normative requirements and recommendations.
-
-   [Rule <section>-<number>] (<applicability>)
-
-      An enforceable rule for NIEM.
-
-   Each rule has a classification, which is either "Constraint" or "Interpretation". If the classification is "Constraint", then the rule is a [constraint rule]. If the classification is "Interpretation", then the rule is an [interpretation rule].
-
-   [Definition: constraint rule]
-
-      A constraint rule is a rule that sets a requirement on an artifact with respect to its conformance to a [conformance target].
-
-   [Definition: interpretation rule]
-
-      An interpretation rule is a rule that sets the methodology, pattern, or procedure for understanding some aspect of an instance of a conformance target.
-
-   Each rule identifies its applicability. This identifies the conformance targets to which the rule applies. Each entry in the list is a code from Table Table 4-1, Codes representing conformance targets, below. 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 4, Conformance targets, below. For example, a rule with applicability "(REF, EXT)" would be applicable to a [reference schema document], as well as to an [extension schema document].
-
-   Rules are stated with the help of XML Infoset terminology (e.g., elements and attributes), as described by Section 3.3, XML Information Set terminology, below, and XML Schema terminology (e.g., schema components), as described by Section 3.4, XML Schema terminology, below. The choice of terminology is driven by which terms best express a concept. Certain concepts are more clearly expressed using XML Infoset terms items, others using XML Schema terms; still others are best expressed using a combination of terminology drawn from each standard.
-
-   Rules are numbered according to the section in which they appear and the order in which they appear within that section. For example, the first rule in Section 7 is Rule 7-1.
-
-2.4.2. Use of normative Schematron
-
-   This document defines many normative rules using Schematron rule-based validation syntax, as defined by [Schematron]. For example, see Rule 9-28, Complex type content is explicitly simple or complex. Effort has been made to make the rules precise and unambiguous. Very detailed text descriptions of rules can introduce ambiguity, and they are not directly executable by users. Providing NDR rules that are expressed as Schematron rules ensures that the rules are precise, and that they are directly executable through commercially-available and free tools.
-
-   Many rules herein do not have executable Schematron supporting them. Some are not fit for automatic validation, and others may be difficult or cumbersome to express in Schematron. In neither case are such rules any less normative. A rule that has no Schematron is just as normative as a rule that does have Schematron. The level of requirements and recommendations within a rule is expressed using terminology from [RFC 2119] as described in Section 3.1, RFC 2119 terminology, below.
-
-   The Schematron rules are written using XPath2 as defined by [XPath 2]. These executable rules are normative.
-
-   An execution of a Schematron pattern that issues a failed assertion (represented via sch:assert) represents a validation error, and signifies that the assessed artifact violates a requirement of a conformance rule. An example of a constraint rule that uses schematron is Rule 9-10, Simple type definition is top-level.
-
-   An execution of a Schematron pattern that issues a report (represented via sch:report) indicates cause for concern. This may be:
-
-      *  An indication that the automated rules are not sufficient to validate a conformance rule, and that another means is required to ensure conformance. This is frequently a reference to another specification. For example, see Rule 9-83, Target namespace is absolute URI, which references [RFC 3986].
-
-      *  an indication that an automated rule has found that the assessed artifact violates a recommendation of the specification (e.g., a SHOULD, rather than a MUST), and that attention should be paid to ensure that the artifact maintains the spirit of the specification. For example, see Rule 10-41, Name of element that ends in "Representation" is abstract.
-
-   In either case, a diagnostic report generated by testing an XML document against the Schematron rules may identify specific locations (e.g., line numbers) within the document that need further attention.
-
-2.4.3. Normative XPath functions
-
-   The Schematron within this document is supported by functions, to make the rules more comprehensible, and to abstract away process-specific operations. Each function has a normative XPath interface and a normative text definition. Any implementation provided for these functions should be considered informative, not normative, but may be useful for certain implementations of the rules.
-
-   The following XPath functions are defined normatively when used within Schematron by this specification:
-
-      *  nf:get-document-element($context as element()) as element()
-
-         Yields the document element of the XML document in which $context occurs.
-
-         This function provides the ability for a validator to consolidate multiple XML Schema documents and XML instance documents into a single XML document, which may simplify validation, and allow for preprocessing of xs:include elements.
-
-      *  nf:get-target-namespace($element as element()) as xs:anyURI?
-
-         Yields the target namespace of the XML Schema document in which $element appears. If it is a [schema document] with no target namespace defined, then it yields the zero-length xs:anyURI value (xs:anyURI('')). If the [XML document] in which $element appears is not a [schema document], then the function yields the empty sequence (()).
-
-      *  nf:resolve-namespace($context as element(), $namespace-uri as xs:anyURI) as element(xs:schema)?
-
-         Yields the document element of the first available [schema document] that has the target namespace $namespace-uri. If there is no such [schema document] available, it yields the empty sequence (()).
-
-      *  nf:resolve-type($context as element(), $qname as xs:QName) as element()?
-
-         Yields the first occurence occurrence of an element xs:simpleType or xs:complexType that defines a type with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no such occurrence, it yields the empty sequence (()).
-
-      *  nf:resolve-element($context as element(), $qname as xs:QName) as element(xs:element)?
-
-         Yields the first occurrence of an element xs:element that declares an element with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no occurrence available, it yields the empty sequence. (())
-
-      *  nf:has-effective-conformance-target-identifier($context as element(), $match as xs:anyURI) as xs:boolean
-
-         Yields true if and only if an [effective conformance target identifier] of the XML document containing $context is $match.
-
-2.4.4. Normative Schematron namespace declarations
-
-   The following Schematron namespace declarations are normative for the Schematron rules and supporting Schematron code within this specification:
-
-   Figure 2-1: Normative Schematron namespace declarations
-
-      <sch:ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/>
-      <sch:ns prefix="xsl" uri="http://www.w3.org/1999/XSL/Transform"/>
-      <sch:ns prefix="nf" uri="http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#NDRFunctions"/>
-      <sch:ns prefix="ct" uri="http://release.niem.gov/niem/conformanceTargets/3.0/"/>
-      <sch:ns prefix="xsi" uri="http://www.w3.org/2001/XMLSchema-instance"/>
-      <sch:ns prefix="appinfo" uri="http://release.niem.gov/niem/appinfo/34.0/"/>
-      <sch:ns prefix="structures" uri="http://release.niem.gov/niem/structures/34.0/"/>
-      <sch:ns prefix="term" uri="http://release.niem.gov/niem/localTerminologyappinfo/34.0/"/>
-
-   Note that the binding of the prefix xml to the XML namespace ("http://www.w3.org/XML/1998/namespace") is implicit.
-
-2.5. Additional formatting
-
-   In addition to the special formatting above, this document uses additional formatting conventions.
-
-   [square brackets]: Terms in plain [square brackets] are properties of XML information set information items, as defined by [XML Infoset]. The information items and many of the information items' properties are defined in that document. [XML Schema Structures] defines additional information item properties that are contributed by validation of an [XML document] against an [XML Schema].
-
-   {curly brackets}: Terms in plain {curly brackets} are properties of [schema components], as defined by [XML Schema Structures].
-
-   Courier: All words appearing in Courier font are values, objects, keywords, or literal XML text.
-
-   Italics: A phrase appearing in italics is one of:
-
-      *  a title of a section of document or a rule,
-
-      *  a locally-defined term, often one that is not normatively defined, or
-
-      *  is emphasized for importance or prominence.
-
-   Bold: A phrase appearing in bold is one of:
-
-      *  a term being defined within a definition,
-
-      *  a term that was bold in the original source text for a quote
-
-      *  a heading, such as for a section, a figure, a principle, definition, or rule, or
-
-      *  a cross-reference within the document, to a reference to an outside document, or to a normative heading.
-
-   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 2-2: Example of an XML fragment
-
-      <xs:complexType name="PersonType">
-        ...
-      </xs:complexType>
-
-3. Terminology
-
-   This document uses standard terminology from other standards to explain the principles and rules that describe NIEM. In addition, it defines terms related to these other standards. This section enumerates this externally-dependent terminology.
-
-3.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 [RFC 2119].
-
-3.2. XML terminology
-
-   [Definition: XML document]
-
-      The term "XML document" is as defined by [XML] Section 2, Documents, which states:
-
-         A data object is an XML document if it is well-formed, as defined in this specification. In addition, the XML document is valid if it meets certain further constraints.
-
-3.3. XML Information Set terminology
-
-   When discussing XML documents, this document uses terminology and language as defined by [XML Infoset].
-
-   [XML Infoset] uses the term "information item" to describe pieces of XML documents. Documents, elements, and attributes are types of information items. The use of the term "element information item", for example, refers to the term as defined by [XML Infoset]. Shorthand terms may also be used to refer to information items, such as [element], as defined below. The information items are identified and defined by [XML Infoset] Section 2, Information Items.
-
-   [Definition: element]
-
-      An element is an element information item, as defined by [XML Infoset] Section 2.2, Element Information Items
-
-   [Definition: attribute]
-
-      An attribute is an attribute information item, as defined by [XML Infoset] Section 2.3, Attribute Information Items
-
-   [XML Infoset] also describes properties of information items. Each class of information item carries a set of properties. Each property has a name, and the property is identified by putting the name into square brackets. For example, the element that contains an attribute is described as the [owner element] of an attribute information item, as defined in [XML Infoset] Section 2.3, Attribute Information Items.
-
-   Shorthand terms for properties of information items include:
-
-      *  parent (of an element): the value of the [parent] property of an element information item
-
-      *  child (of an element): a member of the list of information items that is the value of the [children] property of an element information item
-
-      *  owner (of an attribute): the value of the [owner element] property of an attribute information item
-
-      *  document element: the value of the [document element] property of a document information item; preferred over the term "root element".
-
-3.4. XML Schema terminology
-
-   This document uses many terms from [XML Schema Structures] and [XML Schema Datatypes] in a normative way.
-
-   [Definition: schema component]
-
-      The term "schema component" is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:
-
-         Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.
-
-   Note that this defines an abstract concept. This is not a direct reference to elements that are defined by the [XML Schema definition language]; this is an abstract concept that might be realized within a tool as an in-memory model of data objects.
-
-   [Definition: XML Schema]
-
-      The term "XML Schema" is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:
-
-         An XML Schema is a set of schema components.
-
-   Note, again, that this is an abstract concept: the set of abstract [schema components] that are put together to define a schema against which an XML document might be validated.
-
-   [Definition: XML Schema definition language]
-
-      The term "XML Schema definition language" is as defined by [XML Schema Structures] subsection Abstract, which states:
-
-         XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs).
-
-   This describes the XML syntax (and related semantics) defined by the XML Schema specifications. It is through the [XML Schema definition language] that a complex type definition schema component is created using the xs:complexType element.
-
-   [Definition: schema document]
-
-      The term "schema document" is as defined by [XML Schema Structures] Section 3.1.2, XML Representations of Components, which states:
-
-         A document in this form (i.e. a <schema> element information item) is a schema document.
-
-   This definition describes an [XML document] that follows the syntax of the [XML Schema definition language].
-
-   [Definition: valid]
-
-      The term "valid" is as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, which states:
-
-         [Definition:] the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.
-
-      The referenced clause 1 is a part of a description of schema-validity:
-
-         Schema-validity assessment has two aspects:
-
-            1. Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;
-
-            2. Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.
-
-   In addition, this specification locally defines terms relevant to XML Schema concepts:
-
-   [Definition: instance document]
-
-      An instance document (of an [XML Schema]) is an [XML document] that is [valid] against the [XML Schema].
-
-   The term "instance document" is used with [XML Schema Structures], but is not defined therein.
-
-   [Definition: XML Schema document set]
-
-      An XML Schema document set is a set of [schema documents] that together define an [XML Schema] suitable for assessing the [validity] of an [XML document].
-
-   Schema assembly is a tricky topic that is not resolved by this document. Other specifications may express specifics about the process of turning a set of [schema documents] into an [XML Schema]. Methods used may include use of tool-specific schema caches and mappings, use of XML catalogs and entity resolvers, use of schemaLocation attributes on xs:import elements, and xsi:schemaLocation attributes in XML documents, among others. The topic of schema assembly is discussed in Section 6.2.10, Schema locations provided in schema documents are hints, below. This specification abstracts away details of schema assembly through the use of XPath functions described by Section 2.4.3, Normative XPath functions, above.
-
-3.4.1. Schema components
-
-   In this document, the name of a referenced schema component may appear without the suffix "schema component" to enhance readability of the text. For example, the term "complex type definition" may be used instead of "complex type definition schema component".
-
-   [Definition: base type definition]
-
-      The term "base type definition" is as defined by [XML Schema Structures] Section 2.2.1.1, Type Definition Hierarchy, which states:
-
-         A type definition used as the basis for an extension or restriction is known as the base type definition of that definition.
-
-   [Definition: simple type definition]
-
-      The term "simple type definition" is as defined by [XML Schema Structures] Section 2.2.1.2, Simple Type Definition.
-
-   [Definition: complex type definition]
-
-      The term "complex type definition" is as defined by [XML Schema Structures] Section 2.2.1.3, Complex Type Definition.
-
-   [Definition: element declaration]
-
-      The term "element declaration" is as defined by [XML Schema Structures] Section 2.2.2.1, Element Declaration.
-
-3.4.2. Schema information set contributions
-
-   As described in Section 3.3, XML Information Set terminology, above, the XML Information Set specification defined properties of the content of XML documents. The XML Schema specification also provides properties of the content of XML documents. These properties are called Schema information set contribution, as described by [XML Schema Structures] Section 2.3, Constraints and Validation Rules, which defines them as:
-
-      Augmentations to post-schema-validation infosets expressed by schema components, which follow as a consequence of validation and/or assessment.
-
-   This document uses these property terms within definitions and other text. Terms used include:
-
-      *  [type definition] (of an element): The type of the element as determined at run-time. This will reflect the use of the attribute xsi:type in an XML document.
-
-3.5. XML Namespaces terminology
-
-   This document uses XML Namespaces as defined by [XML Namespaces] and [XML Namespaces Errata].
-
-3.6. Conformance Targets Attribute Specification terminology
-
-   [CTAS] defines several terms used normatively within this specification.
-
-   [Definition: conformance target]
-
-      The term "conformance target" is as defined by [CTAS], which states:
-
-         A conformance target is a class of artifact, such as an interface, protocol, document, platform, process or service, that is the subject of conformance clauses and normative statements. There may be several conformance targets defined within a specification, and these targets may be diverse so as to reflect different aspects of a specification. For example, a protocol message and a protocol engine may be different conformance targets.
-
-   [Definition: conformance target identifier]
-
-      The term "conformance target identifier" is as defined by [CTAS], which states:
-
-         A conformance target identifier is an internationalized resource identifier that uniquely identifies a conformance target.
-
-   [Definition: effective conformance target identifier]
-
-      The term "effective conformance target identifier" is as defined by [CTAS] Section 4, Semantics and Use, which states:
-
-         An effective conformance target identifier of a conformant document is an internationalized resource identifier reference that occurs in the document's effective conformance targets attribute.
-
-4. Conformance targets
-
-4.1. Conformance targets defined
-
-   This section defines and describes conformance targets of this specification. Each conformance target has a formal definition, along with a notional description of the characterstics characteristics and intent of each. These include:
-
-   * Section 4.1.1, Reference schema document
-   * Section 4.1.2, Extension schema document
-   * Section 4.1.3, Schema document set
-   * Section 4.1.4, Instance documents and elements
-
-4.1.1. Reference schema document
-
-   [Definition: reference schema document]
-
-      A reference schema document is a [schema document] that is intended to provide the authoritative definitions of broadly reusable [schema components]. It is a [conformance target] of this specification. A reference schema document MUST conform to all rules of this specification that apply to this conformance target. An [XML document] with a [conformance target identifier] of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument MUST be a conformant reference schema document.
-
-   A [reference schema document] is a [schema document] that is intended to be the authoritative definition schema for a namespace. Examples include NIEM Core and NIEM domains.
-
-   Some characteristics of a [reference schema document]:
-
-      *  It is explicitly designated as a reference schema via the conformance targets attribute, per Rule 4-5, Schema claims reference schema conformance target.
-
-      *  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 information exchanges and extension schema documents.
-
-      *  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 will be defined as a reference schema.
-
-   The rules for reference schema documents are more stringent than are the rules for other classes of NIEM-conformant schemas. Reference schema documents are intended to support the broadest reuse. They are very uniform in their structure. As they are the primary definitions for schema components, they do not need to restrict other data definitions, and they are not allowed to use XML Schema's restriction mechanism (e.g., Rule 9-29, Complex content uses extension). Reference schema documents are intended to be as regular and simple as possible.
-
-4.1.2. Extension schema document
-
-   [Definition: extension schema document]
-
-      An extension schema document is a [schema document] that is intended to provide definitions of [schema components] that are intended for reuse within a more narrow scope than those defined by a [reference schema document]. It is a [conformance target] of this specification. An extension schema document MUST conform to all rules of this specification that apply to this conformance target. An XML document with a [conformance target identifier] of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument MUST be an extension schema document.
-
-   Characteristics of an [extension schema document] include:
-
-      *  It is explicitly designated as an [extension schema document] via the conformance targets attribute.
-
-      *  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 schema documents].
-
-      *  It is intended to express the additional vocabulary required for an information exchange, above and beyond the vocabulary available from reference schemas, and to also support additional XML Schema validation requirements for an exchange.
-
-      *  It satisfies all rules specified in this document for [extension schema documents].
-
-   An extension schema in an information exchange specification serves several functions. First, it defines new content within a new namespace, which may be an exchange-specific namespace or a namespace shared by several exchanges. This content is NIEM-conformant but has fewer restrictions on it than do [reference schema documents]. Second, the [extension schema document] bases its content on content from [reference schema documents], where appropriate. Methods of deriving content include using (by reference) existing [schema components], as well as creating extensions and restrictions of existing components.
-
-   For example, an information exchange specification may define a type for an exchange-specific phone number and base that type on a type defined by the NIEM Core reference schema document. This exchange-specific phone number type may restrict the NIEM Core type to limit those possibilities that are permitted of the base type. Exchange 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 [reference schema documents].
-
-   Note that exchange specifications may define schemas that meet the criteria of reference schemas for those components that its developers wish to nominate for later inclusion in NIEM Core or in domains.
-
-4.1.3. Schema document set
-
-   A [conformant schema document set] is a set of schema documents that are capable of validating XML docments documents.
-
-   [Definition: conformant schema document set]
-
-      A conformant schema document set is a collection of [schema documents] that together are capable of [validating] a [conformant instance XML document]. It is a [conformance target] of this specification. A conformant schema document set MUST conform to all rules of this specification that apply to this conformance target.
-
-   A [conformant schema document set] has strong dependencies on [reference schema documents] and [extension schema documents]. Without the guarantees provided by those conformance targets, the rules for a [conformant schema document set] would not be helpful. Those schemas in a schema set that are marked as reference or extension schemas are required to conform to the appropriate conformance targets.
-
-Rule 4-1. Schema marked as reference schema document must conform
-
-   [Rule 4-1] (SET)
-
-      Any [schema document] with an [effective conformance target identifier] of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument MUST be a [reference schema document].
-
-Rule 4-2. Schema marked as extension schema document must conform
-
-   [Rule 4-2] (SET)
-
-      Any [schema document] with an [effective conformance target identifier] of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument MUST be an [extension schema document].
-
-4.1.4. Instance 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: conformant instance XML document]
-
-      A conformant instance XML document is an [XML document] that is [instance document] [valid] to a [conformant schema document set]. It is a [conformance target] of this specification. A conformant instance XML document MUST conform to all rules of this specification that apply to this conformance target.
-
-   Characteristics of a [conformant instance XML document] include:
-
-      *  The document element is locally schema-valid.
-
-      *  Each element information item within the [XML document] that has property [namespace name] matching the target namespace of a [reference schema document] or [extension schema document] is a [conformant element information item].
-
-   Schema-validity may be assessed against a single set of schemas or against multiple sets of schemas.
-
-   Assessment against schemas may be directed by a Model Package Description (MPD), by other instructions, or by other tools.
-
-   Note that this specification does not require the document element of a [conformant instance XML document] to be a [conformant element information item]. Other specifications, such as the MPD specification, may add additional constraints to these in order to specify MPD-specific or exchange-specific conformance contraints constraints.
-
-   [Definition: conformant element information item]
-
-      A 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 document] or [extension schema document].
-
-         *  It occurs within a [conformant instance XML document].
-
-         *  It is locally schema-valid.
-
-         *  It satisfies all rules specified in this document applicable to an element in a [conformant instance XML document].
-
-   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 that the {process contents} with a value of "skip". As described by [XML Schema Structures] Section 3.10.1, The Wildcard Schema Component, the content of an element introduced by a wildcard with {process contents} set to "skip" does not have any schema validity constraint; it is only required to be well-formed XML. Within a NIEM-conformant XML document, each element that is from a NIEM namespace conforms to its schema specification.
-
-4.2. Applicability of rules to conformance targets
-
-   Each rule within this document is applicable to one or more of the conformance targets identified by Section 4.1, Conformance targets defined, above. Each rule identifies its applicability as described in Section 2.4.1, Rules, above. The applicability field of each rule will contain one or more code values from Table Table 4-1, Codes representing conformance targets, below. A rule is applicable to the identified conformance targets.
-
-   Table 4-1: Codes representing conformance targets
-
-      Code|Conformance target
-
-      REF|reference REF|[reference schema document]
-
-      EXT|[extension
-
-      EXT|extension schema document]
-
-      SET|[conformant
-
-      SET|Conformant schema document set]
-
-      INS|[conformant
-
-      INS|Conformant instance XML document]
-
-4.3. Conformance target identifiers
-
-   A conformant schema document claims to be conformant thorough the use of a set of [conformance target identifiers].
-
-Rule 4-3. Schema is CTAS-conformant
-
-   [Rule 4-3] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:report test="true()">The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification.</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   The term "conformant document" is defined by [CTAS] Section 3.2, Conformance to this Specification. Note that this rule uses sch:report to provide a location that must be checked for conformance to an external standard, and does not itself provide any enforcement or checking of the actual rule.
-
-Rule 4-4. Document element has attribute ct:conformanceTargets
-
-   [Rule 4-4] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)
-                             or exists(@ct:conformanceTargets)]">
-          <sch:assert test="(. is nf:get-document-element(.)) = exists(@ct:conformanceTargets)"
-            >The [document element] of the XML document, and only the [document element], MUST own an attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 4-5. Schema claims reference schema conformance target
-
-   [Rule 4-5] (REF)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:assert test="nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))"
-            >The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [effective conformance target identifier].
-
-Rule 4-6. Schema claims extension conformance target
-
-   [Rule 4-6] (EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:assert test="nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument'))"
-            >The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [effective conformance target identifier].
-
-5. The NIEM conceptual model
-
-   This section describes aspets aspects of the RDF model, and provides a mapping between NIEM concepts and the RDF model.
-
-   * Section 5.1, Purpose of the NIEM conceptual model
-   * Section 5.2, The RDF model
-   * Section 5.3, NIEM in terms of RDF
-   * Section 5.4, Unique identification of data objects
-   * Section 5.5, NIEM data is explicit, not implicit
-   * Section 5.6, Mapping of NIEM concepts to RDF concepts
-
-5.1. Purpose of the NIEM conceptual model
-
-   Each release of NIEM provides a concrete data model, in the form of a set of [schema documents]. These schema documents may be used to build messages and information exchanges. The schema documents spell out what kinds of objects exist and how those objects may be related. A set of XML data that follows the rules of NIEM implies specific meaning. The varieties of [schema components] used within conformant schema documents 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 through the construction and use of schema components.
-
-   In a schema, the meaning of a schema component may be described using the xs:documentation element, or additional information may be included via use of the xs: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. This meaning 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 this section, 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.
-
-5.2. The RDF model
-
-   This section identifies features of RDF and RDFS, in order to establish a mapping between RDF semantics and NIEM. A reader should read the referenced source documents to obtain a full understanding of the concepts mentioned in this section.
-
-   RDF establishes a graph-based data model, as described by [RDF Concepts] Section 1.1, Graph-based Data Model, which states:
-
-      The core structure of the abstract syntax is a set of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph.
-
-   [RDF Concepts] also states:
-
-      There can be three kinds of nodes in an RDF graph: IRIs, literals, and blank nodes.
-
-   [RDF Concepts] Section 1.2, Resources and Statements describes resources:
-
-      Any IRI or literal denotes something in the world (the "universe of discourse"). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with "entity" as it is used in the RDF Semantics specification. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its literal value.
-
-   [RDF Concepts] also describes relationships and blank nodes.
-
-      Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object. This statement corresponding to an RDF triple is known as an RDF statement. The predicate itself is an IRI and denotes a property, that is, a resource that can be thought of as a binary relation. (Relations that involve more than two entities can only be indirectly expressed in RDF.)
-
-      Unlike IRIs and literals, blank nodes do not identify specific resources. Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.
-
-   [RDF Concepts] Section 1.7, Equivalence, Entailment and Inconsistency describes the meaning of an RDF triple:
-
-      An RDF triple encodes a statement--a simple logical expression, or claim about the world. An RDF graph is the conjunction (logical AND) of its triples.
-
-   [RDF Concepts] Section 3.1, Triples defines an RDF triple:
-
-      An RDF triple consists of three components:
-
-         *  the subject, which is an IRI or a blank node
-
-         *  the predicate, which is an IRI
-
-         *  the object, which is an IRI, a literal or a blank node
-
-      An RDF triple is conventionally written in the order subject, predicate, object.
-
-5.3. NIEM in terms of RDF
-
-   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 defines NIEM data in XML terminology, complex types and elements, rather than using RDF terms, resources and properties. NIEM NIEM objects and associations conincide coincide with RDF resources; both objects and associations correspond to RDF resources with additional constraints:
-
-   NIEM associations are defined as n-ary properties, as described in [N-ary], "Use Case 3: N-ary relation with no distinguished participant". NIEM associations are defined in Section 10.3, Associations, below. Assertions are made via NIEM-conformant XML data, described by Section 12, XML instance document rules, below.
-
-   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. These elements and attributes are XML Schema representations, which correspond to RDF properties. NIEM-conformant XML Schemas describe things and their properties. NIEM-conformant data contains elements and attributes. These correspond to RDF resources and their properties, which describe their characteristics and relationships.
-
-5.4. Unique identification of data objects
-
-   In A NIEM, an data exchange is generally adhoc may be ephemeral and ad hoc. That is, a message may be generated transmitted without any expectation of persistence. It Such a message 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) carried by a message 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 XML document may use XML IDs carry any of these attributes to identify objects within it; messages:
-
-      *  Attribute xml:base (of type xs:anyURI) is defined by [XML Base] Section 3, xml:base Attribute, which states:
-
-            The NIEM attribute xml:base may be inserted in XML ID is documents to specify a base URI other than the base URI of the document or external entity.
-
-         An XML document has an implicit base URI, the identifier of the document itself. This attribute allows the base URI to be made explicit within a NIEM XML document.
-
-      *  Attribute structures:uri (of type xs:anyURI) may appear within an XML element to define a URI for that element. This may be an absolute URI (e.g., http://example.org/incident182#person12), or may be a relative URI (e.g., #person12). Relative URIs are resolved against a URI determined by the xml:base attributes in scope, falling back to the base URI of the containing document.
-
-      *  Attribute structures:id of (of type xs:IDID) provides a document-relative identifier for an element. These Semantically, "structures:id="abe92"" is equivalent to "structures:uri="#abe92"".
-
-      *  Attribute structures:ref (of type xs:IDREF) provides a reference to another element within a document, by providing a value of a structures:id attribute within the document. Semantically, "structures:ref="abe92"" is equivalent to "structures:uri="#abe92""
-
-   The values of URIs and IDs within NIEM XML documents are not assumed by NIEM presumed to have any universal significance; they need only particular significance. XML requires every ID to be unique within the its XML document, and for every IDREF to refer to an ID within the same document. The use mapping of IDs and IDREFs to URIs does not mean that the identifiers are persistent or significant.
-
-   These attributes provide the identifiers of objects. The properties of an ID is required only when an object must may be referenced within spread across several XML elements that have the document same identifer. NIEM recognizes no correlation between these local IDs and any URI These properties must be merged together to provide all the properties of a single object, as described by [JSON LD] Section 8.2, Node Objects:
-
-      The properties of
-
-   As a result node in a graph may be spread among different node objects within a document. When that happens, the basic mapping keys of the different node objects need to be merged to create the properties of the resulting node.
-
-   Mapping of NIEM data to RDF frequently involves the use of blank nodes, not universally-meaningful resource IRIS.
-
-   Any given implementation, message, or MPD may be defined to apply a URI or other universally meaningful identifier to an object or message. However, NIEM has no such requirement.
-
-5.5. NIEM data 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.
-
-5.6. Mapping of NIEM concepts to RDF concepts
-
-   This section has not yet been updated to accommodate attribute structures:uri, and the updated mappings for structures:id and structures:ref.
-
-   This section provides RDF implementations for many aspects of NIEM-conformant scheamas schemas and instance documents.
-
-5.6.1. Resource IRIs for XML Schema components and information items
-
-   The term "qualified name" is defined by [XML Namespaces] Section 2.1, Basic Concepts, which states:
-
-      A qualified name is a name subject to namespace interpretation.
-
-   A Qname is used to represent a qualified name, as described by [XML Schema Datatypes] Section 3.2.18, QName, which states:
-
-      The value space of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName.
-
-   Certain components defined by NIEM schemas and instances have corresponding resource IRIs. Each IRI is taken from a qualified name, as follows:
-
-      *  If namespace name ends with "#": concatenate(namespace name, local part)
-
-      *  Otherwise: concatenate(namespace name, "#", local part)
-
-   Note that this is only meaningful when the namespace name is not empty and is an absolute URI.
-
-   The corresponding RDF resource IRIs for information items and schema components are:
-
-      *  element information item or attribute information item: the resource IRI is built from the qualified name constructed from its [namespace name] and [local name] properties.
-
-      *  schema component: the resource IRI is built from the qualified name constructed from its {target namespace} and {name} properties.
-
-5.6.2. Blank nodes for instances and schemas
-
-   A blank node may correspond to an occurrence of an element information item, which represents the relationship established by the element.
-
-   A blank node may correspond to the content of an element, which represents an instance of a type. This is distinct from the occurrence of the element itself. This includes resolution of structures:ref to structures:id attributes, in which case the content of the referred-to element is considered the content of the element.
-
-   A blank node may correspond to a combination of factors. For example, a blank node is used for each application of an element to a base object via an augmentation, as a single augmentation may be applied to multiple base objects.
-
-   A blank node may also correspond to the above, but for attributes.
-
-5.6.3. RDF Literals
-
-   A simple value may be incorporated into a [conformant instance XML document] as the value of an attribute information item, or as a child of an element information item. This section describes how a simple value is mapped to an RDF literal. Note that there is no mapping for the simple content of an element that is not a [conformant element information item], nor for attributes defined by non-conformant schema documents, so there is no accommodation of mixed content, untyped values, or other cases outside of what conformant schema documents define.
-
-   For each occurrence of a simple value, the following may be relevant:
-
-      *  The value of the literal, which is a normalized value of an attribute or element information item processed in accordance with [XML] Section 2.10, White Space Handling and [XML Schema Structures] Section 3.1.4, White Space Normalization during Validation.
-
-      *  The occurrence of an attribute xml:lang applicable to the value (described by [XML] Section 2.12, Language Identification), which may entail a language tag on the literal (described by [RDF Concepts] Section 3.3, Literal).
-
-      *  The XML Schema-defined base type of the simple value, which may be an attribute's {type definition}, or a simple type base type of an element's {type definition}.
-
-   The literal for a simple value $value is:
-
-      *  If $value has a base type definition that is derived from type xs:string (and not a XML Schema-defined type derived from xs:string), and a non-empty language specification is applied to $value using xml:lang, as described by [XML] Section 2.12, Language Identification, then the literal is a language-tagged string, as described by [RDF Concepts] Section 3.3, Literals:
-
-            "$lexical-form"@$language-tag
-
-            Where:
-
-               *  $lexical-form is a Unicode string for $value.
-
-               *  $language-tag is the in-scope value of attribute xml:lang.
-
-      *  Otherwise, if $value has a base type definition $base-type that is listed as an RDF-compatible XSD type in [RDF Concepts] Section 5.1, The XML Schema Built-in Datatypes, then the literal is:
-
-            "$lexical-form"^^$datatype-IRI
-
-            Where:
-
-               *  $lexical-form is a Unicode string for $value.
-
-               *  $datatype-IRI is the QName of $base-type.
-
-      *  Otherwise, the literal is a simple literal, which is:
-
-            "$lexical-form"
-
-            Where: $lexical-form is a Unicode string for $value.
-
-5.6.4. Resolved element
-
-   This document defines two attributes, structures:id and structures:ref that, together, define a reference mechanism for conformant elements. This enables the use of references to date in place of directly-contained data, which loops in data graphs, as well as for multiple relationships to be defined to a single object. This mechanism uses XML IDs and IDREFs as provided by the XML Schema language. As this document defines the mechanism, a structures:ref attribute may refer to a structures:id; this reference means that the element that has the structures:ref attribute refers to the element that has the structures:id attribute.
-
-   This section defines an operation, resolving an element information item to obtain whatever element is referred to by it. This is put in terms of taking an element and finding the resolved element to which it refers. In a case where there is no reference, the resolved element is the same as the original element.
-
-   [Definition: resolved element information item]
-
-      Within an XML document $document, for any element information item $element there is a resolved element information item, which is:
-
-         *  If all of the following are true:
-
-               *  $document is a [conformant instance XML document].
-
-               *  $element and $referent are [conformant element information items] within $document.
-
-               *  $element owns attribute information item structures:ref with a value $ref.
-
-               *  $referent owns attribute information item structures:id with a value $id.
-
-               *  $ref is equal to $id.
-
-            Then the resolved element information item for $element is $referent.
-
-         *  Otherwise, the resolved element information item for $element is $element.
-
-5.6.5. NIEM instance mappings to RDF
-
-   This section has the following subsections:
-
-   * Section 5.6.5.1, XML document mapping
-   * Section 5.6.5.2, Content of an element
-   * Section 5.6.5.3, Element as a property with unknown context 
-   * Section 5.6.5.4, Element as a simple property of an object or association
-   * Section 5.6.5.5, Attribute as a simple property of an object or association
-   * Section 5.6.5.6, Elements via an augmentation type
-   * Section 5.6.5.7, Attributes via an augmentation type
-   * Section 5.6.5.8, Elements applied to an object via a metadata type
-   * Section 5.6.5.9, Attributes applied to an object via a metadata type
-   * Section 5.6.5.10, Elements applied to a relationship via a metadata type
-   * Section 5.6.5.11, Attributes applied to a relationship via a metadata type
-
-5.6.5.1. XML document mapping
-
-   A [conformant instance XML document] entails a corresponding RDF graph, which is a set of triples, which are entailed by the mapping of the contents of the XML document to RDF.
-
-5.6.5.2. Content of an element
-
-   A [conformant element information item] $element that has property [type definition] that is an [object type] or an [association type], entails the RDF:
-
-      $content rdf:type $type .
-
-      Where:
-
-         *  $content is a blank node corresponding to the content of $element.
-
-         *  $type is resource IRI for the value of the [type definition] property of $element.
-
-   If $element has a non-empty simple value, then it also entails the RDF:
-
-      $content rdf:value $literal .
-
-      Where:
-
-         *  $content is as above.
-
-         *  $literal is the literal value for $element, as described in Section 5.6.3, RDF Literals, above.
-
-5.6.5.3. Element as a property with unknown context 
-
-   A [conformant element information item] $element that
-
-      *  has [type definition] that is the ur-type, an [object type], or an [association type], and that
-
-      *  has a [parent] that is not an element information item, or that is an element information item that is not a [conformant element information item]
-
-   entails the RDF:
-
-      $element-node rdf:type rdf:Statement .
-      $element-node rdf:subject $blank-node .
-      $element-node rdf:predicate $predicate .
-      $element-node rdf:object $element-content-blank-node .
-
-      Where:
-
-         *  $element-node is a blank node corresponding to $element, to represent the relationship being established.
-
-         *  $blank-node is a blank node, to represent the unknown context in which $element occurs.
-
-         *  $predicate is the IRI for element information item $element, to respresent represent the semantics of the relationship.
-
-         *  $element-content-blank-node is a blank node corresponding to the content of the resolved element information item for $element.
-
-5.6.5.4. Element as a simple property of an object or association
-
-   A [conformant element information item] $context that is an instance of an [object type] or [association type], and that has a child [conformant element information item] $element that is an instance of an [object type] or an [association type], entails the RDF:
-
-      $element-node rdf:type rdf:Statement .
-      $element-node rdf:subject $subject .
-      $element-node rdf:predicate $predicate .
-      $element-node rdf:object $object .
-
-      Where:
-
-         *  $element-node is a blank node corresponding to $element.
-
-         *  $subject is a blank node corresponding to the content of $context.
-
-         *  $predicate is the IRI for $element.
-
-         *  $object is a blank node corresponding to the content of the [resolved element information item] for $child.
-
-5.6.5.5. Attribute as a simple property of an object or association
-
-   An attribute information item $attribute where:
-
-      *  $attribute is owned by a [conformant element information item] $context that has property [type definition] that is an [object type] or an [association type], and
-
-      *  $attribute has property [attribute declaration] $attribute-declaration that is defined by a [reference schema document] or an [extension schema document]
-
-   entails the RDF:
-
-      $attribute-node rdf:type rdf:Statement .
-      $attribute-node rdf:subject $subject .
-      $attribute-node rdf:predicate $predicate .
-      $attribute-node rdf:object $literal .
-
-      Where:
-
-         *  $attribute-node is a blank node corresponding to $attribute.
-
-         *  $subject is a blank node corresponding to the content of $context.
-
-         *  $predicate is the resource IRI for $attribute-declaration.
-
-         *  $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
-
-5.6.5.6. Elements via an augmentation type
-
-   An element of a an augmentation type contains a set of elements and attributes that are applied to some base object or association.
-
-   For each element applied to a type via an augmentation type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Element information item $augmentation that is a child of $base that has [type definition] that is an [augmentation type],
-
-      *  Element information item $resolved-augmentation that is the [resolved element information item] for $augmentation,
-
-      *  Element information item $element that is a child of $resolved-augmentation, that has [type definition] that is an [object type] or an [association type], and
-
-      *  Element information item $resolved-element that is the [resolved element information item] for $element
-
-   entails the RDF:
-
-      $element-node rdf:type rdf:Statement .
-      $element-node rdf:subject $subject .
-      $element-node rdf:predicate $predicate .
-      $element-node rdf:object $object .
-
-      Where:
-
-         *  $element-node is a blank node corresponding to $element applied to $base via $augmentation.
-
-         *  $subject is a blank node corresponding to the content of $base.
-
-         *  $predicate is a the resource IRI for [element declaration] of $element.
-
-         *  $object is a blank node corresponding to the content of $resolved-element
-
-5.6.5.7. Attributes via an augmentation type
-
-   An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association.
-
-   For each attribute applied to a type via an augmentation type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Element information item $augmentation that is a child of $base that has [type definition] that is an [augmentation type],
-
-      *  Element information item $resolved-augmentation that is the [resolved element information item] for $augmentation,
-
-      *  Attribute information item $attribute that is owned by $resolved-augmentation, that has an [attribute declaration] that is defined by a [reference schema document] or an [extension schema document]
-
-   entails the RDF:
-
-      $attribute-node rdf:type rdf:Statement .
-      $attribute-node rdf:subject $subject .
-      $attribute-node rdf:predicate $predicate .
-      $attribute-node rdf:object $literal .
-
-      Where:
-
-         *  $attribute-node is a blank node corresponding to $attribute applied to $base via $augmentation.
-
-         *  $subject is a blank node corresponding to the content of $base.
-
-         *  $predicate is a the resource IRI for [attribute declaration] of $attribute.
-
-         *  $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
-
-5.6.5.8. Elements applied to an object via a metadata type
-
-   An element of a metadata type contains a set of elements and attributes that are applied to some base object or association.
-
-   For each element applied to a type via a metadata type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
-
-      *  Each element information item $metdata $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metdata $metadata-idref.
-
-      *  Element information item $element that is a child of $metdata $metadata, that has [type definition] that is an [object type] or an [association type], and
-
-      *  Element information item $resolved-element that is the [resolved element information item] for $element
-
-   entails the RDF:
-
-      $element-node rdf:type rdf:Statement .
-      $element-node rdf:subject $subject .
-      $element-node rdf:predicate $predicate .
-      $element-node rdf:object $object .
-
-      Where:
-
-         *  $element-node is a blank node corresponding to $element applied to $base via $metadata.
-
-         *  $subject is a blank node corresponding to the content of $base.
-
-         *  $predicate is a the resource IRI for [element declaration] of $element.
-
-         *  $object is a blank node corresponding to the content of $resolved-element
-
-5.6.5.9. Attributes applied to an object via a metadata type
-
-   An element of a metadata type contains a set of elements and attributes that are applied to some base object or association.
-
-   For each element applied to a type via a metadata type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
-
-      *  Each element information item $metdata $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metdata $metadata-idref.
-
-      *  Attribute information item $attribute that is owned by $metdata $metadata, that has [attribute declaration] that is defined by a [reference schema document] or an [extension schema document]
-
-   entails the RDF:
-
-      $attribute-node rdf:type rdf:Statement .
-      $attribute-node rdf:subject $subject .
-      $attribute-node rdf:predicate $predicate .
-      $attribute-node rdf:object $literal .
-
-      Where:
-
-         *  $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata.
-
-         *  $subject is a blank node corresponding to the content of $base.
-
-         *  $predicate is a the resource IRI for [element declaration] of $element.
-
-         *  $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
-
-5.6.5.10. Elements applied to a relationship via a metadata type
-
-   An element of a metadata type contains a set of elements and attributes that are applied to a relationship.
-
-   For each element applied to a type via a metadata type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Each value $metadata-idref that is a value in attribute structures:relationshipMetadata owned by $base.
-
-      *  Each element information item $metdata $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metdata $metadata-idref.
-
-      *  Element information item $element that is a child of $metdata $metadata, that has [type definition] that is an [object type] or an [association type], and
-
-      *  Element information item $resolved-element that is the [resolved element information item] for $element
-
-   entails the RDF:
-
-      $element-node rdf:type rdf:Statement .
-      $element-node rdf:subject $subject .
-      $element-node rdf:predicate $predicate .
-      $element-node rdf:object $object .
-
-      Where:
-
-         *  $element-node is a blank node corresponding to $element applied to $base via $metadata.
-
-         *  $subject is a blank node corresponding to $base.
-
-         *  $predicate is a the resource IRI for [element declaration] of $element.
-
-         *  $object is a blank node corresponding to the content of $resolved-element
-
-5.6.5.11. Attributes applied to a relationship via a metadata type
-
-   An element of a metadata type contains a set of elements and attributes that are applied to a relationship.
-
-   For each element applied to a type via a metadata type:
-
-      *  Element information item $base that is an an instance of an [object type] or [association type],
-
-      *  Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
-
-      *  Each element information item $metdata $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metdata $metadata-idref.
-
-      *  Attribute information item $attribute that is owned by $metdata $metadata, that has [attribute declaration] that is defined by a [reference schema document] or an [extension schema document]
-
-   entails the RDF:
-
-      $attribute-node rdf:type rdf:Statement .
-      $attribute-node rdf:subject $subject .
-      $attribute-node rdf:predicate $predicate .
-      $attribute-node rdf:object $literal .
-
-      Where:
-
-         *  $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata.
-
-         *  $subject is a blank node corresponding to $base.
-
-         *  $predicate is a the resource IRI for [element declaration] of $element.
-
-         *  $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
-
-5.6.6. NIEM complex type definitions to RDF
-
-   The following RDF mappings apply to the content of a [reference schema document] or [extension schema document].
-
-   An [object type] or [association type] $type entails the following RDF:
-
-      $resource rdf:type rdf:Class .
-
-      Where $resource is the resource IRI for $type.
-
-   An [object type] or [association type] $type that has property {base type definition} $base entails the RDF:
-
-      $type-resource rdfs:subClassOf $base-resource
-
-      Where:
-
-         *  $type-resource is the resource IRI for $type.
-
-         *  $base-resource is the resource IRI for $base.
-
-5.6.7. NIEM element declaration mappings to RDF
-
-   The following RDF mappings apply to the content of a [reference schema document] or [extension schema document].
-
-   A top-level element declaration schema component $element-declaration that has property {type definition} that is
-
-      *  the ur-type, or
-
-      *  is, or is derived from, structures:ObjectType, or
-
-      *  is, or is derived from, structures:AssociationType
-
-   entails the RDF:
-
-      $element-resource rdf:type rdf:Property .
-
-      Where $element-resource is the resource IRI for $element-declaration.
-
-   If $element-declaration has property {substitution group affiliation} with a value of element declaration $base, then it entails the RDF:
-
-      $element-resource rdfs:subPropertyOf $base-resource
-
-      Where:
-
-         *  $element-resource is the resource IRI for $element-declaration.
-
-         *  $base-resource is the resource IRI for $base.
-
-   If $element-declaration has property {type definition} with a value $type that is an [object type] or [association type], then it entails the RDF:
-
-      $element-resource rdfs:range $type-resource
-
-      Where:
-
-         *  $element-resource is the resource IRI for $element-declaration.
-
-         *  $type-resource is the resource IRI for $type.
-
-5.6.8. NIEM attribute declarations to RDF
-
-   The following RDF mappings apply to the content of a [reference schema document] or [extension schema document].
-
-   A top-level attribute declaration schema component $attribute-declaration that has property {type definition} that is a simple type definition defined within a [reference schema document] or an [extension schema document], then it entails the RDF:
-
-      $attribute-resource rdf:type rdf:Property .
-
-      Where $attribute-resource is the resource IRI for $attribute-declaration.
-
-6. 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 organized as follows:
-
-   * Section 6.1, Specification guidelines
-   * Section 6.2, XML Schema design guidelines
-   * Section 6.3, Modeling design guidelines
-   * Section 6.4, Implementation guidelines
-   * Section 6.5, Modeling guidelines
-
-6.1. Specification guidelines
-
-   The principles in this section address what material should be included in this NDR and how it should be represented.
-
-6.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." 
-
-6.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 and their instance documents. It should avoid specifying complex data models or data dictionaries.
-
-   [Principle 2]
-
-      This specification SHOULD focus on specifying characterstics characteristics of schema documents, their instance documents, and their interpretation.
-
-6.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 that are specific, precise, and concise.
-
-6.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.
-
-6.2.1. Purpose of XML Schemas
-
-   [Principle 4]
-
-      The specification SHOULD focus on rules for XML Schemas in order to support:
-
-         1. the expression of interface specifications for exchange of information between data producers and consumers,
-
-         2. validation of XML documents against interface specifications,
-
-         3. comprehension and understanding of XML documents, including the use of post-schema-validation infoset as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, and
-
-         4. development of implementations supported by tools that use XML Schemas.
-
-6.2.2. 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. An example 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 primarily validation: testing that data instances match desired constraints and guidelines. It should not be used to change the content of data instances.
-
-   [Principle 5]
-
-      The content of a NIEM-conformant data instance SHOULD NOT be modified by processing against XML Schema documents.
-
-6.2.3. Use XML validating parsers for content validation
-
-   NIEM is designed for XML Schema validation. One 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 6]
-
-      NIEM-conformant schemas and NIEM-conformant XML documents SHOULD use features supported by XML Schema validating parsers for validation of XML content.
-
-6.2.4. Validate for conformance to schema
-
-   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 validation against schemas 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 7]
-
-      Systems that use NIEM-conformant data SHOULD mark as invalid data that does not conform to the rules defined by applicable XML Schema documents.
-
-6.2.5. Allow multiple schemas for XML constraints
-
-   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. Although NIEM is prinicipally principally expressed as a set of reference schemas for a NIEM release, additional validation may be conducted through other mechanisms, which may include XML Schemas that express additional constraints, and business rules and structure-specifying languages other than the [XML Schema definition language].
-
-   [Principle 8]
-
-      Constraints on XML instances MAY be validated by multiple validation passes, using multiple schemas and specifications for different aspects of each namespace.
-
-6.2.6. 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 9]
-
-      Each NIEM-conformant namespace SHOULD be defined by exactly one reference schema.
-
-6.2.7. 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 10]
-
-      NIEM-conformant schemas SHOULD NOT specify data that uses mixed content.
-
-6.2.8. Specify types for all constructs
-
-   Every schema component defined by a NIEM-conformant schema that can have a name has a name. 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 11]
-
-      NIEM-conformant schemas SHOULD NOT use or define local or anonymous components, as they adversely affect reuse.
-
-6.2.9. Avoid wildcards in 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 xs:any, which allows insertion of arbitrary elements) allows unstandardized data to be passed via otherwise standardized exchanges.
-
-   Avoidance of wildcards in the standard schemas encourages the separation of standardized and unstandardized 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 12]
-
-      NIEM-conformant components SHOULD NOT incorporate wildcards unless absolutely necessary, as they hinder standardization by encouraging use of unstandardized data rather than standardized data.
-
-6.2.10. Schema locations provided in schema documents are hints
-
-   [XML Schema Structures] provides several mechanisms for acquiring components of an [XML Schema] for the purpose of assessing validity of an instance. [XML Schema Structures] Section 4.3.2, How schema definitions are located on the Web includes:
-
-      *  Use schema definitions already known to the processor.
-
-      *  Use a location URI or namespace name to identify a schema document from a network location or local schema repository.
-
-      *  Attempt to resolve a location URI or namespace name to locate a schema document.
-
-   In addition, there are several ways for a processor to determine schema locations:
-
-      *  Use schema locations identified by user direction.
-
-      *  Use locations provided via xsi:schemaLocation or xsi:noNamespaceSchemaLocation attributes in an [XML document] under assessment.
-
-      *  Use schema locations provided by xs:import elements.
-
-   [XML Schema Structures] characterizes several of these methods as hints of where to acquire a schema document for assessment. [XML Schema Structures] Section 2.6.3, xsi:schemaLocation, xsi:noNamespaceSchemaLocation states:
-
-      The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which may be used for assessment.
-
-   [XML Schema Structures] Section 4.2.3, References to schema components across namespaces states:
-
-      The actual value of the schemaLocation, if present, gives a hint as to where a serialization of a schema document with declarations and definitions for that namespace (or none) may be found.
-
-   The specification explicitly maintains that schema location provided in schemas or instances may be overridden by applications or by user direction.
-
-   [Principle 13]
-
-      Schema locations specified within NIEM-conformant reference schemas SHOULD be interpreted as hints and as default values by processing applications.
-
-   In accordance with Section 1.1, Scope, above, this document does not provide normative guidance for location of [schema documents] or for schema assembly.
-
-6.2.11. 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 14]
-
-      NIEM standards and schemas SHOULD leverage and enable use of other open standards.
-
-6.3. Modeling design guidelines
-
-   The principles in this section address the design philosophy used in designing the NIEM conceptual model.
-
-6.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 a NIEM-conformant schema, 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 15]
-
-      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 6-1: Example of the use of a namespace
-
-      <xs: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 16]
-
-      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.
-
-6.3.2. Design NIEM for extensibility
-
-   NIEM is designed to be extended. Numerous methods are considered acceptable in creating extended and specialized components.
-
-   [Principle 17]
-
-      NIEM-conformant schemas and standards SHOULD be designed to encourage and ease extension and augmentation by users and developers outside the NIEM governance process.
-
-6.4. Implementation guidelines
-
-   The principles in this section address issues pertaining to the implementation of applications that use NIEM.
-
-6.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. Structured XML content does not belong in places targeting humans. Human-targeted information should be of a form suitable for presentation.
-
-   [Principle 18]
-
-      XML data SHOULD be designed for automatic processing. XML data SHOULD NOT be designed for literal presentation to people. NIEM specifications and schemas SHOULD NOT use literal presentation of XML data to people as a design criterion.
-
-6.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 19]
-
-      NIEM SHOULD NOT depend on specific software packages, software frameworks, or software systems for interpretation of XML instances.
-
-   [Principle 20]
-
-      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.
-
-6.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.
-
-6.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 schema component's [data 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 21]
-
-      The [data definition] of a component SHOULD be drafted before the component's name is composed.
-
-6.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 22]
-
-      Components in NIEM SHOULD be given names that are consistent with names of other NIEM components. Such names SHOULD be based on simple rules.
-
-6.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 23]
-
-      Component definitions in NIEM-conformant schemas SHOULD reflect real-world concepts.
-
-   It is important for the modeler to understand what she is modeling; a person, an observation of a person, and a drivers license for a person are all at different levels, although they each may contain similar information.
-
-6.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 24]
-
-      Component definitions in NIEM-conformant schemas SHOULD have semantic consistency.
-
-6.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 25]
-
-      Complex type definitions in NIEM-conformant schemas SHOULD use type inheritance only for specialization.
-
-   Note that the use of [augmentations] allows developers to avoid type specialization in many cases; see Section 10.4, Augmentations, below.
-
-6.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.
-
-   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 26]
-
-      Multiple components with identical or undifferentiated semantics SHOULD NOT be defined. Component definitions SHOULD have clear, explicit distinctions.
-
-6.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 27]
-
-      NIEM-conformant schemas SHOULD have the simplest possible structure, content, and architecture consistent with real business requirements.
-
-6.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 28]
-
-      Components defined by NIEM-conformant schemas SHOULD be defined appropriate for their scope.
-
-6.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 29]
-
-      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.
-
-7. Conformance to standards
-
-7.1. Conformance to XML
-
-Rule 7-1. Document is an XML document
-
-   [Rule 7-1] (REF, EXT, INS)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:report test="true()">The document MUST be an XML document.</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   The term [XML document] is defined by this document.
-
-7.2. Conformance to XML Namespaces
-
-Rule 7-2. Document uses XML namespaces properly
-
-   [Rule 7-2] (REF, EXT, INS)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:report test="true()">The document MUST be namespace-well-formed and namespace-valid.</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   The terms namespace-well-formed and namespace-valid are normatively defined by [XML Namespaces] and [XML Namespaces Errata].
-
-7.3. Conformance to XML Schema
-
-Rule 7-3. Document is a schema document
-
-   [Rule 7-3] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:report test="true()">The document MUST be a schema document.</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [schema document].
-
-Rule 7-4. Document element is xs:schema
-
-   [Rule 7-4] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[. is nf:get-document-element(.)]">
-          <sch:assert test="self::xs:schema"
-            >The [document element] of the XML document MUST have the name xs:schema.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [XML document].
-
-7.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-4] as a baseline for its data component definitions.
-
-   To advance the goal of creating semantically rich NIEM-conformant schemas, it is necessary that data definitions be descriptive, meaningful, and precise. [ISO 11179-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-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-4], NIEM applies additional rules to data definitions. These rules are detailed in Section 11.6.1, Human-readable documentation, below.
-
-   These definitions leverage the term "definition" as defined by [ISO 11179-4]:
-
-      representation of a concept by a descriptive statement which serves to differentiate it from related concepts
-
-   [Definition: data definition]
-
-      The data definition of a [schema component] is the content of the first occurrence of the element xs:documentation that is an immediate child of an occurrence of an element xs:annotation that is an immediate child of the element that defines the component.
-
-   [Definition: documented component]
-
-      In a NIEM-conformant schema, a documented component is [schema component] that has an associated [data definition]. Each documented component has a textual definition, so that the component may be well-understood.
-
-   An example of a data definition is provided in Figure 7-1, Example of data definition of element nc:Activity, below.
-
-   Figure 7-1: Example of data definition of element nc:Activity
-
-      <xs:element name="Activity" type="nc:ActivityType" nillable="true">
-        <xs:annotation>
-          <xs:documentation>A single or set of related actions, events, or process steps.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   See Rule 11-29, Data definition follows 11179-4 requirements and Rule 11-30, Data definition follows 11179-4 recommendations for application of [ISO 11179-4] to constrain NIEM [data definitions].
-
-7.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-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 7-5. Component name follows ISO 11179 Part 5 Annex A
-
-   [Rule 7-5] (REF, EXT)
-
-      A NIEM component name MUST be formed by applying the informative guidelines and examples detailed in Annex A of [ISO 11179-5], with exceptions as specified in this document.
-
-   The guidelines and examples of [ISO 11179-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-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 the relevant sections. In spite of these exceptions, most NIEM component names can be disassembled into their [ISO 11179-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 10.8, Naming rules, below, details the specific rules for each kind of term and how to construct NIEM component names from it.
-
-7.6. IC-ISM and IC-NTK
-
-   The Office of the Director of National Intelligence manages and maintains a set of specifications that support the requirements of the Intelligence Community (IC) to share and manage data across the IC enterprise. These specifications are available at http://purl.org/ic/standards/public. The design of NIEM supports the use of NIEM-conformant data across the IC.
-
-   The following features have been provided to support the use of NIEM-conformant data definitions across the IC, by supporting the use of IC-ISM and IC-NTK wthin within NIEM-defined data:
-
-      *  NIEM base types defined by the [structures namespace] incorporate xs:anyAttribute declarations, which allow the use of attributes from the ISM and NTK namespaces. See Appendix B, Structures namespace, below, for the reference schema.
-
-      *  Rule 11-24, Schema uses only known attribute groups allows conformant data types to reference attribute groups defined in the ISM and NTK namespaces.
-
-      *  Complex types may be constructed that use external attributes, including attributes from the ISM and NTK namespaces. Each such attribute use must be a [documented component], as specified by Rule 10-14, External attribute use has data definition.
-
-   These features ensure that payloads that correctly use IC-ISM AND IC-NTK are supported by NIEM-conformant schema definitions.
-
-8. Strategy for a NIEM profile of XML Schema
-
-8.1. Wildcards
-
-   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 12], above, 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.
-
-   The following restrictions help to ban wildcards and arbitrary data:
-
-      *  Use of the type xs:anyType is prohibited.
-
-      *  Use of the type xs:anySimpleType is prohibited in most cases.
-
-      *  Use of the element xs:any is prohibited in reference schemas.
-
-      *  Use of the element xs:anyAttribute is prohibited in reference schemas.
-
-8.2. Components are globally reusable
-
-   Each component defined by a NIEM-conformant schema may be reused from outside the schema document. Every type definition, element declaration, or attribute declaration schema component that is defined by a NIEM-conformant schema is given an explicit name. These schema components are not defined as local or anonymous. These components are defined at the top level, as children of element xs:schema.
-
-   This is supported by the rules:
-
-      *  Rule 9-10, Simple type definition is top-level
-
-      *  Rule 9-24, Complex type definitions is top-level
-
-      *  Rule 9-35, Element declaration is top-level
-
-      *  Rule 9-47, Attribute declaration is top-level
-
-   Additional restrictions ensure that NIEM components are also defined such that new components may be derived from them and substituted for them. Reference schemas are defined to maximize reuse, while extension schemas are defined to enable a developer to customize schema definitions to match her exchange needs. In reference schemas, the following restrictions help enforce reusability through extension and substitution:
-
-      *  A [reference schema document] or [extension schema document] may not use blockDefault (per Rule 9-85, No disallowed substitutions) or finalDefault (per Rule 9-86, No disallowed derivations).
-
-      *  Element declarations and type definitions in a [reference schema document] may not use block or final, per the rules:
-
-            *  Rule 9-33, No complex type disallowed substitutions
-
-            *  Rule 9-34, No complex type disallowed derivation
-
-            *  Rule 9-42, No element disallowed substitutions 
-
-            *  Rule 9-43, No element disallowed derivation
-
-8.3. Avoid recursive model groups
-
-   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. The rules in this document restrict the use of nested model groups, in order 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.
-
-8.4. Ensure schema processing does not alter processed data
-
-   XML Schema provides the capability for element and attribute declarations to provide default values when XML instances using those components do not provide values. This is done through the use of the attributes default and fixed, both of which provide default values to attributes and element content.
-
-   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 described by Section 6.2.2, Disallow content modification with XML processors, above.
-
-   The transparency of validation to data content is ensured through a prohibition on the use of default and fixed attributes in NIEM-conformant schema documents.
-
-8.5. Use namespaces rigorously
-
-   Every component defined by or used in a NIEM schema has a target namespace.
-
-   XML Schema requires that namespaces used in external references be imported using the xs:import element. The xs:import element appears as an immediate child of the xs:schema element. A schema must import any namespace which is not the local namespace, and which 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. 
-
-   Certain tools have been seen introducing transitive behavior on imports, which is not portable across XML Schema validating parsers. If namespace 1 imports namespace 2 which imports namespace 3, a reference from namespace 1 to namespace 3 is not legal; namespace 1 must explicitly import namespace 3. A tool that imports transitively may allow schema 1 to reference 3 without a direct import of namespace 3. This is prohibited by rules which require imports of namespaces of referenced components.
-
-8.6. Documentation is for people; appinfo is for machines
-
-   The XML Schema specification defines two types of annotations: user information and application information. It defines that user information is for human consumption, while application information is for automatic processing. 
-
-   [XML Schema Structures] Section 3.13, Annotations states:
-
-      Annotations provide for human- and machine-targeted annotations of schema components.
-
-   [XML Schema Structures] Section 3.13.1, The Annotation Schema Component states:
-
-      {user information} is intended for human consumption, {application information} for automatic processing.
-
-   The two types: human-targeted and machine-targeted, are kept separate by the use of two separate container elements defined by XML Schema: xs:documentation and xs:appinfo.
-
-   xs:documentation elements express "user information". This information is targeted for reading by humans. The XML Schema specification does not say what form human-targeted information should take. Since it is intended for human consumption, xs:documentation elements in conformant schemas do not contain structured XML data. As such, any XML content appearing within a documentation element should be human-targeted examples, and should be escaped (e.g., using &lt; and &gt;, or using CDATA blocks). Documentation within conformant schemas should be plain text; whitespace formatting may not be preserved across processing.
-
-   xs:appinfo elements express "application information". This is generally information supporting automatic processing of schemas. Application information is addressed in Section 10.9, Machine-readable annotations, below.
-
-   XML comments are not XML Schema constructs and are not specifically associated with any schema-based component; they are not considered semantically meaningful by NIEM and may not be retained through processing of NIEM schemas.
-
-9. Rules for a NIEM profile of XML Schema
-
-   NIEM-conformant schemas use a profile of XML Schema. The W3C XML Schema Language provides many features that allow a developer to represent a data model many different ways. 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.
-
-   This section establishes a profile of XML Schema for 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 schema documents (i.e., non-NIEM-conformant schema documents) do not need to obey the rules set forth in this section. So long as schema components from external schema documents are adapted for use with NIEM according to the modeling rules in Section 10.2.3, External adapter types and external components, below, they may be used as they appear in the external standard, even if the schema components themselves violate the rules for NIEM-conformant schemas.
-
-   The following sections are broken down in the order provided by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, followed by a section on a schema document as a whole and a section on schema namespaces and assembly:
-
-   * Section 9.1, Type definition components
-   * Section 9.2, Declaration components
-   * Section 9.3, Model group components
-   * Section 9.4, Identity-constraint definition components
-   * Section 9.5, Group definition components
-   * Section 9.6, Annotation components
-   * Section 9.7, Schema as a whole
-   * Section 9.8, Schema assembly
-
-9.1. Type definition components
-
-9.1.1. Type definition hierarchy
-
-9.1.1.1. Types prohibited as base types
-
-Rule 9-1. No base type in the XML namespace
-
-   Although the XML namespace is to be imported as if it is conformant, types from that namespace may not be the [base type definition] of any type.
-
-   [Rule 9-1] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="namespace-uri-from-QName(resolve-QName(@base, .)) != xs:anyURI('http://www.w3.org/XML/1998/namespace')"
-                      >A schema component must not have a base type definition with a {target namespace} that is the XML namespace.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The term [base type definition] has a normative definition.
-
-Rule 9-2. No base type of xs:ID
-
-   [Rule 9-2] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:ID')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:ID.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-3. No base type of xs:IDREF
-
-   [Rule 9-3] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:IDREF')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:IDREF.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-4. No base type of xs:IDREFS
-
-   [Rule 9-4] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:IDREFS')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:IDREFS.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-5. No base type of xs:anyType
-
-   [Rule 9-5] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:anyType')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:anyType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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 xs:anyType.
-
-   NIEM-conformant schemas must not use xs: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.
-
-Rule 9-6. No base type of xs:anySimpleType
-
-   [Rule 9-6] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:anySimpleType')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:anySimpleType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   XML Schema provides a restriction of the "ur-type" that contains only simple content. This provides a wildcard for arbitrary text. It is realized in XML Schema as xs:anySimpleType.
-
-   NIEM-conformant schemas must not use xs: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.
-
-Rule 9-7. No base type of xs:NOTATION
-
-   [Rule 9-7] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:NOTATION')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:NOTATION.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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.
-
-Rule 9-8. No base type of xs:ENTITY
-
-   [Rule 9-8] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:ENTITY')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:ENTITY.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-9. No base type of xs:ENTITIES
-
-   [Rule 9-9] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:ENTITIES')"
-            >A schema component MUST NOT have an attribute {}base with a value of xs:ENTITIES.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.1.2. Simple type definition
-
-Rule 9-10. Simple type definition is top-level
-
-   [Rule 9-10] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType">
-          <sch:assert test="exists(parent::xs:schema)"
-            >A simple type definition MUST be top-level.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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 globally reusable.
-
-Rule 9-11. No simple type disallowed derivation
-
-   [Rule 9-11] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType">
-          <sch:assert test="empty(@final)"
-            >An element xs:simpleType MUST NOT have an attribute {}final.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-12. Simple type has data definition
-
-   [Rule 9-12] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >A simple type MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [data definition].
-
-9.1.2.1. Simple types prohibited as list item types
-
-   There is no explicit prohibition on the use of xs:NOTATION as list item type, because it is prohibited by [XML Schema Datatypes].
-
-   There is no prohibition on xs:anyType as a list item type, because xs:anyType is not a simple type.
-
-Rule 9-13. No list item type of xs:ID
-
-   [Rule 9-13] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@itemType)]">
-          <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:ID')"
-            >A schema component MUST NOT have an attribute {}itemType with a value of xs:ID.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-14. No list item type of xs:IDREF
-
-   [Rule 9-14] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@itemType)]">
-          <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:IDREF')"
-            >A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-15. No list item type of xs:anySimpleType
-
-   [Rule 9-15] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@itemType)]">
-          <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:anySimpleType')"
-            >A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-16. No list item type of xs:ENTITY
-
-   [Rule 9-16] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@itemType)]">
-          <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:ENTITY')"
-            >A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.1.2.2. Simple types prohibited as union member types
-
-   There is no explicit prohibition on the use of xs:NOTATION as a union member type, because it is prohibited by [XML Schema Datatypes].
-
-   There is no prohibition on xs:anyType as a union member type, because xs:anyType is not a simple type.
-
-Rule 9-17. No union member types of xs:ID
-
-   [Rule 9-17] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:ID')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-18. No union member types of xs:IDREF
-
-   [Rule 9-18] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:IDREF')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-19. No union member types of xs:IDREFS
-
-   [Rule 9-19] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:IDREFS')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-20. No union member types of xs:anySimpleType
-
-   [Rule 9-20] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:anySimpleType')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-21. No union member types of xs:ENTITY
-
-   [Rule 9-21] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:ENTITY')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-22. No union member types of xs:ENTITIES
-
-   [Rule 9-22] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@memberTypes)]">
-          <sch:assert test="every $type-qname
-                            in tokenize(normalize-space(@memberTypes), ' ')
-                            satisfies resolve-QName($type-qname, .) != xs:QName('xs:ENTITIES')"
-            >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-23. Enumeration has data definition
-
-   [Rule 9-23] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:enumeration">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >An enumeration facet MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [data definition].
-
-9.1.3. Complex type definition
-
-Rule 9-24. Complex type definitions is top-level
-
-   [Rule 9-24] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:assert test="exists(parent::xs:schema)"
-            >A complex type definition MUST be top-level.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that this implies that every xs:complexType element has a name attribute.
-
-Rule 9-25. Complex type has data definition
-
-   [Rule 9-25] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >A complex type MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [data definition].
-
-9.1.3.1. No mixed content
-
-Rule 9-26. No mixed content on complex type
-
-   [Rule 9-26] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[exists(@mixed)]">
-          <sch:assert test="xs:boolean(@mixed) = false()"
-            >A complex type definition MUST NOT have mixed content.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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 schema documents 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 10], above.
-
-Rule 9-27. No mixed content on complex content
-
-   [Rule 9-27] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexContent[exists(@mixed)]">
-          <sch:assert test="xs:boolean(@mixed) = false()"
-            >A complex type definition with complex content MUST NOT have mixed content.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   See Rule 9-26, No mixed content on complex type for the rationale for this rule.
-
-Rule 9-28. Complex type content is explicitly simple or complex
-
-   [Rule 9-28] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:assert test="exists(xs:simpleContent) or exists(xs:complexContent)"
-            >An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   XML Schema provides shorthand to defining complex content of a complex type, which is to define the complex type with immediate children that specify elements, or other groups, and attributes. In the desire to normalize schema representation of types and to be explicit, NIEM forbids the use of that shorthand.
-
-9.1.3.2. Complex content
-
-Rule 9-29. Complex content uses extension
-
-   [Rule 9-29] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexContent">
-          <sch:assert test="exists(xs:extension)"
-            >An element xs:complexContent MUST have a child xs:extension.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   NIEM does not support the use of complex type restriction in reference schemas. The use of restriction in a reference schema would reduce the ability for that schema to be reused. Restriction may be used in extension schemas.
-
-9.1.3.2.1. Base type of complex type with complex content has complex content
-
-   These two rules addresses a peculiarity of the [XML Schema definition language], which allows a complex type to be constructed using xs:complexContent, and yet is derived from a complex type that uses xs:simpleContent. These rules ensures that each type has the content style indicated by the schema. An example is included in the following figure. Note that type niem-xs:integer is a complex type with simple content.
-
-   Figure 9-1: Example of complex type with simple content that claims to have complex content
-
-      <xs:complexType name="TreeCountType">
-        <xs:annotation>
-          <xs:documentation>A data type for a number of trees</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="niem-xs:integer"/>
-        </xs:complexContent>
-      </xs:complexType>
-
-   The first rule handles cases that can be determined within a single schema document, while the SET version handles cases that require cross-schema resolution.
-
-Rule 9-30. Base type of complex type with complex content must have complex content
-
-   [Rule 9-30] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType/xs:complexContent/xs:*[
-                             (self::xs:extension or self::xs:restriction)
-                             and (some $base-qname in resolve-QName(@base, .) satisfies
-                                    namespace-uri-from-QName($base-qname) = nf:get-target-namespace(.))]">
-          <sch:assert test="some $base-type in nf:resolve-type(., resolve-QName(@base, .)) satisfies
-                              empty($base-type/self::xs:complexType/xs:simpleContent)"
-            >The base type of complex type that has complex content MUST be a complex type with complex content.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-31. Base type of complex type with complex content must have complex content
-
-   [Rule 9-31] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[
-              nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))
-              or nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument'))
-            ]/xs:complexContent">
-          <sch:assert test="some $derivation in xs:*[self::xs:extension or self::xs:restriction],
-                                 $base-qname in resolve-QName($derivation/@base, $derivation),
-                                 $base-type in nf:resolve-type($derivation, $base-qname) satisfies
-                               empty($base-type/self::xs:complexType/xs:simpleContent)"
-            >The base type of complex type that has complex content MUST have complex content.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.1.3.3. Simple content
-
-Rule 9-32. Simple content uses extension
-
-   [Rule 9-32] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleContent">
-          <sch:assert test="exists(xs:extension)"
-            >A complex type definition with simple content schema component MUST have a derivation method of extension.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This rule ensures that the definition of a complex type with simple content will use XML Schema extension. This allows for the above cases while disallowing more complicated syntactic options available in XML Schema. The above rule allows for use of xs:restriction within xs:simpleContent in extension schemas.
-
-Rule 9-33. No complex type disallowed substitutions
-
-   [Rule 9-33] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:assert test="empty(@block)"
-            >An element xs:complexType MUST NOT have an attribute {}block.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-34. No complex type disallowed derivation
-
-   [Rule 9-34] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:assert test="empty(@final)"
-            >An element xs:complexType MUST NOT have an attribute {}final.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.2. Declaration components
-
-9.2.1. Element declaration
-
-   Every element declaration in a NIEM-conformant schema document is a top-level element; rules prohibit the declaration of local elements.
-
-   Within a NIEM-conformant schema document, an element may be declared as abstract. Elements may be defined without a type, but any element declaration that has no type must be declared abstract, as specified by Rule 9-37, Untyped element is abstract.
-
-   Within an element declaration, the attributes fixed, nillable, and substitutionGroup may be used as per the XML Schema specification. The attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local element declarations, as specified by Rule 9-35, Element declaration is top-level.
-
-Rule 9-35. Element declaration is top-level
-
-   [Rule 9-35] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="exists(parent::xs:schema)"
-            >An element declaration MUST be top-level.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   All schema components defined by NIEM-conformant schemas must be named, accessible from outside the defining schema, and reusable across schemas. Local element declarations 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.
-
-Rule 9-36. Element declaration has data definition
-
-   [Rule 9-36] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >An element declaration MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [data definition].
-
-Rule 9-37. Untyped element is abstract
-
-   [Rule 9-37] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema/xs:element[empty(@type)]">
-          <sch:assert test="exists(@abstract)
-                            and xs:boolean(@abstract) = true()"
-            >A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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.
-
-Rule 9-38. Element of type xs:anySimpleType is abstract
-
-   The type xs:anySimpleType does not have any concrete semantics; The use of xs:anySimpleType is limited to the case where an abstract element is of type xs:anySimpleType, to act as a base for concrete implementations of the element.
-
-   [Rule 9-38] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@type)
-                                      and resolve-QName(@type, .) = xs:QName('xs:anySimpleType')]">
-          <sch:assert test="exists(@abstract)
-                            and xs:boolean(@abstract) = true()"
-                      >An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-39. Element type not in the XML Schema namespace
-
-   [Rule 9-39] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@type)]">
-          <sch:assert test="for $type-qname in resolve-QName(@type, .) return
-                              $type-qname = xs:QName('xs:anySimpleType')
-                              or namespace-uri-from-QName($type-qname) != xs:anyURI('http://www.w3.org/2001/XMLSchema')"
-            >An element type that is not xs:anySimpleType MUST NOT have a namespace name <namespace-uri-for-prefix>xs</namespace-uri-for-prefix>.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The prohibition of element types having the XML Schema namespace subsumes a prohibition of the type xs:anyType.
-
-Rule 9-40. Element type not in the XML namespace
-
-   The XML namespace may be imported into an a conformant schema document as if it were conformant. This specification does not enable a reference to any types that may be defined by any implementation of a schema for that namespace.
-
-   [Rule 9-40] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@type)]">
-          <sch:assert test="namespace-uri-from-QName(resolve-QName(@type, .)) != 'http://www.w3.org/XML/1998/namespace'"
-            >An element type MUST NOT have a namespace name that is in the XML namespace.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-41. Element type is not simple type
-
-   [Rule 9-41] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@type]">
-          <sch:assert test="every $type-qname in resolve-QName(@type, .),
-                                  $type-ns in namespace-uri-from-QName($type-qname),
-                                  $type-local-name in local-name-from-QName($type-qname) satisfies (
-                              $type-qname = xs:QName('xs:anySimpleType')
-                              or (($type-ns = nf:get-target-namespace(.)
-                                   or exists(nf:get-document-element(.)/xs:import[
-                                               xs:anyURI(@namespace) = $type-ns
-                                               and empty(@appinfo:externalImportIndicator)]))
-                                  and not(ends-with($type-local-name, 'SimpleType'))))"
-            >An element type that is not xs:anySimpleType MUST NOT be a simple type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-42. No element disallowed substitutions 
-
-   [Rule 9-42] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:element">
-          <sch:assert test="empty(@block)"
-            >An element xs:element MUST NOT have an attribute {}block.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-43. No element disallowed derivation
-
-   [Rule 9-43] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:element">
-          <sch:assert test="empty(@final)"
-            >An element xs:element MUST NOT have an attribute {}final.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.2.1.1. No element value constraints
-
-Rule 9-44. No element default value
-
-   [Rule 9-44] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element">
-          <sch:assert test="empty(@default)"
-            >An element xs:element MUST NOT have an attribute {}default.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-45. No element fixed value
-
-   [Rule 9-45] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element">
-          <sch:assert test="empty(@fixed)"
-            >An element xs:element MUST NOT have an attribute {}fixed.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-46. Element declaration is nillable
-
-   All elements declared by reference schemas allow a nil value. This enables the ID/IDREF mechanism linking structures:ref and structures:id, as described by Section 12.2, Reference elements, below.
-
-   A developer may constrain the use of nil in an instance by setting nillable to false in subset schemas, or by use of non-XML Schema mechanisms, such as Schematron.
-
-   [Rule 9-46] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name and (empty(@abstract)
-                                                 or xs:boolean(@abstract) = false())]">
-          <sch:assert test="exists(@nillable)
-                            and xs:boolean(@nillable) = true()"
-            >An element declaration MUST have the {nillable} property with a value of true.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [element declaration].
-
-9.2.2. Element substitution group
-
-   This section is intentionally blank. It is present in order to ensure that section numbers correspond to [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, as described by Section 9, Rules for a NIEM profile of XML Schema, above.
-
-9.2.3. Attribute declaration
-
-   Within an attribute declaration, the attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local attribute declarations.
-
-Rule 9-47. Attribute declaration is top-level
-
-   [Rule 9-47] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@name)]">
-          <sch:assert test="exists(parent::xs:schema)"
-            >An attribute declaration MUST be top-level.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   All schema components defined by NIEM-conformant schemas are named, accessible from outside the defining schema, and reusable across schemas. Local attribute declarations 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.
-
-Rule 9-48. Attribute declaration has data definition
-
-   [Rule 9-48] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@name)]">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >An attribute declaration MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [data definition].
-
-Rule 9-49. Attribute declaration has type
-
-   [Rule 9-49] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@name)]">
-          <sch:assert test="exists(@type)"
-            >A top-level attribute declaration MUST have a type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Untyped XML Schema attributes allow arbitrary content, with no semantics. Attributes must have a type so that specific syntax and semantics will be provided.
-
-9.2.3.1. Prohibited attribute types
-
-   There is no explicit prohibition on the use of xs:NOTATION as an attribute type, because it is prohibited by [XML Schema Datatypes].
-
-   These types are only explicitly prohibited from attributes, not elements, because the case is covered by a general prohibition against elements having simple types.
-
-Rule 9-50. No attribute type of xs:ID
-
-   [Rule 9-50] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ID')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:ID.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-51. No attribute type of xs:IDREF
-
-   [Rule 9-51] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:IDREF')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:IDREF.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-52. No attribute type of xs:IDREFS
-
-   [Rule 9-52] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:IDREFS')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-53. No attribute type of xs:ENTITY
-
-   [Rule 9-53] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ENTITY')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-54. No attribute type of xs:ENTITIES
-
-   [Rule 9-54] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ENTITIES')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-55. No attribute type of xs:anySimpleType
-
-   [Rule 9-55] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:anySimpleType')"
-            >A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.2.3.2. No attribute value constraints
-
-Rule 9-56. No attribute default values
-
-   [Rule 9-56] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute">
-          <sch:assert test="empty(@default)"
-            >An element xs:attribute MUST NOT have an attribute {}default.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above.
-
-Rule 9-57. No attribute fixed values
-
-   [Rule 9-57] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute">
-          <sch:assert test="empty(@fixed)"
-            >An element xs:attribute MUST NOT have an attribute {}fixed.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above. The use of the fixed attribute may result in alteration of the post-schema-validation infoset, like the use of default does. This behavior is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component.
-
-9.2.4. Notation declaration
-
-Rule 9-58. No use of element xs:notation
-
-   [Rule 9-58] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:notation">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:notation.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   See Rule 9-7, No base type of xs:NOTATION, above, for comments about the use of notations.
-
-9.3. Model group components
-
-9.3.1. Model group
-
-   Complex content definitions in XML Schema use model group schema components. These schema components, xs:all, xs:choice and xs:sequence, also called compositors, provide for ordering and selection of particles within a model group.
-
-   XML Schema defines a particle as an occurrence of xs:element, xs:sequence, xs:choice, xs:any (wildcard) and xs:group (model group) within a content model. For example, an xs:sequence within an XML Schema complex type is a particle. An xs:element occurring within an xs:sequence is also a particle.
-
-Rule 9-59. Model group does not affect meaning
-
-   [Rule 9-59] (EXT)
-
-      The use of model groups xs:all, xs:sequence, and xs:choice MUST NOT define the semantics of an instance. The meaning of an element occurrance occurrence within an element occurrence MUST be identical, regardless of the model group used to define a [schema component].
-
-Rule 9-60. No xs:all
-
-   [Rule 9-60] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:all">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:all</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The element xs:all provides a set of particles (e.g., elements) that may be included in an instance, in no particular order. This compositor does not support a variety of cardinalities, has shown to be confusing in practice, and has functionality that overlaps with NIEM's use of substitution groups. Use of substitution groups is the preferred method in NIEM schemas for obtaining flexible content models.
-
-9.3.1.1. Sequence
-
-Rule 9-61. xs:sequence must be child of xs:extension
-
-   [Rule 9-61] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:sequence">
-          <sch:assert test="exists(parent::xs:extension)"
-            >An element xs:sequence MUST be a child of element xs:extension.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-62. xs:sequence must be child of xs:extension or xs:restriction
-
-   [Rule 9-62] (EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:sequence">
-          <sch:assert test="exists(parent::xs:extension) or exists(parent::xs:restriction)"
-            >An element xs:sequence MUST be a child of element xs:extension or xs:restriction.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.3.1.2. Choice
-
-Rule 9-63. No xs:choice
-
-   [Rule 9-63] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:choice">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:choice</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The element xs: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 xs:choice may be used in extension schemas, as it presents a simple way for a schema writer to represent a set of optional content.
-
-Rule 9-64. xs:choice must be child of xs:sequence
-
-   [Rule 9-64] (EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:choice">
-          <sch:assert test="exists(parent::xs:sequence)"
-            >An element xs:choice MUST be a child of element xs:sequence.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.3.2. Particle
-
-   In NIEM schemas, an element use is a an element declaration acting as a particle within a content model. Each such element declaration must reference a top-level named element declaration.
-
-   Element declarations acting as a particle (particles formed by xs:element) may have any cardinality. NIEM does not provide additional constraints on the values of the XML Schema properties {min occurs} and {max occurs} on element uses. These properties are described by [XML Schema Structures] Section 3.9.1, The Particle Schema Component.
-
-9.3.2.1. Sequence cardinality
-
-   XML Schema allows each particle to specify cardinality (how many times the particle may appear in an instance). NIEM restricts the cardinality of xs:sequence particles to exactly one, to ensure that content model definitions are defined in as straightforward a manner as possible.
-
-   A schema developer who requires the instance syntax that would be obtained from the use of specific cardinality on sequences should define cardinality on individual element uses.
-
-Rule 9-65. Sequence has minimum cardinality 1
-
-   [Rule 9-65] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:sequence">
-          <sch:assert test="empty(@minOccurs) or xs:integer(@minOccurs) = 1"
-            >An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-66. Sequence has maximum cardinality 1
-
-   [Rule 9-66] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:sequence">
-          <sch:assert test="empty(@maxOccurs) or (@maxOccurs instance of xs:integer
-                                                  and 1 = xs:integer(@maxOccurs))"
-            >An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.3.2.2. Choice cardinality
-
-Rule 9-67. Choice has minimum cardinality 1
-
-   [Rule 9-67] (EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:choice">
-          <sch:assert test="empty(@minOccurs) or 1 = xs:integer(@minOccurs)"
-            >An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-68. Choice has maximum cardinality 1
-
-   [Rule 9-68] (EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:choice">
-          <sch:assert test="empty(@maxOccurs) or (@maxOccurs instance of xs:integer
-                                                  and 1 = xs:integer(@maxOccurs))"
-            >An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.3.3. Attribute use
-
-   An attribute use has an {attribute declaration} property that is a top-level, named attribute declaration. NIEM-conformant schemas do not define local named attributes within type definitions. Within an attribute use, the attribute use may be used as per the XML Schema specification.
-
-9.3.4. Wildcard
-
-Rule 9-69. No use of xs:any
-
-   [Rule 9-69] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:any">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:any.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The xs:any particle (see Model Group Restrictions for an informative definition of particle) provides a wildcard that may carry arbitrary content. The particle xs:any may appear within an [extension schema document].
-
-Rule 9-70. No use of xs:anyAttribute
-
-   [Rule 9-70] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:anyAttribute">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:anyAttribute.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The xs:anyAttribute element provides a wildcard, where arbitrary attributes may appear.
-
-9.4. Identity-constraint definition components
-
-   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 consistent through schema reuse.
-
-   Note that there is no prohibition on the use of xs:selector and xs:field, since according to the rules of the [XML Schema definition language], they can only appear within xs:key, xs:keyRefkeyref, and xs:unique, which are themselves prohibited.
-
-Rule 9-71. No use of xs:unique
-
-   [Rule 9-71] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:unique">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:unique.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-72. No use of xs:key
-
-   [Rule 9-72] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:key">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:key.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-73. No use of xs:keyref
-
-   [Rule 9-73] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:keyref">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:keyref.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.5. Group definition components
-
-9.5.1. Model group definition
-
-Rule 9-74. No use of xs:group
-
-   [Rule 9-74] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:group">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:group.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   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 multiple types, and which consists of a sequence of or choice between element particles. NIEM has not developed a semantic model for these components, and they are not integrated into NIEM's design.
-
-9.5.2. Attribute group definition
-
-Rule 9-75. No definition of attribute groups
-
-   Per Rule 11-24, Schema uses only known attribute groups, the only attribute groups used in NIEM-conformant schemas are structures:SimpleObjectAttributeGroup and attribute groups defined by the IC-ISM and IC-NTK schemas. Therefore, NIEM-conformant schemas do not define additional attribute groups.
-
-   [Rule 9-75] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attributeGroup[@name]">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain an attribute group definition schema component.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.6. Annotation components
-
-Rule 9-76. Comment is not recommended
-
-   Note that this rule is written with a context that is not as precise as it could be. Its context is the parent node of the comment node, in order to avoid error messages when executed with common Schematron implementations.
-
-   [Rule 9-76] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="node()[comment()]">
-          <sch:report test="true()"
-            >An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema.</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   Since XML comments are not associated with any specific XML Schema construct, there is no standard way to interpret comments. XML Schema annotations should be preferred for meaningful information about components. NIEM specifically defines how information should be encapsulated in NIEM-conformant schemas via xs:annotation elements.
-
-Rule 9-77. Documentation element has no element children
-
-   [Rule 9-77] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:documentation/node()">
-          <sch:assert test="self::text() or self::comment()"
-            >A child of element xs:documentation MUST be text or an XML comment.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.6.1. Application information annotation
-
-   XML Schema provides special annotations for support of automatic processing. The XML Schema specification provides the element xs:appinfo to carry such content and does not specify what style of content they should carry. In NIEM, xs:appinfo elements carry structured XML content.
-
-Rule 9-78. xs:appinfo children are comments, elements, or whitespace
-
-   [Rule 9-78] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:appinfo/node()">
-          <sch:assert test="self::comment()
-                            or self::element()
-                            or self::text()[string-length(normalize-space(.)) = 0]"
-            >A child of element xs:appinfo MUST be an element, a comment, or whitespace text.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Application information elements are intended for automatic processing; the meaning of an appinfo annotation is provided via elements.
-
-Rule 9-79. Appinfo child elements have namespaces
-
-   [Rule 9-79] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:appinfo/*">
-          <sch:assert test="namespace-uri() != xs:anyURI('')"
-            >An element that is a child of xs:appinfo MUST have a namespace name.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The XML namespaces specification includes the concept of content not in a namespace. Use of elements without namespaces can lead to conflicting data definitions, and makes it difficult to identify relevant data definitions.
-
-Rule 9-80. Appinfo descendants are not XML Schema elements
-
-   [Rule 9-80] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:appinfo//xs:*">
-          <sch:assert test="false()"
-            >An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   NIEM-conformant schemas are designed to be very easily processed. Although uses of XML Schema elements as content of xs:appinfo elements could be contrived, it is not current practice and complicates the processing of XML elements by their namespaces and names. Forbidding the use of XML Schema elements outside valid uses of schema simplifies such processing.
-
-9.7. Schema as a whole
-
-   The XML Schema language defines that the document element xs:schema may contain the optional attributes attributeFormDefault and elementFormDefault. The values of these attributes are not material to a conformant schema, as each attribute and element defined by a conformant schema is defined as a top-level component, and so each is qualified by its target namespace.
-
-Rule 9-81. Schema has data definition
-
-   [Rule 9-81] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema">
-          <sch:assert test="some $definition in (xs:annotation/xs:documentation)[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >An element xs:schema MUST have a data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-82. Schema document defines target namespace
-
-   [Rule 9-82] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema">
-          <sch:assert test="exists(@targetNamespace)"
-            >The schema MUST define a target namespace.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Schemas without defined namespaces provide definitions that are ambiguous, in that they are not universally identifiable.
-
-Rule 9-83. Target namespace is absolute URI
-
-   [Rule 9-83] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema[exists(@targetNamespace)]">
-          <sch:report test="true()"
-                      ><![CDATA[The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986.]]></sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   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. <absolute-URI> is a grammar production defined by [RFC 3986] Section 4.3, Absolute URI. 
-
-Rule 9-84. Schema has version
-
-   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.
-
-   An author of an application schema or exchange may use the version attribute for these purposes within their schemas.
-
-   [Rule 9-84] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema">
-          <sch:assert test="some $version in @version satisfies
-                            string-length(normalize-space(@version)) &gt; 0"
-              >An element xs:schema MUST have an attribute {}version that MUST NOT be empty.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-85. No disallowed substitutions
-
-   [Rule 9-85] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema">
-          <sch:assert test="empty(@blockDefault)"
-            >An element xs:schema MUST NOT have an attribute {}blockDefault.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-86. No disallowed derivations
-
-   [Rule 9-86] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema">
-          <sch:assert test="empty(@finalDefault)"
-            >An element xs:schema MUST NOT have an attribute {}finalDefault.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-9.8. Schema assembly
-
-Rule 9-87. No use of xs:redefine
-
-   [Rule 9-87] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:redefine">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:redefine.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The xs:redefine element allows an XML Schema document to restrict and extend components from a namespace, in a separate schema document from the one that initially defined that namespace. Such redefinition introduces duplication of definitions, allowing multiple definitions to exist for components from a single namespace. This violates [Principle 9], above, that a single reference schema defines a NIEM-conformant namespace.
-
-Rule 9-88. No use of xs:include
-
-   [Rule 9-88] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:include">
-          <sch:assert test="false()"
-            >The schema MUST NOT contain the element xs:include.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Element xs: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 9], above, as it uses multiple schemas to construct a namespace.
-
-Rule 9-89. xs:import must have namespace
-
-   [Rule 9-89] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:import">
-          <sch:assert test="exists(@namespace)"
-            >An element xs:import MUST have an attribute {}namespace.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   An import that does not specify a namespace is enabling references 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.
-
-Rule 9-90. XML Schema document set must be complete
-
-   An [XML Schema document set] defines an [XML Schema] that may be used to validate an [XML document]. This rule ensures that a schema document set under consideration contains definitions for everything that it references; it has everything necessary to do a complete validation of XML documents, without any unresolved references. Note that some tools may allow validation of documents using partial schemas, when components that are not present are not exercised by the XML document under validation. Such a schema does not meet qualify as a [conformant schema document set].
-
-   [Rule 9-90] (SET)
-
-      The schema document set must constitute a complete XML Schema; it must contain the definition of every schema component referenced by any component defined by the schema set.
-
-9.8.1. Namespaces for referenced components are imported
-
-   The [XML Schema definition language] requires that, when a [schema document] references a component in some other namespace, it must use xs:import to import the namespace of the referenced component. The use of xs:import is described by [XML Schema Structures] Section 4.2.3, References to schema components across namespaces.
-
-   Some tools do not enforce this constraint; one such tool carries imports from a [schema document] into [schema documents] that it imports. This has the potential to introduce incompatibility into schema documents and schema document sets that exercise this bug. To maintain compatibility across tool sets, this requirement is an explicit rule for NIEM-conformant schemas.
-
-Rule 9-91. Namespace referenced by attribute type is imported
-
-   [Rule 9-91] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@type]">
-          <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@type, .)) satisfies (
-                              $namespace = nf:get-target-namespace(.)
-                              or $namespace = xs:anyURI('http://www.w3.org/2001/XMLSchema')
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
-                      >The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-92. Namespace referenced by attribute base is imported
-
-   [Rule 9-92] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@base]">
-          <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@base, .)) satisfies (
-                              $namespace = nf:get-target-namespace(.)
-                              or $namespace = xs:anyURI('http://www.w3.org/2001/XMLSchema')
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
-                      >The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-93. Namespace referenced by attribute itemType is imported
-
-   [Rule 9-93] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@itemType]">
-          <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@itemType, .)) satisfies (
-                              $namespace = nf:get-target-namespace(.)
-                              or $namespace = xs:anyURI('http://www.w3.org/2001/XMLSchema')
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
-                      >The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-94. Namespaces referenced by attribute memberTypes is imported
-
-   [Rule 9-94] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@memberTypes]">
-          <sch:assert test="every $type in tokenize(normalize-space(@memberTypes), ' '),
-                                  $namespace in namespace-uri-from-QName(resolve-QName($type, .)) satisfies (
-                              $namespace = nf:get-target-namespace(.)
-                              or $namespace = xs:anyURI('http://www.w3.org/2001/XMLSchema')
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
-                      >The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-95. Namespace referenced by attribute ref is imported
-
-   [Rule 9-95] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@ref]">
-          <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies
-                              $namespace = nf:get-target-namespace(.)
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace]"
-                      >The namespace of a component referenced by @ref MUST be the target namespace or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 9-96. Namespace referenced by attribute substitutionGroup is imported
-
-   [Rule 9-96] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[@substitutionGroup]">
-          <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@substitutionGroup, .)) satisfies
-                              $namespace = nf:get-target-namespace(.)
-                              or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace]"
-                      >The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10. Rules for NIEM modeling, by NIEM concept
-
-   This section focuses on building NIEM data models using the [XML Schema definition language]. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.
-
-   NIEM provides a framework for modeling concepts and relationships as XML artifacts. The data model is implemented via XML Schema. However, XML Schema does not provide sufficient structure and constraint to enable translating from a conceptual model to a schema and then to instances of the concepts. NIEM provides additional support for modeling concepts as schemas and provides rules for creating and connecting data that realizes those concepts.
-
-   Underlying the NIEM data model are two namespaces: the [structures namespace] and the [appinfo namespace]. These two namespaces provide schema components that serve two functions:
-
-      1. They provide support for connecting structural definitions to concepts.
-
-      2. They provide base components from which to derive structural definitions.
-
-   These namespaces are distributed with the NIEM data model content but are not themselves considered to be content of the data model. They are, instead, part of the structure on which the data model is built.
-
-   This section is organized by concept, rather than component type. This section is integrated with the following sections:
-
-      *  Section 11, Rules for NIEM modeling, by XML Schema component, below, is organized by component type, and provides a majority of the constraint rules for schemas that define NIEM models.
-
-      *  Section 12, XML instance document rules, below, provides rules for XML documents that are instances of NIEM models.
-
-   Concepts covered by this section include:
-
-   * Section 10.1, Categories of NIEM type definitions
-   * Section 10.2, Object
-   * Section 10.3, Associations
-   * Section 10.4, Augmentations
-   * Section 10.5, Metadata
-   * Section 10.6, Container elements
-   * Section 10.7, The "Representation" pattern
-   * Section 10.8, Naming rules
-   * Section 10.9, Machine-readable annotations
-   * Section 10.10, NIEM structural facilities
-
-10.1. Categories of NIEM type definitions
-
-   The rules in this document use the name of a type as the key indicator of the type's category. This makes the rules much simpler than doing a deep examination of each type (and its base types) to identify its category. For example, for complex types, the names follow a pattern:
-
-      *  Name ends with "AssociationType" -> type is an association type.
-
-      *  Name ends with "MetadataType" -> type is a metadata type.
-
-      *  Name ends with "AugmentationType" -> type is an augmentation type.
-
-      *  Otherwise -> type is an object type.
-
-Rule 10-1. Complex type has a category
-
-   [Rule 10-1] (REF, EXT)
-
-      Within the schema, a complex type definition MUST be one of the following:
-
-         1. An object type.
-
-         2. An association type.
-
-         3. A metadata type.
-
-         4. An augmentation type.
-
-   This rule establishes the categories of NIEM complex types. It is a limited set, and each category has distinct semantics, as described by following sections.
-
-10.2. Object
-
-   The categories of objects are covered by the following sections:
-
-   * Section 10.2.1, General object types
-   * Section 10.2.2, Role types and roles
-   * Section 10.2.3, External adapter types and external components
-   * Section 10.2.4, Code types
-   * Section 10.2.5, Proxy types
-
-10.2.1. General object types
-
-   [Definition: object type]
-
-      In a NIEM-conformant schema, an object type is a complex type definition, an instance of which asserts the existence of an object. An object type represents some kind of object: a thing with its own lifespan that has some existence. The object may or may not be a physical object. It may be a conceptual object.
-
-10.2.1.1. Object types with complex content
-
-Rule 10-2. Object type with complex content is derived from object type
-
-   [Rule 10-2] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[exists(xs:complexContent)
-                                          and not(ends-with(@name, 'AssociationType')
-                                              or ends-with(@name, 'MetadataType')
-                                              or ends-with(@name, 'AugmentationType'))]">
-          <sch:assert test="
-              every $derivation-method in (xs:complexContent/xs:extension, xs:complexContent/xs:restriction),
-                    $base in $derivation-method/@base,
-                    $base-qname in resolve-QName($base, $derivation-method),
-                    $base-local-name in local-name-from-QName($base-qname) satisfies (
-                $base-qname = xs:QName('structures:ObjectType')
-                or not(ends-with($base-local-name, 'AssociationType')
-                       or ends-with($base-local-name, 'MetadataType')
-                       or ends-with($base-local-name, 'AugmentationType')))"
-            >An object type with complex content MUST be derived from structures:ObjectType or from another object type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   A [base type definition] with a {target namespace} that is the XML namespace is prohibited by Rule 9-1, No base type in the XML namespace. A [base type definition] with a {target namespace} that is not imported as conformant is prohibited by Rule 11-3, Base type definition defined by conformant schema.
-
-10.2.2. Role types and roles
-
-   NIEM differentiates between an object and a role of the object. The term "role" is used here to mean a function or part played by some object. The simplest way to represent a role of an object is to use an element. The following element declaration models the role of a person who undergoes an assessment:
-
-   Figure 10-1: An element declaration that constitutes a role without the use of a role type
-
-      <xs:element name="AssessmentPerson" type="nc:PersonType" nillable="true">
-        <xs:annotation>
-          <xs:documentation>A person who undergoes an assessment.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   In many cases, there is a further need to represent characteristics and additional information associated with a role of an object. In such cases, the above element is insufficient. When a role must be modeled with additional information, a [role type] is called for.
-
-   For example, when a person is a driver involved in an automotive crash, that person has a particular role in the crash, which is modeled by the element j:CrashDriver.
-
-   Figure 10-2: Element j:CrashDriver, modeling the role of a driver in a crash
-
-      <xs:element name="CrashDriver" type="j:CrashDriverType" nillable="true">
-        <xs:annotation>
-          <xs:documentation>A motor vehicle driver involved into a traffic accident.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   There is more information associated with this role of the driver than just his identity as a person. Information associated with this role include the drivers license, contributing circumstances, distractions, and other properties. These characteristics are modeled as shown in the following figure. The role is modeled as a [role type]:
-
-   Figure 10-3: Role type j:CrashDriverType, modeling a driver involved in a crash
-
-      <xs:complexType name="CrashDriverType">
-        <xs:annotation>
-          <xs:documentation>A data type for a motor vehicle driver involved in a traffic accident.</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="structures:ObjectType">
-            <xs:sequence>
-              <xs:element ref="nc:RoleOfPerson" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:DriverLicense" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:CrashDriverContributingCircumstances" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:CrashDriverDistraction" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:CrashDriverViolation" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:CrashDrivingViolation" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:CrashDriverAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-            </xs:sequence>
-          </xs:extension>
-        </xs:complexContent>
-      </xs:complexType>
-
-   The term [role type] has a normative definition:
-
-   [Definition: role type]
-
-      A role type is an [object type] that represents a particular function, purpose, usage, or role of one or more objects of its base type.
-
-   A [role type] describes a role of a thing. A role is a function or position played by something in a particular situation or context. A [role type] holds information that is specific to the role, but that is not specific to the context, and is not specific to thing that plays the role.
-
-   In the example (Figure 10-5, An XML instance of a role type, below), a person (John Doe) has the role of being a driver in a crash. Associated with this role are descriptions of a law violation related to him and a law violation related to his driving behavior. These are properties of his role as a driver in a crash.
-
-   This data is described by a [role type], j:CrashDriverType (described by Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above), which carries elements and attributes that are properties of the role. The role type also carries a [RoleOf element], which indicates the base type for the role. The [role type] describes a role of the base type, which in this case is nc:PersonType, as identified by the type of nc:RoleOfPerson defined by Figure 10-4, Declaration of RoleOf element nc:RoleOfPerson, below.
-
-   Developers of NIEM-conformant schemas and exchanges should create and use role types whenever they have information specific to a base object's function. Such information is a characteristic of the rule role, and not of the base object. Information that is a characteristic of a base object probably does not belong in a role type.
-
-   [Definition: RoleOf element]
-
-      A RoleOf element is an [element declaration] that
-
-         *  is defined by a [reference schema document] or an [extension schema document], and
-
-         *  has a {name} that begins with "RoleOf".
-
-      A RoleOf element represents a base type for a [role type].
-
-   We saw the use of [RoleOf element] nc:RoleOfPerson in Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above. Its definition is the following figure:
-
-   Figure 10-4: Declaration of RoleOf element nc:RoleOfPerson
-
-      <xs:element name="RoleOfPerson" type="nc:PersonType" substitutionGroup="nc:RoleOf" nillable="true">
-        <xs:annotation>
-          <xs:documentation>A person of whom the role object is a function.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   Here is an example of the j:CrashDriver role type used in an instance:
-
-   Figure 10-5: An XML instance of a role type
-
-      <j:CrashDriver>
-        <nc:RoleOfPerson structures:ref="BRAVO"/>
-        <j:CrashDriverViolationCode>A10</j:CrashDriverViolationCode>
-        <j:CrashDrivingViolationCode>S16</j:CrashDrivingViolationCode>
-      </j:CrashDriver>
-      <nc:Person structures:id="BRAVO">
-        <nc:PersonBirthDate>
-          <nc:Date>1966-06-06</nc:Date>
-        </nc:PersonBirthDate>
-        <nc:PersonName>
-          <nc:PersonFullName>John Doe</nc:PersonFullName>
-        </nc:PersonName>
-      </nc:Person>
-
-   Note that the value of the j:CrashPerson element was indicated above using a reference; it could have been shown as a content element, instead.
-
-Rule 10-3. RoleOf element type is an object type
-
-   [Rule 10-3] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name[starts-with(., 'RoleOf')]]">
-          <sch:assert test="every $type in @type,
-                                  $type-local-name in local-name-from-QName(resolve-QName($type, .)) satisfies
-                              not(ends-with($type-local-name, 'AssociationType')
-                                  or ends-with($type-local-name, 'MetadataType')
-                                  or ends-with($type-local-name, 'AugmentationType'))"
-            >The type definition of a RoleOf element MUST be an object type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that by Rule 11-14, Element type is from conformant namespace, the element's type must be from a conformant namespace.
-
-Rule 10-4. Only object type has RoleOf element
-
-   [Rule 10-4] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[
-            empty(@appinfo:externalAdapterTypeIndicator)
-            and exists(descendant::xs:element[
-                  exists(@ref[
-                    starts-with(local-name-from-QName(resolve-QName(., ..)), 'RoleOf')])])]">
-          <sch:assert test="not(ends-with(@name, 'AssociationType')
-                                or ends-with(@name, 'MetadataType')
-                                or ends-with(@name, 'AugmentationType'))"
-            >A complex type that includes a RoleOf element in its content model MUST be an object type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that [RoleOf element] and [object type] are defined terms.
-
-Rule 10-5. RoleOf elements indicate the base types of a role type
-
-   [Rule 10-5] (REF, EXT, INS)
-
-      An [element declaration] that has a local name that begins with the string "RoleOf" MUST represent a base type, of which the containing element instance represents a role.
-
-Rule 10-6. Instance of RoleOf element indicates a role object
-
-   [Rule 10-6] (INS)
-
-      When a parent element has a child element valid to an [element declaration] that is a [RoleOf element],
-
-         *  The value of the parent element is a role object.
-
-         *  The value of the child element is a base object of the role object.
-
-   An instance of a [RoleOf element] indicates the base object of a role. The prefix "RoleOf" on the element ensures that a role object may be distinguished from other objects and that its link to the base object is also distinguishable from the additional properties that are characteristics or other data of the role.
-
-   NIEM does not require that there be only one [RoleOf element] within a single type, nor does it require that a particular role object have only a single occurrence of a [RoleOf element]. However, the use of multiple [RoleOf elements] may not make sense in all cases. An exchange specification may restrict [RoleOf elements] to a single occurrence within a type.
-
-   This specification does not require that a [RoleOf element] occur in an instance of a [role type]. In such a case, the instance of the role type behaves like any other type; it simply does not have a reference to its base object. For example, we may talk about a weapon's use in an incident without referring to the car that acted as the weapon.
-
-10.2.3. External adapter types and external components
-
-   There are a variety of commonly used standards that are represented in XML Schema. Such schemas are generally not NIEM-conformant. NIEM-conformant schemas may reference components defined by these external schema documents. This section provides rules under which NIEM-conformant components may be constructed from schema components that are not NIEM-conformant.
-
-   [Definition: external schema document]
-
-      An external schema document is any [schema document] that is not one of
-
-         *  a [reference schema document],
-
-         *  an [extension schema document], or
-
-         *  a [schema document] that has the [structures namespace] as its target namespace.
-
-   Note that, although the schema document for the [structures namespace] is not conformant, it is not considered an external schema document because it defines the fundamental framework on which NIEM is built; it is considered a supporting namespace. It is not considered an external schema document because of its supporting nature and is thus a special case of this definition.
-
-   A [schema component] defined by an [external schema document] may be called an external component. A NIEM-conformant type may use external components in its definition. There are two ways to integrate external components into a NIEM-conformant schema:
-
-      1. An external adapter type may be constructured constructed from externally-defined elements and attributes. A goal of this method is to represent, as a single unit, a set of data that embodies a single concept from an external standard. This is an [external adapter type].
-
-      2. A type that is not an external adapter type may incorporate externally-defined attributes.
-
-   Figure 10-6: Use of external components to create a NIEM-conformant type
-
-      Images are omitted from this edition.
-
-   For example, a NIEM-conformant type may be created to represent a bibliographic reference from an external standard. Such an object may be composed of multiple elements (of multiple types) from the external standard. These pieces are put together to form a single NIEM-conformant [external adapter type]. For example, an author element, a book element, and a publisher element may be used to define a single bibliographic entry type.
-
-   A NIEM-conformant type built from these components may be used as any other NIEM-conformant type. That is, elements may be constructed from such a type, and those elements are fully NIEM-conformant.
-
-   To construct such a component, a NIEM-conformant schema must import the namespace defined by the [external schema document].
-
-   Rule 11-36, Reference schema imports reference schema and Rule 11-37, Extension schema document imports reference or extension schema require that xs:import elements be consistent with an importing [schema document].
-
-   A NIEM-conformant schema has well-known documentation points. Therefore, a schema that imports a NIEM-conformant namespace need not provide additional documentation. However, when an external schema document is imported, appropriate documentation must be provided at the point of import because documentation associated with external schema documents is undefined and variable. In this particular case, documentation of external schema documents is required at their point of use in NIEM.
-
-10.2.3.1. Import of external namespace
-
-Rule 10-7. Import of external namespace has data definition
-
-   [Rule 10-7] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:import[@appinfo:externalImportIndicator]">
-          <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($definition))) &gt; 0"
-            >An element xs:import that is annotated as importing an external schema document MUST be a documented component.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.2.3.2. External adapter types
-
-   [Definition: external adapter type]
-
-      An external adapter type is a NIEM-conformant type that adapts external components for use within NIEM. An external adapter type creates a new class of object that embodies a single concept composed of external components. A NIEM-conformant schema defines an external adapter type.
-
-Rule 10-8. External adapter type has indicator
-
-   [Rule 10-8] (REF, EXT)
-
-      A type is an [external adapter type] if and only if it is a complex type with application information of attribute appinfo:externalAdapterTypeIndicator with a value of true.
-
-   An external adapter type should contain the information from an external standard to express a complete concept. This expression should be composed of content entirely from an external schema document. Most likely, the external schema document will be based on an external standard with its own legacy support.
-
-   In the case of an external expression that is in the form of model groups, attribute groups, or types, additional elements and type components may be created in an external schema document, and the external adapter type may use those components.
-
-   In normal (conformant) type definition, a reference to an attribute or element is a reference to a documented component. Within an external adapter type, the references to the attributes and elements being adapted are references to undocumented components. These components must be documented to provide comprehensibility and interoperability. Since documentation made available by nonconformant schemas is undefined and variable, documentation of these components is required at their point of use, within the conformant schema.
-
-Rule 10-9. Structure of external adapter type definition follows pattern
-
-   [Rule 10-9] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[@appinfo:externalAdapterTypeIndicator]">
-          <sch:assert test="xs:complexContent/xs:extension[
-                              resolve-QName(@base, .) = xs:QName('structures:ObjectType')
-                            ]/xs:sequence"
-            >An external adapter type definition MUST be a complex type definition with complex content that extends structures:ObjectType, and that uses xs:sequence as its top-level compositor.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-10. Element use from external adapter type defined by external schema documents
-
-   [Rule 10-10] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@ref
-                                      and exists(ancestor::xs:complexType[exists(@appinfo:externalAdapterTypeIndicator)])]">
-          <sch:assert test="some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies
-                              nf:get-document-element(.)/xs:import[
-                                $ref-namespace = xs:anyURI(@namespace)
-                                and @appinfo:externalImportIndicator]"
-            >An element reference that appears within an external adapter type MUST have a target namespace that is imported as external.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-11. External adapter type not a base type
-
-   [Rule 10-11] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[(self::xs:extension or self::xs:restriction)
-                                and (some $base-qname in resolve-QName(@base, .),
-                                          $base-namespace in namespace-uri-from-QName($base-qname) satisfies
-                                       nf:get-target-namespace(.) = $base-namespace)]">
-          <sch:assert test="nf:resolve-type(., resolve-QName(@base, .))[
-                              empty(@appinfo:externalAdapterTypeIndicator)]"
-             >An external adapter type definition MUST NOT be a base type definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Each external adapter type is meant to stand alone; each type expresses a single concept, and is built from schema components from one or more external schema documents.
-
-Rule 10-12. External adapter type not a base type
-
-   [Rule 10-12] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[(self::xs:extension or self::xs:restriction)
-                                and (nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))
-                                     or nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument')))
-                                and (some $base-qname in resolve-QName(@base, .),
-                                          $base-namespace in namespace-uri-from-QName($base-qname) satisfies
-                                       not($base-namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))))]">
-          <sch:assert test="nf:resolve-type(., resolve-QName(@base, .))[
-                              empty(@appinfo:externalAdapterTypeIndicator)]"
-             >An external adapter type definition MUST NOT be a base type definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Each external adapter type is meant to stand alone; each type expresses a single concept, and is built from schema components from one or more external schema documents.
-
-10.2.3.3. External attribute use
-
-Rule 10-13. External attribute use only in external adapter type
-
-   A complex type that is defined by a [reference schema document] is permitted to contain an attribute use schema component only if it is an [external adapter type]. This does not apply to a complex type defined by an [extension schema document], which is permitted to use external attributes, as long as each attribute use is a [documented component], per Rule 10-14, External attribute use has data definition.
-
-   [Rule 10-13] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)),
-                                             $import in ancestor::xs:schema[1]/xs:import satisfies (
-                                          xs:anyURI($import/@namespace) = $ref-namespace
-                                          and exists($import/@appinfo:externalImportIndicator))]">
-          <sch:assert test="exists(ancestor::xs:complexType[1]/@appinfo:externalAdapterTypeIndicator)"
-            >An external attribute use MUST be in an external adapter type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [external adapter type].
-
-Rule 10-14. External attribute use has data definition
-
-   [Rule 10-14] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)),
-                                             $import in ancestor::xs:schema[1]/xs:import satisfies (
-                                          xs:anyURI($import/@namespace) = $ref-namespace
-                                          and exists(@appinfo:externalImportIndicator))]">
-          <sch:assert test="some $documentation in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($documentation))) &gt; 0"
-            >An external attribute use MUST be a documented component with a non-empty data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The terms [documented component] and [data definition] are defined.
-
-Rule 10-15. External attribute use not an ID
-
-   NIEM schemas use structures:id to enable references between components. Each NIEM-defined complex type must incorporate a definition for structures:id. [XML] Section 3.3.1, Attribute Types entails that a complex type may have no more than one ID attribute. This means that an external attribute use must not be an ID attribute.
-
-   [Rule 10-15] (SET)
-
-      An attribute use schema component MUST NOT have an {attribute declaration} with an ID type.
-
-   The term "attribute use schema component" is defined by [XML Schema Structures] Section 3.5.1, The Attribute Use Schema Component. Attribute type ID is defined by [XML] Section 3.3.1, Attribute Types.
-
-10.2.3.4. External element use
-
-Rule 10-16. External element use has data definition
-
-   [Rule 10-16] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[
-            some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies
-              nf:get-document-element(.)/self::xs:schema//xs:import[
-                xs:anyURI(@namespace) = $ref-namespace
-                and @appinfo:externalImportIndicator]]">
-          <sch:assert test="some $documentation in xs:annotation/xs:documentation[1] satisfies
-                              string-length(normalize-space(string($documentation))) &gt; 0"
-            >An external attribute use MUST be a documented component with a non-empty data definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The terms [documented component] and [data definition] are defined.
-
-10.2.4. Code types
-
-   [Definition: code type]
-
-      A code type is a NIEM object type with a content model that is constrained by one or more enumeration facets.
-
-   These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.
-
-Rule 10-17. Name of code type ends in "CodeType"
-
-   [Rule 10-17] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:let name="has-code-type-name" value="ends-with(@name, 'CodeType')"/>
-          <sch:let name="has-code-type-base" value="
-              exists(xs:simpleContent[
-                exists(xs:*[local-name() = ('extension', 'restriction')
-                            and (ends-with(@base, 'CodeSimpleType')
-                                 or ends-with(@base, 'CodeType'))])])"/>
-          <sch:assert test="$has-code-type-name = $has-code-type-base"
-            >A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.
-
-10.2.5. Proxy types
-
-   The NIEM 3.0 release schema niem/proxy/xsd/3.0/xs.xsd provides complex type bases for some of the simple types in the XML Schema namespace. The complex types in this schema reuse the local names of the XML Schema simple types they extend, even though those names don't follow the naming structure of most conformant complex types. There is a special exception to naming rules to allow the reuse of the XML Schema simple type names in conformant schemas. This is done to make conformant schemas more understandable to people that are familiar with the names of the XML Schema namespace simple types.
-
-   A complex type that is a direct extension of a simple type from the XML Schema namespace (e.g., xs:string, xs:integer, xs:boolean) is allowed to have the same local name as the XML Schema simple type, if and only if the extension adds no content other than the attribute group structures:SimpleObjectAttributeGroup. This allows for an intuitive name when using an XML Schema simple type in a conformant schema.
-
-Rule 10-18. Proxy type has designated structure
-
-   [Rule 10-18] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[some $name in @name,
-                                          $extension in xs:simpleContent/xs:extension,
-                                          $base-qname in resolve-QName($extension/@base, $extension) satisfies
-                                          $base-qname = QName('http://www.w3.org/2001/XMLSchema', @name) $name)]">
-          <sch:assert test="xs:simpleContent[
-                              xs:extension[
-                                empty(xs:attribute)
-                                and count(xs:attributeGroup) = 1
-                                and xs:attributeGroup[
-                                      resolve-QName(@ref, .) = xs:QName('structures:SimpleObjectAttributeGroup')]]]"
-            >A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.3. Associations
-
-   Within NIEM, an association is a specific relationship between objects. Associations are used when a simple NIEM property is insufficient to model the relationship clearly, or when you want to model properties of the relationship itself.
-
-   Here is an example of an association in an XML instance:
-
-   Figure 10-7: An association in an instance
-
-      <scr:PersonPhoneAssociation>
-        <nc:Person>
-          <nc:PersonName>
-            <nc:PersonFullName>John Doe</nc:PersonFullName>
-          </nc:PersonName>
-        </nc:Person>
-        <nc:TelephoneNumber>
-          <nc:FullTelephoneNumber>
-            <nc:TelephoneNumberFullID>(212)555-1212</nc:TelephoneNumberFullID>
-          </nc:FullTelephoneNumber>
-        </nc:TelephoneNumber>
-      </scr:PersonPhoneAssociation>
-
-   This example shows an association between a person and a phone number. This relationship is defined by the element scr:PersonPhoneAssociation, the structure of which is defined by the type scr:PersonPhoneAssociationType. In practice, an [association type] usually defines what kinds of things the association relates, while the association element may refine the meaning of the association.
-
-   An example of an association type defined by an XML Schema document follows, in Figure 10-8, A definition of an association type, below.
-
-   Note that the NIEM Core schema in NIEM 3.0 defines a type nc:AssociationType, which acts as the base type for all of the other association types defined within NIEM Core. This is a convention adopted by that version of NIEM Core namespace, but is not a requirement of this document. An implementer of a NIEM-conformant schema is not required by this specification to base a new association type on nc:AssociationType.
-
-   Figure 10-8: A definition of an association type
-
-        <xs:complexType name="PersonPhoneAssociationType">
-          <xs:annotation>
-            <xs:documentation>A data type for a relationship between a PERSON and a PHONE.</xs:documentation>
-          </xs:annotation>
-          <xs:complexContent>
-            <xs:extension base="nc:AssociationType">
-              <xs:sequence>
-                <xs:element ref="nc:Person" minOccurs="0" maxOccurs="unbounded"/>
-                <xs:element ref="nc:TelephoneNumber" minOccurs="0" maxOccurs="unbounded"/>
-              </xs:sequence>
-            </xs:extension>
-          </xs:complexContent>
-        </xs:complexType>
-        <xs:element name="PersonPhoneAssociation" type="scr:PersonPhoneAssociationType" nillable="true">
-          <xs:annotation>
-            <xs:documentation>An association between a PERSON and a PHONE.</xs:documentation>
-          </xs:annotation>
-        </xs:element>
-
-   This schema fragment shows the definition of an association type that defines a relationship between a person and a telephone number. This is followed by the definition of an association element declaration that uses the association type.
-
-   [Definition: association type]
-
-      In a NIEM-conformant schema, an association type is a type that establishes a relationship between objects, along with the properties of that relationship. An association type provides a structure that does not establish existence of an object but instead specifies relationships between objects.
-
-   [Definition: association]
-
-      In a NIEM-conformant schema, an association is an [element] whose type is an [association type].
-
-10.3.1. Association types
-
-Rule 10-19. Association types type is derived from association type
-
-   [Rule 10-19] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:let name="is-association-type" value="exists(@name[ends-with(., 'AssociationType')])"/>
-          <sch:let name="has-association-base-type" value="
-            exists(xs:complexContent[
-              exists(xs:*[local-name() = ('extension', 'restriction')
-                          and exists(@base[ends-with(., 'AssociationType')])])])"/>
-          <sch:assert test="$is-association-type = $has-association-base-type"
-            >A type MUST have a an association type name if and only if it is derived from an association type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Associations are easily identifiable as such and have a commonly defined base type. Using the qualifier Association immediately identifies a type as representing an association.
-
-10.3.2. Association element declarations
-
-Rule 10-20. Association element type is an association type
-
-   [Rule 10-20] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="exists(@type[ends-with(., 'AssociationType')])
-                            = exists(@name[ends-with(., 'Association')])"
-            >An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Association immediately identifies an element as representing an association. This document defines the term [association type].
-
-10.4. Augmentations
-
-   Developers of domain schemas and other schemas that build on and extend the NIEM release schemas need to be able to define additional characteristics of common types. For example, the JXDM domain, which addresses justice and public safety concerns, considers the following elements to be characteristics of a person, as defined by nc:PersonType:
-
-      *  j:PersonMedicalInsuranceIndicator
-
-      *  j:PersonProfessionalCertificateText
-
-      *  j:PersonSightedIndicator
-
-      *  j:PersonFBIIdentification
-
-   There are several approaches that could be used to by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:
-
-      *  It results in numerous, domain-specific specializations of nc:PersonType, each with common content and extension-specific content.
-
-      *  There is no method for the developer of an information exchange specification (IES) to bring these types back together into a single type that carries the attributes desired for the IES. XML Schema does not support multiple inheritance, so there is no way to join together j:PersonType, im:PersonType, and cyfs:PersonType.
-
-      *  There is no standard or easy way for the developer to express that the various element instances of the various person types represent the same person, or which parts of those instances are required to be populated; does each person restate the name and birthdate, or is that handled by just one instance?
-
-      *  A domain, having created its own j:PersonType that extends nc:PersonType, is, of course, going to create elements of that type. These elements will not be easily reused by other domains, as the Immigration namespace will want to use im:PersonType instead of j:PersonType.
-
-   This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community.
-
-   To handle this need, NIEM has adopted augmentations. There are several parts that fit together for the definition and use of augmentations:
-
-      *  Each object type and association type carries an augmentation point element, which provides a place for domain- and extension-specific content in the type. Augmentation points are optional in extension schema documents, but must appear in reference schema documents. Augmentation points are also defined for the base types for [object types] and [association types]:
-
-            *  structures:ObjectType has augmentation point structures:ObjectAugmentationPoint.
-
-            *  structures:AssociationType has augmentation point structures:AssociationAugmentationPoint.
-
-      *  A developer of a domain or other schema that extends common types may define elements that are substitutable for an augmentation point. Each of these elements expresses an additional characteristic or relationship of the base type.
-
-      *  A developer may also define an augmentation type, and a corresponding augmentation element of that type, which acts as a bucket of elements that apply to the base type. An augmentation element is defined to be substitutable for an augmentation point, which enables it to appear in instances of that base type.
-
-      *  A developer of an information exchange may choose, through selection and subsetting reference schemas:
-
-            *  Which types will carry augmentation point elements, and the cardinality (i.e. minOccurs, maxOccurs) of those augmentation point elements
-
-            *  Which elements will be included that substitute for an augmentation point. Some of these may be direct elements, while others may have an augmentation type, and carry multiple elements for the base type.
-
-            *  Which elements will be carried within the augmentation types; each of these will apply to its base type.
-
-      *  Augmentation point elements also appear on structures:ObjectType and structures:AssociationType. This allows schema developers to define elements that may be applied to any object or association.
-
-   In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange.
-
-   [Definition: augmentation]
-
-      An augmentation is an [element] that
-
-         1. is a child of an [element] that is an instance of an [augmentable type], and
-
-         2. is a member of the substitution group of the augmentation point element declaration for the [augmentable type].
-
-   As an example, here is a definition for nc:PersonType, which includes its augmentation point element:
-
-   Figure 10-9: Definition of augmentable type nc:PersonType
-
-      <xs:complexType name="PersonType">
-        <xs:annotation>
-          <xs:documentation>A data type for a human being.</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="structures:ObjectType">
-            <xs:sequence>
-              <xs:element ref="nc:PersonBirthDate" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="nc:PersonName" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="nc:PersonAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-            </xs:sequence>
-          </xs:extension>
-        </xs:complexContent>
-      </xs:complexType>
-
-   Note that the augmentation point element has the same namespace and name as the type, with the suffix "Type" replaced by "AugmentationPoint". The augmentation point is also defined with cardinality (minOccurs 0, maxOccurs unbounded) to ensure that it can support an arbitrary number of augmentations, and can be subset or constrained as needed. The augmentation point is the last element used by its type; it is always last in the sequence. The definition of the augmentation point is pretty simple:
-
-   Figure 10-10: Declaration of augmentation point element nc:PersonAugmentationPoint
-
-      <xs:element name="PersonAugmentationPoint" abstract="true">
-        <xs:annotation>
-          <xs:documentation>An augmentation point for PersonType.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   The augmentation point element is abstract and typeless. This enables the substitution of elements that have simple content, elements that have complex content, or elements that are of an augmentation type. The JXDM domain defines an augmentation type and a corresponding augmentation element that substitutes for this augmentation point:
-
-   Figure 10-11: Declaration of augmentation type and element
-
-      <xs:complexType name="PersonAugmentationType">
-        <xs:annotation>
-          <xs:documentation>A data type for additional information about a person.</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="structures:AugmentationType">
-            <xs:sequence>
-              <xs:element ref="j:PersonMedicalInsuranceIndicator" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:PersonProfessionalCertificateText" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:PersonSightedIndicator" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="j:PersonFBIIdentification" minOccurs="0" maxOccurs="unbounded"/>
-            </xs:sequence>
-          </xs:extension>
-        </xs:complexContent>
-      </xs:complexType>
-      
-      <xs:element name="PersonAugmentation" type="j:PersonAugmentationType"
-                  substitutionGroup="nc:PersonAugmentationPoint">
-        <xs:annotation>
-          <xs:documentation>Additional information about a person.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   The augmentation type is derived from structures:AugmentationType and has a name ending in "AugmentationType". The augmentation element uses the type, and has a name ending in "Augmentation". Note that the thing that binds the augmentation type to the augmentation point is the augmentation element's use of the augmentation point element as its substitution group. This means that an augmentation type can be reused for multiple types, by creating more augmentation elements that have that type, each with its own substitution group for a different augmentation point.
-
-   In addition to defining elements that use an augmentation type, a schema document may define an element that substitutes for an augmentation point element, but does not use an augmentation type. For example, the CBRN namespace defines an augmentation to nc:ScheduleType:
-
-   Figure 10-12: An augmentation that is not an augmentation type
-
-                  substitutionGroup="nc:ScheduleAugmentationPoint">
-        <xs:annotation>
-          <xs:documentation>A schedule providing the beginning and ending hours of operation by weekday, for a designated time period.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   The type of this element is not an augmentation type. Instead, it is its own object, not meant to just add to another type:
-
-   Figure 10-13: A type used for an augmentation
-
-      <xs:complexType name="OperatingScheduleType">
-        <xs:annotation>
-          <xs:documentation>A data type for a schedule providing the beginning and ending hours of operation by weekday, for a designated time period.</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="structures:ObjectType">
-            <xs:sequence>
-              <xs:element ref="cbrn:ScheduleStartDateTime" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="cbrn:ScheduleEndDateTime" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="cbrn:OperatingScheduleAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-            </xs:sequence>
-          </xs:extension>
-        </xs:complexContent>
-      </xs:complexType>
-
-   This method can be used by an information exchange developer to define individual attributes that can be applied to any augmentable type.
-
-   Note that the augmentation method can introduce an additional element into every [object type] or [association type] in an exchange, which provides opportunity for some rrors errors in schema development. It is important that developers of exchanges not introduce elements substitutable for an augmentation point into complex types multiple ways, as it can introduce XML Schema's Unique Particle Attribution errors. A single complex type should not introduce an element via both element substition substitution and element reference. This constraint is also supported by Rule 11-21, Element or attribute declaration introduced only once into a type.
-
-10.4.1. Augmentable types
-
-   [Definition: augmentable type]
-
-      An augmentable type is [complex type definition] that
-
-         *  is defined by either a [reference schema document] or by an [extension schema document], and
-
-         *  is either
-
-               *  an [association type], or
-
-               *  an [object type] that has complex content and is not an external adapter type.
-
-Rule 10-21. Augmentable type has augmentation point element
-
-   [Rule 10-21] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[
-                             @name[not(ends-with(., 'MetadataType'))
-                                   and not(ends-with(., 'AugmentationType'))]
-                             and empty(@appinfo:externalAdapterTypeIndicator)
-                             and xs:complexContent]">
-          <sch:let name="augmentation-point-qname"
-                   value="QName(nfQName(string(nf:get-target-namespace(.))),
-                                replace(./@name, 'Type$', 'AugmentationPoint'))"/>
-          <sch:assert test="xs:complexContent/xs:extension/xs:sequence/xs:element[
-                              @ref[resolve-QName(., ..) = $augmentation-point-qname]]"
-            >An augmentable type MUST contain an element use of its augmentation point element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-22. Augmentable type has at most one augmentation point element
-
-   [Rule 10-22] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[
-                             @name[not(ends-with(., 'MetadataType'))
-                                   and not(ends-with(., 'AugmentationType'))]
-                             and empty(@appinfo:externalAdapterTypeIndicator)
-                             and xs:complexContent]">
-          <sch:let name="augmentation-point-qname"
-                   value="QName(nfQName(string(nf:get-target-namespace(.))),
-                                replace(./@name, 'Type$', 'AugmentationPoint'))"/>
-          <sch:assert test="count(xs:complexContent/xs:extension/xs:sequence/xs:element[
-                                    @ref[resolve-QName(., ..) = $augmentation-point-qname]]) &lt;= 1"
-            >An augmentable type MUST contain no more than one element use of its augmentation point element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.4.2. Augmentation point element declarations
-
-Rule 10-23. Augmentation point corresponds to augmentable type
-
-   [Rule 10-23] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name[
-                                       matches(., 'AugmentationPoint$')])]">
-          <sch:let name="element-name" value="@name"/>
-          <sch:assert test="exists(
-                              parent::xs:schema/xs:complexType[
-                                @name = replace($element-name, 'AugmentationPoint$', 'Type')
-                                and exists(@name[
-                                        not(ends-with(., 'MetadataType'))
-                                        and not(ends-with(., 'AugmentationType'))])
-                                      and empty(@appinfo:externalAdapterTypeIndicator)
-                                      and exists(child::xs:complexContent)])"
-            >A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the terms [schema document], [element declaration], and [augmentable type].
-
-Rule 10-24. An augmentation point has no type
-
-   [Rule 10-24] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name[
-                                       matches(., 'AugmentationPoint$')])]">
-          <sch:assert test="empty(@type)"
-              >An augmentation point element MUST have no type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Because an augmentation point element has no type, it will be abstract, per Rule 9-37, Untyped element is abstract
-
-Rule 10-25. An augmentation point has no substitution group
-
-   [Rule 10-25] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name[
-                                       matches(., 'AugmentationPoint$')])]">
-          <sch:assert test="empty(@substitutionGroup)"
-              >An augmentation point element MUST have no substitution group.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.4.3. Augmentation point element use
-
-Rule 10-26. Augmentation point element may only be referenced by its type
-
-   [Rule 10-26] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType//xs:element[exists(@ref[
-                             matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
-      
-          <sch:assert test="QName(nfQName(string(nf:get-target-namespace(ancestor::xs:complexType[1]))), ancestor::xs:complexType[1]/@name)
-                            = QName(namespace QName(string(namespace-uri-from-QName(resolve-QName(@ref, .))))), 
-                     replace(local-name-from-QName(resolve-QName(@ref, .)), 'AugmentationPoint$', 'Type'))"
-            >An augmentation point element MUST only be referenced by its corresponding type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-27. Augmentation point reference is optional
-
-   [Rule 10-27] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType//xs:element[exists(@ref[
-                                 matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
-          <sch:assert test="exists(@minOccurs) and xs:integer(@minOccurs) = 0"
-              >An augmentation point element particle MUST have attribute minOccurs equal to 0.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-28. Augmentation point reference is unbounded
-
-   [Rule 10-28] (REF)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType//xs:element[exists(@ref[
-                                 matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
-          <sch:assert test="exists(@maxOccurs) and string(@maxOccurs) = 'unbounded'"
-             >An augmentation point element particle MUST have attribute maxOccurs set to unbounded.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-29. Augmentation point reference must be last particle
-
-   [Rule 10-29] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType//xs:element[exists(@ref[
-                                 matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
-          <sch:assert test="empty(following-sibling::*)"
-             >An augmentation point element particle MUST be the last element occurrence in its content model.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.4.4. Augmentation types
-
-   [Definition: augmentation type]
-
-      An augmentation type is a [complex type definition] that
-
-         1. provides elements that establish relationships to a base object or association, rather than to the instance of the augmentation type itself, and
-
-         2. is designed to be the type of an [augmentation element declaration].
-
-   [Definition: augmentation element declaration]
-
-      An augmentation element declaration is an [element declaration] that
-
-         1. has a type that is an [augmentation type], and
-
-         2. carries elements that establish a relationship to its parent object or association
-
-         3. is designed to be used as an [augmentation] of its parent object or association
-
-Rule 10-30. Element within instance of augmentation type modifies base
-
-   [Rule 10-30] (INS)
-
-      Given:
-
-         1. Some element has a value $base-value.
-
-         2. Value $base-value contains element $augmentation.
-
-         3. Element $augmentation has property [element declaration] with a value that is an [augmentation element declaration].
-
-         4. Element $augmentation has a value, by reference or by content.
-
-         5. The value of $augmentation contains element $relationship.
-
-         6. Element $relationship has a value, by reference or by content.
-
-      Element $relationship establishes a relationship between $base-value and the value of $relationship.
-
-Rule 10-31. Only an augmentation type name ends in "AugmentationType"
-
-   [Rule 10-31] (REF, EXT)
-
-      A [schema component] that has a name that ends in "AugmentationType" MUST be an [augmentation type].
-
-   The primary indicator that a complex type is an [augmentation type] is its name. Using the qualifier Augmentation immediately identifies a type as an augmentation type.
-
-Rule 10-32. Schema component with name ending in "AugmentationType" is an augmentation type
-
-   [Rule 10-32] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[ends-with(@name, 'AugmentationType')]">
-          <sch:assert test="self::xs:complexType/xs:complexContent/xs:*[
-                              (self::xs:extension or self::xs:restriction)
-                              and ends-with(@base, 'AugmentationType')]"
-             >An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The [base type definition] of an augmentation type is required to be from a conformant namespace by Rule 11-3, Base type definition defined by conformant schema.
-
-Rule 10-33. Type derived from augmentation type is an augmentation type
-
-   [Rule 10-33] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[(self::xs:restriction or self::xs:extension)
-                                and ends-with(@base, 'AugmentationType')]">
-          <sch:assert test="ancestor::xs:complexType[ends-with(@name, 'AugmentationType')]"
-                      >A type definition derived from an augmentation type MUST be an augmentation type definition</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.4.5. Augmentation element declarations
-
-Rule 10-34. Augmentation element type is an augmentation type
-
-   [Rule 10-34] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="exists(@type[ends-with(., 'AugmentationType')])
-                            = exists(@name[ends-with(., 'Augmentation')])"
-            >An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Augmentation immediately identifies an element as representing an augmentation.
-
-Rule 10-35. Augmentation elements are not used directly
-
-   [Rule 10-35] (REF, SET)
-
-      Within a [reference schema document], a complex type definition MUST NOT have an element use of
-
-         *  an [augmentation element declaration], or
-
-         *  an element declration declaration that is in the substitution group of an augmentation point element declaration.
-
-10.5. Metadata
-
-   There are rules for use of metdata metadata in instance in Section 12.3, Instance metadata, below.
-
-10.5.1. Metadata types
-
-   Within NIEM, metadata is defined as "data about data." This may include information such as the security of a piece of data or the source of the data. These pieces of metadata may be composed into a metadata type. The types of data to which metadata may be applied may be constrained.
-
-   [Definition: metadata type]
-
-      A metadata type describes data about data, that is, information that is not descriptive of objects and their relationships, but is descriptive of the data itself. It is useful to provide a general mechanism for data about data. This provides required flexibility to precisely represent information.
-
-Rule 10-36. Metadata type has data about data
-
-   [Rule 10-36] (REF, EXT)
-
-      Within the schema, a metadata type MUST contain elements appropriate for a specific class of data about data.
-
-Rule 10-37. Metadata type derived from structures:MetadataType
-
-   [Rule 10-37] (REF, EXT)
-
-      Within the schema, a metadata type and only a metadata type MUST be derived directly from structures:MetadataType.
-
-   A metadata type establishes a specific, named aggregation of data about data. Any type derived from structures:MetadataType is a metadata type. Metadata types should not be derived from other metadata types. Such metadata types should be used asis as is and additional metadata types defined for additional content.
-
-Rule 10-38. Metadata types are derived from metadata types
-
-   [Rule 10-38] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType">
-          <sch:let name="is-metadata-type" value="exists(@name[ends-with(., 'MetadataType')])"/>
-          <sch:let name="has-metadata-base-type" value="
-            exists(xs:complexContent[
-              exists(xs:*[local-name() = ('extension', 'restriction')
-                          and exists(@base[ends-with(., 'MetadataType')])])])"/>
-          <sch:assert test="$is-metadata-type = $has-metadata-base-type"
-            >A type MUST have a metadata type name if an only if it is derived from a metadata type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Metadata immediately identifies a type as representing metadata.
-
-10.5.2. Metadata element declarations
-
-   [Definition: metadata element declaration]
-
-      A metadata element declaration is an element declaration defined by a [reference schema document] or an [extension schema document] that defines a metadata object. A metadata element declaration has a name ending in "Metadata", and a {type definition} that is a [metadata type].
-
-    There are limitations on the meaning of a metadata element in an instance; it does not establish existence of an object, nor is it a property of its containing object.
-
-Rule 10-39. Metadata element declaration type is a metadata type
-
-   [Rule 10-39] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="exists(@type[ends-with(., 'MetadataType')])
-                            = exists(@name[ends-with(., 'Metadata')])"
-            >An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Metadata immediately identifies an element as representing metadata. This document defines the term [metadata type].
-
-Rule 10-40. Metadata element has applicable elements
-
-   Each metadata element declaration may be applied to a set of elements. Any element to which a metadata element may be validly applied is called an "applicable element" for the metadata element.
-
-   [Rule 10-40] (REF, EXT, SET)
-
-      The set of applicable elements for a metadata element declaration are as follows:
-
-         *  A metadata element declaration that has neither an attribute appinfo:appliesToTypes nor an attribute appinfo:appliesToElements may be applied to any element.
-
-         *  A metadata element declaration that has either an attribute appinfo:appliesToTypes or an attribute appinfo:appliesToElements may be applied to
-
-               *  any element whose qualified name is in the value of appinfo:appliesToElements, or any element with a declaration that is in the substitution group of the declaration of such an element, and to
-
-               *  any element with a type with a qualified name that is in the value of appinfo:appliesToTypes, or any element with a type that is validly derived from such a type.
-
-10.6. Container elements
-
-   All NIEM properties establish a relationship between the object holding the property and the value of the property. For example, an activity object of type nc:ActivityType may have an element nc:ActivityDescriptionText. This element will be of type nc:TextType and represents a NIEM property owned by that activity object. An occurrence of this element within an activity object establishes a relationship between the activity object and the text: the text is the description of the activity.
-
-   In a NIEM-conformant instance, an element establishes a relationship between the object that contains it and the element's value. This relationship between the object and the element may be semantically strong, such as the text description of an activity in the previous example, or it may be semantically weak, with its exact meaning left unstated. In NIEM, the contained element involved in a weakly defined semantic relationship is commonly referred to as a container element.
-
-   A container element establishes a weakly defined relationship with its containing element. For example, an object of type nc:ItemDispositionType may have a container element nc:Item of type nc:ItemType. The container element nc:Item does not establish what relationship exists between the object of nc:ItemDispositionType and itself. There could be any of a number of possible semantics between an object and the value of a container element. It could be a contained object, a subpart, a characteristic, or some other relationship. The appearance of this container element inside the nc:ItemDispositionType merely establishes that the disposition has an item.
-
-   The name of the container element is usually based on the NIEM type that defines it: nc:PersonType uses a container element nc:Person, while nc:ActivityType uses a container element nc:Activity. The concept of an element as a container element is a notional one.
-
-   There are no formalized rules addressing what makes up a container element. A container element is vaguely defined and carries very little semantics about its context and its contents. Accordingly, there is no formal definition of container elements in NIEM: There are no specific artifacts that define a container element; there are no appinfo or other labels for container elements.
-
-   The appearance of a container element within a NIEM type carries no additional semantics about the relationship between the property and the containing type. The use of container elements indicates only that there is a relationship; it does not provide any semantics for interpreting that relationship.
-
-   For example, a NIEM container element nc:Person would be associated with the NIEM type nc:PersonType. The use of the NIEM container element nc:Person in a containing NIEM type indicates that a person has some association with the instances of the containing NIEM type. But because the nc:Person container element is used, there is no additional meaning about the association of the person and the instance containing it. While there is a person associated with the instance, nothing is known about the relationship except its existence.
-
-   The use of the Person container element is in contrast to a NIEM property named nc:AssessmentPerson, also of NIEM type nc:PersonType. When the NIEM property nc:AssessmentPerson is contained within an instance of a NIEM type, it is clear that the person referenced by this property was responsible for an assessment of some type, relevant to the exchange being modeled. The more descriptive name, nc:AssessmentPerson, gives more information about the relationship of the person with the containing instance, as compared with the semantic-free implications associated with the use of the nc:Person container element.
-
-   When a NIEM-conformant schema requires a new container element, it may define a new element with a concrete type and a general name, with general semantics. Any schema may define a container element when it requires one.
-
-10.7. The "Representation" pattern
-
-   One need frequently faced by schema developers is for multiple representations for a single concept. For example, for a general concept of a point in time, there are numerous base representations, and innumerable ways to combine them. For example, the [XML Schema definition language] defines the types xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth, each representing a point in time, or perhaps a span of time. There is a need in XML Schema to be able to represent a general concept like a point in time, along with a variety of representations for the concept.
-
-   Note that this need is a bit different than specialization of relationships (e.g., rdfs:subPropertyOf), in that it specifically is to be used to describe and carry the variety of representations for a particular concept. The need is to be able to represent an abstract point in time using a single type, and then to add a set of specific representations for that basic concept.
-
-   There are a variety of methods that could be used to satisfy this need. A method could be devised that uses an abstract type, along with a set of concrete extensions of that abstract type. However, there would still be a need for a set of concrete elements to carry the types, as type substitution (distinct from element substition) substitution) is not widely adopted across the NIEM community. As well, it is difficult to create a network of complex types with complex content and complex types with simple content that all substitute for a base type; the XML Schema syntax is complicated. Other alternatives each have their pros and cons.
-
-   To handle this need, NIEM has adopted the "Representation" pattern, in which a type has contains a representation element, and the various representations for that type are in the substitution group for that representation element.
-
-   For example, the definition of nc:DateType uses this pattern:
-
-   Figure 10-14: A type definition that uses the "Representation" pattern
-
-      <xs:complexType name="DateType">
-        <xs:annotation>
-          <xs:documentation>A data type for a calendar date.</xs:documentation>
-        </xs:annotation>
-        <xs:complexContent>
-          <xs:extension base="structures:ObjectType">
-            <xs:sequence>
-              <xs:element ref="nc:DateRepresentation" minOccurs="0" maxOccurs="unbounded"/>
-              <xs:element ref="nc:DateAccuracy" minOccurs="0" maxOccurs="1"/>
-              <xs:element ref="nc:DateMarginOfErrorDuration" minOccurs="0" maxOccurs="1"/>
-              <xs:element ref="nc:DateAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-            </xs:sequence>
-          </xs:extension>
-        </xs:complexContent>
-      </xs:complexType>
-
-   The type has elements that represent accuracy and margin of error, as well as an augmentation point. The actual date value, however, is carried by an element that substitutes for nc:DateRepresentation. That base element, and several substitutions are defined by the NIEM Core namespace:
-
-   Figure 10-15: Element declarations that implement representations
-
-      <xs:element name="DateRepresentation" abstract="true">
-        <xs:annotation>
-          <xs:documentation>A data concept for a representation of a date.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-      
-      <xs:element name="Date" type="niem-xs:date" substitutionGroup="nc:DateRepresentation" nillable="true">
-        <xs:annotation>
-          <xs:documentation>A full date.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-      
-      <xs:element name="DateTime" type="niem-xs:dateTime" substitutionGroup="nc:DateRepresentation">
-        <xs:annotation>
-          <xs:documentation>A full date and time.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-      
-      <xs:element name="YearDate" type="niem-xs:gYear" substitutionGroup="nc:DateRepresentation">
-        <xs:annotation>
-          <xs:documentation>A year.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-      
-      <xs:element name="YearMonthDate" type="niem-xs:gYearMonth" substitutionGroup="nc:DateRepresentation">
-        <xs:annotation>
-          <xs:documentation>A year and month.</xs:documentation>
-        </xs:annotation>
-      </xs:element>
-
-   This method has several benefits:
-
-      *  Its implementation requires a minimum number of additional schema components. There is only the one abstract representation element; all other elements are concrete and needed to carry strongly typed values.
-
-      *  It is simple to implement. The method requires only elements, and the definition of each element is quite simple.
-
-      *  It is straightforward to use, as its implementation is based on element substitution, which is already widely used by NIEM.
-
-      *  It is highly extensible. Any domain or exchange specification may define additional representations for any concept, by defining new elements substitutable for the representation element.
-
-Rule 10-41. Name of element that ends in "Representation" is abstract
-
-   [Rule 10-41] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name[ends-with(., 'Representation')]]">
-          <sch:report test="empty(@abstract) or xs:boolean(@abstract) = false()"
-            >An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true".</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-   [Definition: representation element declaration]
-
-      A representation element declaration is an [element declaration] that is abstract, and that has a {name} that ends in "Representation".
-
-Rule 10-42. A substitution for a representation element declaration is a value for a type
-
-   [Rule 10-42] (REF, EXT)
-
-      Any element declaration that is substitutable for a a representation element declaration represents an optional representation of a value of a type that carries the representation element.
-
-10.8. Naming rules
-
-   This section outlines the rules used to create names for NIEM data components previously discussed in this document. Data component names must be understood easily both by humans and by machine processes. These rules improve name consistency by restricting characters, terms, and syntax that could otherwise allow too much variety and potential ambiguity. These rules also improve readability of names for humans, facilitate parsing of individual terms that compose names, and support various automated tasks associated with dictionary and controlled vocabulary maintenance.
-
-Rule 10-43. Schema component name composed of English words
-
-   [Rule 10-43] (REF, EXT)
-
-      The name of any XML Schema component defined by the schema MUST be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED].
-
-   The English language has many spelling variations for the same word. For example, American English "program" has a corresponding British spelling "programme." This variation has the potential to cause interoperability problems when XML components are exchanged because of the different names used by the same elements. Providing users with a dictionary standard for spelling will mitigate this potential interoperability issue.
-
-Rule 10-44. Schema component names have only specific characters
-
-   [Rule 10-44] (REF, EXT)
-
-      The name of any XML Schema component defined by the schema MUST contain only the following characters:
-
-         *  Upper-case letters ("A"-"Z").
-
-         *  Lower-case letters ("a"-"z").
-
-         *  Digits ("0"-"9").
-
-         *  Hyphen ("-").
-
-      Other characters, such as the underscore ("_") character and the period (".") character MUST NOT appear in component names in NIEM-conformant schemas.
-
-Rule 10-45. Hyphen in component name is a separator
-
-   [Rule 10-45] (REF, EXT)
-
-      The hyphen character ("-") MAY appear in component names only when used as a separator between parts of a single word, phrase, or value, which would otherwise be incomprehensible without the use of a separator.
-
-   Names of standards and specifications, in particular, tend to consist of series of discrete numbers. Such names require some explicit separator to keep the values from running together. The separator used within NIEM is the hyphen.
-
-   Names of NIEM components follow the rules of XML Schema, by Rule 7-3, Document is a schema document. NIEM components also follow the rules specified herein for each type of XML Schema component.
-
-10.8.1. Character case
-
-   Names of conformant components use camel case formatting. Camel case is the convention of writing compound words or phrases with no spaces and an initial lowercase or uppercase letter, with each remaining word element beginning with an uppercase letter. UpperCamelCase is written with an initial uppercase letter, and lowerCamelCase is written with an initial lowercase letter.
-
-Rule 10-46. Names use camel case
-
-   [Rule 10-46] (REF, EXT)
-
-      The name of any XML Schema component defined by the schema MUST use the camel case formatting convention.
-
-Rule 10-47. Attribute name begins with lower case letter
-
-   [Rule 10-47] (REF, EXT)
-
-      Within the schema, any attribute declaration MUST have a name that begins with a lower-case letter ("a"-"z").
-
-Rule 10-48. Name of schema component other than attribute begins with upper case letter
-
-   [Rule 10-48] (REF, EXT)
-
-      Within the schema, any XML Schema component other than an attribute declaration MUST have a name that begins with an upper-case letter ("A"-"Z").
-
-   The foregoing rules establish lowerCamelCase for all NIEM components that are XML attributes and UpperCamelCase for all NIEM components that are types, elements, or groups.
-
-10.8.2. Use of acronyms and abbreviations
-
-   Acronyms and abbreviations have the ability to improve readability and comprehensibility of large, complex, or frequently used terms. They also obscure meaning and impair understanding when their definitions are not clear or when they are used injudiciously. They should be used with great care. Acronyms and abbreviations that are used must be documented and used consistently.
-
-Rule 10-49. Names use common abbreviations
-
-   [Rule 10-49] (REF, EXT)
-
-      The schema MUST use, in defined names, the abbreviations identified by Table Table 10-1, Abbreviations used in schema component names, rather than their full meanings.
-
-   Table 10-1: Abbreviations used in schema component names
-
-      Abbreviation|Full Meaning
-
-      ID|Identifier
-
-      URI|Uniform Resource Identifier
-
-   Consistent, controlled, and documented abridged terms that are used frequently and/or tend to be lengthy can support readability, clarity, and reduction of name length.
-
-10.8.2.1. Use of Acronyms, Initialisms, Abbreviations, and Jargon
-
-   The NDR establishes appinfo for local terminology that introduces such terms into the schema document in which the appinfo appears.
-
-   [Definition: local term]
-
-      In a conformant schema document, a local term is a word, phrase, acronym, or other string of characters for which all of the following are true:
-
-         1. It is not a term defined in the [OED], or it has a non-OED definition, or its word sense may not be clear.
-
-         2. It is introduced into the schema document via an appinfo element with a [namespace name] of the [local terminology appinfo namespace]:LocalTerm.
-
-         3. It is used in the local name of a schema component within the schema document.
-
-   [Definition: local terminology appinfo namespace]
-
-      The local terminology appinfo namespace is the XML Schema namespace represented by the URI http://release.niem.gov/niem/localTerminology/3.0/.
-
-   Local terminology is introduced into a schema document by the application use of local terminology appinfo:LocalTerm within the schema.
-
-   See additional rules constraining the use of the [local terminology appinfo namespace] in Section 10.9.2, The NIEM local Local terminology namespace, below.
-
-Rule 10-50. Local term declaration is local to its schema document
-
-   [Rule 10-50] (REF, EXT)
-
-      An element term appinfo:LocalTerm MUST establish the meaning of a [local term] only within the XML Schema document in which it occurs. There MUST NOT be any transitive inheritance of local terminology within schema documents that import the containing schema document.
-
-Rule 10-51. Local terminology interpretation
-
-   [Rule 10-51] (REF, EXT)
-
-      An element information item term appinfo:LocalTerm MUST establish a term as follows:
-
-         1. The value of the attribute term is the [local term]; it may occur as a term within the name of a schema component within the schema document.
-
-         2. The value of the attribute literal is the meaning of the local term, provided as a full, plain-text form of the term. This may be useful when a local term is an abbreviation, acronym, or diminutive form of a longer term.
-
-         3. The value of the attribute definition is a dictionary-style description of the meaning of the local term.
-
-         4. The value of the attribute sourceURIs is a list of URIs, each of which is an identifier or locator for an originating or authoritative document defining the term.
-
-         5. Each child element information item term appinfo:SourceText is a plain text citation of, reference to, or bibliographic entry for an originating or authoritative document defining the term.
-
-10.8.3. Word forms
-
-Rule 10-52. Singular form is preferred in name
-
-   [Rule 10-52] (REF, EXT)
-
-      A noun used as a term in the name of an XML Schema component MUST be in singular form unless the concept itself is plural.
-
-Rule 10-53. Present tense is preferred in name
-
-   [Rule 10-53] (REF, EXT)
-
-      A verb used as a term in the name of an XML Schema component MUST be used in the present tense unless the concept itself is past tense.
-
-Rule 10-54. Name does not have nonessential words
-
-   [Rule 10-54] (REF, EXT)
-
-      Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.
-
-   Articles (e.g., a, an, the), conjunctions (e.g., and, or, but), and prepositions (e.g., at, by, for, from, in, of, to) are all disallowed in NIEM component names, unless they are required. For example, PowerOfAttorneyCode requires the preposition. These rules constrain slight variations in word forms and types to improve consistency and reduce potentially ambiguous or confusing component names.
-
-Rule 10-55. Component name follows pattern
-
-   Elements in NIEM-conformant schemas are given names that follow a specific pattern. This pattern comes from [ISO 11179-5].
-
-   [Rule 10-55] (REF, EXT)
-
-      Except as specified elsewhere in this document, any element or attribute defined within the schema MUST have a name that takes the form:
-
-         *  Object-class qualifier terms (0 or more).
-
-         *  An object class term (1).
-
-         *  Property qualifier terms (0 or more).
-
-         *  A property term (1).
-
-         *  Representation qualifier terms (0 or more).
-
-         *  A representation term (0 or 1).
-
-   Consistent naming rules are helpful for users who wish to understand components with which they are unfamiliar, as well as for users to find components with known semantics. This rule establishes the basic structure for an element or attribute name, in line with the rules for names under [ISO 11179-5]. Note that many elements with complex type should not have a representation term.
-
-10.8.4. Object-class term
-
-   NIEM adopts an object-oriented approach to representation of data. Object classes represent what [ISO 11179-5] refers to as "things of interest in a universe of discourse that may be found in a model of that universe." An object class or object term is a word that represents a class of real-world entities or concepts. An object-class term describes the applicable context for a NIEM component.
-
-Rule 10-56. Object-class term identifies concrete category
-
-   [Rule 10-56] (REF, EXT)
-
-      The object-class term of a NIEM component MUST consist of a term identifying a category of concrete concepts or entities.
-
-   The object-class term indicates the object category that this data component describes or represents. This term provides valuable context and narrows the scope of the component to an actual class of things or concepts.
-
-   Example:
-
-      Concept term: Activity
-
-      Entity term: Vehicle
-
-10.8.5. Property term
-
-   Objects or concepts are usually described in terms of their characteristic properties, data attributes, or constituent subparts. Most objects can be described by several characteristics. Therefore, a property term in the name of a data component represents a characteristic or subpartof subpart of an object class and generally describes the essence of that data component.
-
-Rule 10-57. Property term describes characteristic or subpart
-
-   [Rule 10-57] (REF, EXT)
-
-      A property term MUST describe or represent a characteristic or subpart of an entity or concept.
-
-   The property term describes the central meaning of the data component.
-
-10.8.6. Qualifier terms
-
-   Qualifier terms modify object, property, representation, or other qualifier terms to increase semantic precision and reduce ambiguity. Qualifier terms may precede or succeed the terms they modify. The goal for the placement of qualifier terms is to generally follow the rules of ordinary English while maintaining clarity.
-
-Rule 10-58. Name may have multiple qualifier terms
-
-   [Rule 10-58] (REF, EXT)
-
-      Multiple qualifier terms MAY be used within a component name as necessary to ensure clarity and uniqueness within its namespace and usage context.
-
-Rule 10-59. Name has minimum necessary number of qualifier terms
-
-   [Rule 10-59] (REF, EXT)
-
-      The number of qualifier terms SHOULD be limited to the absolute minimum required to make the component name unique and understandable.
-
-Rule 10-60. Order of qualifies is not significant
-
-   [Rule 10-60] (REF, EXT)
-
-      The order of qualifiers MUST NOT be used to differentiate names.
-
-   Very large vocabularies may have many similar and closely related properties and concepts. The use of object, property, and representation terms alone is often not sufficient to construct meaningful names that can uniquely distinguish such components. Qualifier terms provide additional context to resolve these subtleties. However, swapping the order of qualifiers rarely (if ever) changes meaning; qualifier ordering is no substitute for meaningful terms.
-
-10.8.7. Representation terms
-
-   The representation terms for a component name serve several purposes in NIEM:
-
-      1. It can indicate the style of component. For example, types are clearly labeled with the representation term Type.
-
-      2. It helps prevent name conflicts and confusion. For example, elements and types may not be given the same name.
-
-      3. It indicates the nature of the value carried by element. Labeling elements and attributes with a notional indicator of the content eases discovery and comprehension.
-
-Rule 10-61. Redundant term in name is omitted
-
-   [Rule 10-61] (REF, EXT)
-
-      If any word in the representation term is redundant with any word in the property term, one occurrence SHOULD be deleted.
-
-   This rule, carried over from 11179, is designed to prevent repeating terms unnecessarily within component names. For example, this rule allows designers to avoid naming an element "PersonFirstNameName."
-
-   The valid value set of a data element or value domain is described by the representation term. NIEM uses a standard set of representation terms in the representation portion of a NIEM-conformant component name. Table Table 10-2, Representation terms, below, lists the primary representation terms and a definition for the concept associated with the use of that term. The table also lists secondary representation terms that may represent more specific uses of the concept associated with the primary representation term.
-
-   Table 10-2: Representation terms
-
-      Primary Representation Term|Secondary Representation Term|Definition
-
-      Amount|-|A number of monetary units specified in a currency where the unit of currency is explicit or implied.
-
-      BinaryObject|-|A set of finite-length sequences of binary octets.
-
-      |Graphic|A diagram, graph, mathematical curves, or similar representation
-
-      |Picture|A visual representation of a person, object, or scene
-
-      |Sound|A representation for audio
-
-      |Video|A motion picture representation; may include audio encoded within
-
-      Code||A character string (i.e., letters, figures, and symbols) that for brevity, language independence, or precision represents a definitive value of an attribute.
-
-      DateTime||A particular point in the progression of time together with relevant supplementary information.
-
-      |Date|A particular day, month, and year in the Gregorian calendar.
-
-      |Time|A particular point in the progression of time within an unspecified 24-hour day.
-
-      |Duration|An amount of time; the length of a time span.
-
-      ID||A character string to identify and distinguish uniquely one instance of an object in an identification scheme from all other objects in the same scheme together with relevant supplementary information.
-
-      |URI|A string of characters used to identify (or name) a resource. The main purpose of this identifier is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. A URI is either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The specific syntax for each is defined by [RFC 3986].
-
-      Indicator||A list of two mutually exclusive Boolean values that express the only possible states of a property.
-
-      Measure||A numeric value determined by measuring an object along with the specified unit of measure.
-
-      Numeric||Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure.
-
-      |Value|A result of a calculation.
-
-      |Rate|A representation of a ratio where the two units are not included.
-
-      |Percent|A representation of a ratio in which the two units are the same.
-
-      Quantity||A counted number of nonmonetary units possibly including fractions.
-
-      Text|-|A character string (i.e., a finite sequence of characters) generally in the form of words of a language.
-
-      |Name|A word or phrase that constitutes the distinctive designation of a person, place, thing, or concept.
-
-      |List|A List||A sequence of values. This representation term is used in tandem with another of the listed representation terms.
-
-      Abstract||An element that may represent a concept, rather than a concrete property. This representation term may be used in tandem with another of the listed representation terms.
-
-Rule 10-62. Element with simple content has representation term
-
-   [Rule 10-62] (REF, EXT)
-
-      Within the schema, the name of an element declaration that is of simple content MUST use an appropriate representation term as found in Table Table 10-2, Representation terms.
-
-   This rule is also supported by Rule 11-16, Name of element declaration with simple content has representation term and Rule 11-17, Name of element declaration with simple content has representation term, which provide tests that a top-level declaration has a representation term.
-
-Rule 10-63. Name has representation term when appropriate
-
-   [Rule 10-63] (REF, EXT)
-
-      Within the schema, the name of an element declaration that is of complex content, and that corresponds to a concept listed in Table Table 10-2, Representation terms, MUST use a representation term from that table.
-
-   An element that represents a value listed in the table should have a representation term. It should do so even if its type is complex with multiple parts. For example, a type with multiple fields may represent an audio binary, a date, or a name.
-
-Rule 10-64. Name has representation term only when appropriate
-
-   [Rule 10-64] (REF, EXT)
-
-      Within the schema, the name of an element declaration that is of complex content and that does not correspond to a concept listed in Table Table 10-2, Representation terms MUST NOT use a representation term.
-
-10.9. Machine-readable annotations
-
-   XML Schema provides application information schema components to provide for automatic processing and machine-readable content for schemas, as described by [XML Schema Structures] Section 3.13.2, XML Representation of Annotation Schema Components. NIEM utilizes application information to convey information that is outside schema definition and outside human-readable text definitions. NIEM uses application information to convey high-level data model concepts and additional syntax to support the NIEM conceptual model and validation of NIEM-conformant XML instances.
-
-   XML elements, attributes, and text content may appear as machine-readable annotations within an XML Schema document. The methods provided by XML Schema for machine-readable annotations are:
-
-      1. An element in the XML Schema namespace (e.g., xs:schema, xs:complexType, ...) may carry attributes from namespaces other than the XML Schema namespace. By the rules of XML Schema, any XML Schema element may have attributes that are from other namespaces. These attributes do not participate in XML Schema validation, but may carry information useful to tools that process schemas. In [XML Schema Structures], these attributes are described in the XML Representation summary of XML Schema elements as "{any attributes with non-schema namespace . . .}", for example in Section 3.2.2, XML Representation of Attribute Declaration Schema Components.
-
-      2. XML Schemas may include xs:appinfo elements, which may include arbitrary XML content. This XML does not participate in XML Schema validation, but may communicate useful information to schema readers or processors. These are described by [XML Schema Structures] in Section 3.13.1, The Annotation Schema Component and Section 3.13.2, XML Representation of Annotation Schema Components.
-
-   This document defines the term [machine-readable annotation] to normatively refer to such annotations within XML Schema documents:
-
-   [Definition: machine-readable annotation]
-
-      An information item within a schema is defined to be a machine-readable annotation when all of the following are true:
-
-         1. It is one of the following:
-
-               1. It is an element information item that is a child of an xs:appinfo element.
-
-               2. It is an attribute information item that satisfies the "{any attributes with non- schema namespace . . .}" clause within the declaration of an XML Schema element.
-
-         2. The namespace name property of the item is not the XML namespace, XML Schema namespace, or the XSI namespace.
-
-   Attributes from the XML namespace, the XML Schema namespace, and the XML Schema instance namespace have special meanings within XML Schema, and may have effects on validation, and so are not considered machine-readable annotations.
-
-   [Definition: application information]
-
-      A component is said to have application information of some element $element when the XML Schema element that defines the component has an immediate child element xs:annotation, which has an immediate child element xs:appinfo, which has as an immediate child the element $element.
-
-   If a component is described as having some [application information], this means that the elements in question appear in an xs:appinfo annotation of the element that defines the component.
-
-   The majority of uses of [application information] from the [appinfo namespace] are described in the modeling rules for the specific component.
-
-Rule 10-65. Machine-readable annotations are valid
-
-   [Rule 10-65] (REF, EXT)
-
-      Every element information item or attribute information item that appears as a machine-readable annotation in a schema MUST be a valid instance, according to its specification.
-
-   The specification for an element or attribute may be via an XML Schema, a Schematron schema, via a DTD, by some other specification, or by other means. This rule is intended to allow NIEM schema developers to leverage relevant vocabularies without being limited by the vocabulary's method of specification, while ensuring that developers do not subvert or misuse those vocabularies.
-
-10.9.1. The NIEM appinfo namespace
-
-   NIEM defines a single namespace that holds components for use in NIEM-conformant schema application information. This namespace is referred to as the [appinfo namespace].
-
-   [Definition: appinfo namespace]
-
-      The appinfo namespace is the namespace represented by the URI "http://release.niem.gov/niem/appinfo/34.0/".
-
-   The [appinfo namespace] defines attributes which provide additional semantics for components built by NIEM-conformant schemas. The XML Schema document for the appinfo namespace appears in Appendix C, Appinfo namespace, below.
-
-10.9.1.1. Deprecation
-
-   The appinfo schema provides a construct for indicating that a construct is deprecated. A deprecated component is one whose use is not recommended. A deprecated component may be kept in a schema for support of older versions but should not be used in new efforts. A deprecated component may be removed, replaced, or renamed in a later version of a namespace.
-
-   [Definition: deprecated component]
-
-      A deprecated component is one that developers are discouraged from using, typically because a better alternative exists, yet which is maintained in the schema for compatibility with previous versions of the namespace.
-
-   The definition for [deprecated component] is adapted from [JLS] Section 9.6.4.6, @Deprecated.
-
-Rule 10-66. Component marked as deprecated is deprecated component
-
-   [Rule 10-66] (REF, EXT)
-
-      A [schema component] that has an attribute appinfo:deprecated with a value of "true" MUST be a [deprecated component].
-
-   Deprecation can allow version management to be more consistent; versions of schema may be incrementally improved without introducing validation problems and incompatibility. As XML Schema lacks a deprecation mechanism, NIEM defines such a mechanism.
-
-Rule 10-67. Deprecated annotates schema component
-
-   [Rule 10-67] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:deprecated)]">
-          <sch:assert test="namespace-uri-from-QName(node-name(.)) = xs:anyURI('http://www.w3.org/2001/XMLSchema')"
-                  >The attribute appinfo:deprecated MUST be owned by an element with a namespace name <namespace-uri-for-prefix>xs</namespace-uri-for-prefix>.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-68. External import indicator annotates import
-
-   [Rule 10-68] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:externalImportIndicator)]">
-          <sch:assert test="exists(self::xs:import)"
-              >The attribute {http://release.niem.gov/niem/appinfo/34.0/}externalImportIndicator MUST be owned by an element xs:import.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-69. External adapter type indicator annotates complex type
-
-   [Rule 10-69] (REF)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:externalAdapterTypeIndicator)]">
-          <sch:assert test="exists(self::xs:complexType)"
-                  >The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.9.1.2. appinfo:appliesToTypes annotation
-
-Rule 10-70. appinfo:appliesToTypes annotates metadata element
-
-   [Rule 10-70] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:appliesToTypes)]">
-          <sch:assert test="exists(self::xs:element[exists(@name)
-                                     and ends-with(@name, 'Metadata')])"
-            >The attribute appinfo:appliesToTypes MUST be owned by a metadata element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-71. appinfo:appliesToTypes references types
-
-   [Rule 10-71] (SET)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:appliesToTypes)]">
-          <sch:assert test="every $item in tokenize(normalize-space(@appinfo:appliesToTypes), ' ') satisfies
-                              exists(nf:resolve-type(., resolve-QName($item, .)))"
-            >Every item in @appinfo:appliesToTypes MUST resolve to a type.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.9.1.3. appinfo:appliesToElements annotation
-
-Rule 10-72. appinfo:appliesToElements annotates metadata element
-
-   [Rule 10-72] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:appliesToElements)]">
-          <sch:assert test="exists(self::xs:element[
-                                exists(@name)
-                                and ends-with(@name, 'Metadata')])"
-                  >The attribute appinfo:appliesToElements MUST be owned by a metadata element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 10-73. appinfo:appliesToElements references elements
-
-   [Rule 10-73] (SET)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@appinfo:appliesToElements)]">
-          <sch:assert test="every $item in tokenize(normalize-space(@appinfo:appliesToElements), ' ') satisfies
-                              count(nf:resolve-element(., resolve-QName($item, .))) = 1"
-            >Every item in @appinfo:appliesToElements MUST resolve to an element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.9.2. The NIEM local Local terminology namespace
-
-Rule 10-74. term appinfo:LocalTerm annotates schema
-
-   [Rule 10-74] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="termappinfo:LocalTerm">
-          <sch:assert test="parent::xs:appinfo[parent::xs:annotation[parent::xs:schema]]"
-            >The element term appinfo:LocalTerm MUST be application information an on an element xs:schema.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [application information].
-
-Rule 10-75. term appinfo:LocalTerm has literal or definition
-
-   [Rule 10-75] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="termappinfo:LocalTerm">
-          <sch:assert test="exists(@literal) or exists(@definition)"
-                  >The element {http://release.niem.gov/niem/localTerminologyappinfo/34.0/}LocalTerm MUST have a literal or definition.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-10.10. NIEM structural facilities
-
-   NIEM provides the structures schema that contains base types for types defined in NIEM- conformant schemas. It provides base elements to act as heads for substitution groups. It also provides attributes that provide facilities not otherwise provided by XML Schema. These structures should be used to augment XML data. The structures provided are not meant to replace fundamental XML organization methods; they are intended to assist them.
-
-   [Definition: structures namespace]
-
-      The structures namespace is the namespace represented by the URI "http://release.niem.gov/niem/structures/34.0/".
-
-   The structures namespace is a single namespace, separate from namespaces that define NIEM-conformant data. This document refers to this content via the prefix structures.
-
-Rule 10-76. Use structures as specified
-
-   [Rule 10-76] (REF, EXT, INS)
-
-      The schema or instance MUST use content within the NIEM structures namespace as specified in this document and ONLY as specified by this document.
-
-   This rule further enforces uniformity and consistency by mandating use of the NIEM structures namespace as is, without modification. Users are not allowed to insert types, attributes, etc. that are not specified by this document.
-
-11. Rules for NIEM modeling, by XML Schema component
-
-   This section focuses on building NIEM data models using XML schema. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.
-
-11.1. Type definition components
-
-Rule 11-1. Name of type ends in "Type"
-
-   [Rule 11-1] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[some $name in @name,
-                                          $extension in xs:simpleContent/xs:extension,
-                                          $base-qname in resolve-QName($extension/@base, $extension) satisfies
-                                          $base-qname = QName('http://www.w3.org/2001/XMLSchema', @name) $name)]">
-          <sch:report test="false()">The name of a proxy type does not end in "Type".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:*[(self::xs:simpleType or self::xs:complexType) and exists(@name)]">
-          <sch:assert test="ends-with(@name, 'Type')"
-            >A type definition schema component that does not define a proxy type MUST have a name that ends in "Type".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Use of the representation term "Type" immediately identifies XML types in a NIEM-conformant schema and prevents naming collisions with corresponding XML elements and attributes. The exception for proxy types ensures that simple NIEM-compatible uses of base XML Schema types are familiar to people with XML Schema experience.
-
-   Note that the first sch:rule and subsequent sch:report serve to provide an exception to the rule for proxy types. It does not establish a constraint on the data.
-
-Rule 11-2. Name of type other than proxy type is in upper camel case
-
-   [Rule 11-2] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[some $name in @name,
-                                          $extension in xs:simpleContent/xs:extension,
-                                          $base-qname in resolve-QName($extension/@base, $extension) satisfies
-                                          $base-qname = QName('http://www.w3.org/2001/XMLSchema', @name) $name)]">
-          <sch:report test="false()">The name of a proxy type is not upper camel case.</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:*[(self::xs:simpleType or self::xs:complexType) and exists(@name)]">
-          <sch:assert test="matches(@name, '^([A-Z][A-Za-z0-9\-]*)+$')"
-            >A type definition schema component that does not define a proxy type MUST be in upper camel case.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that the first sch:rule and q subsequent sch:report (with @test-="false()") serve to provide an exception to this rule for proxy types. It does not establish a constraint on the data.
-
-11.1.1. Type definition hierarchy
-
-Rule 11-3. Base type definition defined by conformant schema
-
-   [Rule 11-3] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:*[exists(@base)]">
-          <sch:assert test="some $base-namespace in namespace-uri-from-QName(resolve-QName(@base, .)) satisfies (
-                              $base-namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
-                              or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                                                         and $base-namespace = xs:anyURI(@namespace)
-                                                                         and empty(@appinfo:externalImportIndicator)]))"
-            >The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.1.2. Simple type definition
-
-Rule 11-4. Name of simple type ends in "SimpleType"
-
-   [Rule 11-4] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType[@name]">
-          <sch:assert test="ends-with(@name, 'SimpleType')"
-            >A simple type definition schema component MUST have a name that ends in "SimpleType".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Specific uses of type definitions have similar syntax but very different effects on data definitions. Schemas that clearly identify complex and simple type definitions are easier to understand without tool support. This rule ensures that names of simple types end in SimpleType.
-
-Rule 11-5. Name of simple type is upper camel case
-
-   [Rule 11-5] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType[exists(@name)]">
-          <sch:assert test="matches(string(@name), '^([A-Z][A-Za-z0-9\-]*)+$')"
-            >The name of a simple type definition schema component MUST be upper camel case.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.1.2.1. Derivation by list
-
-Rule 11-6. Use lists only when data is uniform
-
-   [Rule 11-6] (REF, EXT)
-
-      Within the schema, a simple type definition that uses xs:list SHOULD NOT be defined if any member of the list requires a property or metadata that is different than other members of the list. All members of the list SHOULD have the same metadata, and should be related via the same properties.
-
-   The use of lists should be reserved for cases where the data is fairly uniform.
-
-   Items in a list are not individually addressable by NIEM metadata techniques. The items are also not individually referencable by elements or attributes; one will have a value of the entire list, including all the items in the list. NIEM provides no method for individually addressing an item in a list. If an individual item in a list needs to be marked up in a manner different than other items in the list, the use of individual elements may be preferred to the definition of a list simple type.
-
-Rule 11-7. List item type defined by conformant schemas
-
-   [Rule 11-7] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:list[exists(@itemType)]">
-          <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@itemType, .))"/>
-          <sch:assert test="$namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
-                            or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                          and $namespace = xs:anyURI(@namespace)
-                                          and empty(@appinfo:externalImportIndicator)])"
-            >The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.1.2.2. Derivation by union
-
-Rule 11-8. Union member types defined by conformant schemas
-
-   [Rule 11-8] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:union[exists(@memberTypes)]">
-          <sch:assert test="every $qname in tokenize(normalize-space(@memberTypes), ' '),
-                                  $namespace in namespace-uri-from-QName(resolve-QName($qname, .))
-                            satisfies ($namespace = nf:get-target-namespace(.)
-                                       or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                                 and $namespace = xs:anyURI(@namespace)
-                                                 and empty(@appinfo:externalImportIndicator)]))"
-                      >Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.1.2.3. Code simple types
-
-   [Definition: code simple type]
-
-      A code simple type is a simple type definition schema component that is constrained by one or more enumeration facets.
-
-   These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.
-
-Rule 11-9. Name of a code simple type has standard suffix
-
-   [Rule 11-9] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType[exists(@name)
-            and (xs:restriction/xs:enumeration
-                 or xs:restriction[ends-with(local-name-from-QName(resolve-QName(@base, .)), 'CodeSimpleType')])]">
-          <sch:assert test="ends-with(@name, 'CodeSimpleType')"
-            >A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-10. Code simple type has enumerations
-
-   [Rule 11-10] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType[exists(@name) and ends-with(@name, 'CodeSimpleType')]">
-          <sch:assert test="xs:restriction[ends-with(local-name-from-QName(resolve-QName(@base, .)), 'CodeSimpleType')]
-                            or xs:restriction/xs:enumeration
-                            or (for $union in xs:union,
-                                   $member-types in $union/@memberTypes return
-                                 some $member-type in tokenize(normalize-space($member-types), ' ') satisfies
-                                   ends-with(local-name-from-QName(resolve-QName($member-type, $union)), 'CodeSimpleType'))"
-            >A code simple type MUST be derived from a code simple type or have an enumeration facet.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.
-
-11.1.3. Complex type definition
-
-Rule 11-11. Complex type with simple content has structures:SimpleObjectAttributeGroup
-
-   Within a [reference schema document], a complex type with simple content can be created in one of two ways:
-
-      1. By extension of an existing complex type with simple content.
-
-      2. By extension of an existing simple type.
-
-   Both of these methods use the element xs:extension. Although these two methods have similar syntax, there are subtle differences. NIEM's conformance rules ensure that any complex type has the necessary attributes for representing IDs, references, metadata, and relationship metadata. Case 1 does not require adding these attributes, as they are guaranteed to occur in the base type. However, in case 2, in which a new complex type is created from a simple type, the attributes for complex types must be added. This is done by reference to the attribute group structures:SimpleObjectAttributeGroup.
-
-   [Rule 11-11] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleContent/xs:extension[
-            some $base-qname in resolve-QName(@base, .) satisfies
-              namespace-uri-from-QName($base-qname) = xs:anyURI('http://www.w3.org/2001/XMLSchema')
-              or ends-with(local-name-from-QName($base-qname), 'SimpleType')]">
-          <sch:assert test="xs:attributeGroup[
-                              resolve-QName(@ref, .) = xs:QName('structures:SimpleObjectAttributeGroup')]"
-            >A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/34.0/}SimpleObjectAttributeGroup.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This rule ensures that a complex type with simple content that is created as an immediate extension of a simple type adds the attributes required for specific NIEM linking mechanisms.
-
-   This creates a pattern for complex type with simple content definition as follows:
-
-   Figure 11-1: Example of complex type with simple content derived from a simple type
-
-        <xs:complexType name="PassportCategoryCodeType">
-          <xs:annotation>
-            <xs:documentation>A data type for a kind of passport.</xs:documentation>
-          </xs:annotation>
-          <xs:simpleContent>
-            <xs:extension base="nc:PassportCategoryCodeSimpleType">
-              <xs:attributeGroup ref="structures:SimpleObjectAttributeGroup"/>
-            </xs:extension>
-          </xs:simpleContent>
-        </xs:complexType>
-
-11.2. Declaration components
-
-11.2.1. Element declaration
-
-Rule 11-12. Element name is upper camel case
-
-   [Rule 11-12] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@name)]">
-          <sch:assert test="matches(string(@name), '^([A-Z][A-Za-z0-9\-]*)+$')"
-                      >The name of an element declaration MUST be upper camel case.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [element declaration].
-
-Rule 11-13. Element type does not have a simple type name
-
-   [Rule 11-13] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@type)]">
-          <sch:assert test="not(ends-with(@type, 'SimpleType'))"
-                      >The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defins defines the term [element declaration].
-
-Rule 11-14. Element type is from conformant namespace
-
-   [Rule 11-14] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@type)]">
-          <sch:assert test="for $type-qname in resolve-QName(@type, .),
-                                $type-namespace in namespace-uri-from-QName($type-qname) return
-                              $type-namespace = nf:get-target-namespace(.)
-                              or exists(nf:get-document-element(.)/xs:import[
-                                          xs:anyURI(@namespace) = $type-namespace
-                                          and empty(@appinfo:externalImportIndicator)])"
-                      >The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [element declaration].
-
-   Additional prohibitions on element types are defined by Rule 9-40, Element type not in the XML namespace and Rule 9-41, Element type is not simple type.
-
-Rule 11-15. Name of element that ends in "Abstract" is abstract
-
-   [Rule 11-15] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name[ends-with(., 'Abstract')]]">
-          <sch:assert test="exists(@abstract) and xs:boolean(@abstract) = true()"
-            >An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true".</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.2.1.1. Object element declarations
-
-   This rule checks all cases that are testable in a single schema document.
-
-Rule 11-16. Name of element declaration with simple content has representation term
-
-   [Rule 11-16] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name and @type
-                                      and (some $type-qname in resolve-QName(@type, .) satisfies (
-                                             nf:get-target-namespace(.) = namespace-uri-from-QName($type-qname)
-                                             and nf:resolve-type(., $type-qname)/xs:simpleContent))]">
-          <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                              ends-with(@name, $representation-term)"
-            >The name of an element declaration that is of simple content MUST use a representation term.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Representation terms are defined by Table Table 10-2, Representation terms, above. This Schematron rule supports Rule 10-62, Element with simple content has representation term.
-
-Rule 11-17. Name of element declaration with simple content has representation term
-
-   This rule only checks the cases not testable in the (REF, EXT) version.
-
-   [Rule 11-17] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[@name and @type
-             and (nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))
-                  or nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument')))
-             and (some $type-qname in resolve-QName(@type, .) satisfies (
-                    nf:get-target-namespace(.) != namespace-uri-from-QName($type-qname)
-                    and nf:resolve-type(., $type-qname)/xs:simpleContent))]">
-          <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                              ends-with(@name, $representation-term)"
-            >the name of an element declaration that is of simple content MUST use a representation term.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Representation terms are defined by Table Table 10-2, Representation terms, above. This rule supports Rule 10-62, Element with simple content has representation term.
-
-11.2.2. Element substitution group
-
-Rule 11-18. Element substitution group defined by conformant schema
-
-   [Rule 11-18] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(@substitutionGroup)]">
-          <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@substitutionGroup, .))"/>
-          <sch:assert test="$namespace = nf:get-target-namespace(.)
-                            or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                          and $namespace = xs:anyURI(@namespace)
-                                          and empty(@appinfo:externalImportIndicator)])"
-            >An element substitution group MUST have either the target namespace or a namespace that is imported as conformant.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.2.3. Attribute declaration
-
-Rule 11-19. Attribute type defined by conformant schema
-
-   [Rule 11-19] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@type)]">
-          <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@type, .))"/>
-          <sch:assert test="$namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
-                            or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                          and $namespace = xs:anyURI(@namespace)
-                                          and empty(@appinfo:externalImportIndicator)])"
-            >The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-20. Attribute name uses representation term
-
-   [Rule 11-20] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[exists(@name)]">
-          <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                              ends-with(@name, $representation-term)"
-                      >An attribute name MUST end with a representation term.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.2.4. Notation declaration
-
-11.3. Model group components
-
-11.3.1. Model group
-
-11.3.2. Particle
-
-11.3.2.1. Element use
-
-Rule 11-21. Element or attribute declaration introduced only once into a type
-
-   [Rule 11-21] (REF, EXT)
-
-      Within the schema, an element declaration or attribute decaration declaration MUST NOT be introduced more than once into a type definition. This applies to content acquired by a type by any means, including from a base type definition, via element substitution groups, or through the use of attribute groups.
-
-   This rule ensures that a type definition does not incorporate a component multiple times. As information exchange specifications often contain multiple versions of schemas, including reference schemas as well as subset and constraint schemas, it may be easy to omit an element or attribute in one version of the schema, only to reincorporate it via an extension. This can cause difficulties in integrating such schemas, as it may be impossible to use a reference schema if an attribute is added twice, in both a base type and an extension type, since that would make it an invalid schema.
-
-   Incorporating a component multiple times can also make it difficult to avoid violating XML Schema's unique particle attribution constraint, which is described by [XML Schema Structures] Section 3.8.6, Constraints on Model Group Schema Components. This can create difficulty if an element is added both directly, and via a substitution group head. In such a case, a parser may not be able to determine which element use is responsible for an element in an instance, which is a violation of the UPA constraint.
-
-   This rule is also intended to prevent developers from creating complicated sequences of recurring elements. Such definitions are difficult for developers to satisfy in code, and can cause havoc with XML Schema language binding tools. If an element is needed more than once, or if a particular sequence of elements is needed, a developer should consider the use of flexible content models (via substitution groups) along with additional rules.
-
-Rule 11-22. Element reference defined by conformant schema
-
-   [Rule 11-22] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[exists(ancestor::xs:complexType[empty(@appinfo:externalAdapterTypeIndicator)]) and @ref]">
-          <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@ref, .))"/>
-          <sch:assert test="$namespace = nf:get-target-namespace(.)
-                            or exists(ancestor::xs:schema[1]/xs:import[exists(@namespace)
-                                          and $namespace = xs:anyURI(@namespace)
-                                          and empty(@appinfo:externalImportIndicator)])"
-            >An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   The term [schema document] is a defined term.
-
-11.3.3. Attribute use
-
-Rule 11-23. Referenced attribute defined by conformant schemas
-
-   [Rule 11-23] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attribute[@ref]">
-          <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@ref, .))"/>
-          <sch:assert test="some $namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies (
-                              $namespace = nf:get-target-namespace(.)
-                              or ancestor::xs:schema[1]/xs:import[
-                                   @namespace
-                                   and $namespace = xs:anyURI(@namespace)
-                                   and empty(@appinfo:externalImportIndicator)])"
-            >An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.3.3.1. Attribute group use
-
-Rule 11-24. Schema uses only known attribute groups
-
-   In conformant schemas, use of attribute groups is restricted. The only attribute group defined by NIEM for use in conformant schemas is structures:SimpleObjectAttributeGroup. This attribute group provides the attributes necessary for IDs, references, metadata, and relationship metadata. In addition, there are attributes defined by ISM and NTK namespaces, which may be used in conformant schemas. Rationale for this use is provided in Section 7.6, IC-ISM and IC-NTK, above.
-
-   [Rule 11-24] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:attributeGroup[@ref]">
-          <sch:assert test="some $ref in resolve-QName(@ref, .) satisfies (
-                              $ref = xs:QName('structures:SimpleObjectAttributeGroup')
-                              or namespace-uri-from-QName($ref) = (xs:anyURI('urn:us:gov:ic:ism'),
-                                                                   xs:anyURI('urn:us:gov:ic:ntk')))"
-            >An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-11.3.4. Wildcard
-
-11.4. Identity-constraint definition components
-
-11.5. Group definition components
-
-11.5.1. Model group definition
-
-11.5.2. Attribute group definition
-
-11.6. Annotation components
-
-   NIEM-conformant schemas define data models for the purpose of information exchange. A major part of defining data models is the proper definition of the contents of the model. What does a component mean, and what might it contain? How should it be used? NIEM- conformant schemas contain the invariant part of the definitions for the data model. The set of definitions includes:
-
-      1. A text definition of each component. This describes what the component means. The term used in this specification for such a text definition is data definition.
-
-      2. The structural definition of each component. This is made up of XML Schema component definitions, along with certain [application information] (via xs:appinfo).
-
-   When possible, meaning is expressed via XML Schema mechanisms: type derivation, element substitution, specific types and structures, as well as names that are trivially parseable. Beyond that, NIEM-specific syntax must be used, as discussed in this section.
-
-11.6.1. Human-readable documentation
-
-   Note that Rule 11-29, Data definition follows 11179-4 requirements and Rule 11-30, Data definition follows 11179-4 recommendations apply [ISO 11179-4] definition rules to documented components.
-
-Rule 11-25. Data definition does not introduce ambiguity
-
-   [Rule 11-25] (REF, EXT)
-
-      Words or synonyms for the words within a data definition MUST NOT be reused as terms in the corresponding component name if those words dilute the semantics and understanding of, or impart ambiguity to, the entity or concept that the component represents.
-
-   This document defines the term [data definition].
-
-Rule 11-26. Object class has only one meaning
-
-   [Rule 11-26] (REF, EXT)
-
-      An object class MUST have one and only one associated semantic meaning (i.e., a single word sense) as described in the definition of the component that represents that object class.
-
-Rule 11-27. Data definition of a part does not redefine the whole
-
-   [Rule 11-27] (REF, EXT)
-
-      An object class MUST NOT be redefined within the definitions of the components that represent properties or subparts of that entity or class.
-
-   Data definitions should be concise, precise, and unambiguous without embedding additional definitions of data elements that have already been defined once elsewhere (such as object classes). [ISO 11179-4] says that definitions should not be nested inside other definitions. Furthermore, a data dictionary is not a language dictionary. It is acceptable to reuse terms (object class, property term, and qualifier terms) from a component name within its corresponding definition to enhance clarity, as long as the requirements and recommendations of [ISO 11179-4] are not violated. This further enhances brevity and precision.
-
-Rule 11-28. Do not leak representation into data definition
-
-   [Rule 11-28] (REF, EXT)
-
-      A data definition MUST NOT contain explicit representational or data typing information such as number of characters, classes of characters, range of mathematical values, etc., unless the very nature of the component can be described only by such information.
-
-   A component definition is intended to describe semantic meaning only, not representation or structure. How a component with simple content is represented is indicated through the representation term, but the primary source of representational information should come from the XML Schema definition of the types themselves. A developer should try to keep a component's data definition decoupled from its representation.
-
-Rule 11-29. Data definition follows 11179-4 requirements
-
-   [Rule 11-29] (REF, EXT)
-
-      Each [data definition] MUST conform to the requirements for data definitions provided by [ISO 11179-4] Section 5.2, Requirements.
-
-Rule 11-30. Data definition follows 11179-4 recommendations
-
-   [Rule 11-30] (REF, EXT)
-
-      Each [data definition] SHOULD conform to the recommendations for data definitions provided by [ISO 11179-4] Section 5.3, Recommendations.
-
-11.6.1.1. Data definition opening phrases
-
-Rule 11-31. Standard opening phrase for element
-
-   [Rule 11-31] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:element[ends-with(@name, 'AugmentationPoint')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(starts-with(lower-case(normalize-space(.)), 'an augmentation point '))"
-            >The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Augmentation')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(some $phrase in ('supplements ', 'additional information about ')
-                                  satisfies starts-with(lower-case(normalize-space(.)), $phrase))"
-            >The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Metadata')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '(metadata about|information that further qualifies)'))"
-            >The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Association') and empty(@abstract)
-                             ]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)),
-                                        '^an?( .*)? (relationship|association)'))"
-            >The data defintion definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[xs:boolean(@abstract) = true()
-                             ]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(starts-with(lower-case(normalize-space(.)), 'a data concept'))"
-            >The data defintion definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Date')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (date|month|year)'))"
-            >The data defintion definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Quantity')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (count|number)'))"
-            >The data defintion definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Picture')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (image|picture|photograph)'))"
-            >The data defintion definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Indicator')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^true if .*; false (otherwise|if)'))"
-            >The data defintion definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Identification')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? identification'))"
-            >The data defintion definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[ends-with(@name, 'Name')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^(a|an)( .*)? name'))"
-            >The data defintion definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:element[@name]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^an? '))"
-            >The data defintion definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)".</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-32. Standard opening phrase for complex type
-
-   [Rule 11-32] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:complexType[ends-with(@name, 'AssociationType')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type for (a relationship|an association)'))"
-            >The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:complexType[ends-with(@name, 'AugmentationType')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type (that supplements|for additional information about)'))"
-            >The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:complexType[ends-with(@name, 'MetadataType')]/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type for (metadata about|information that further qualifies)'))"
-            >The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metdata (metadata about|information that further qualifies)...".</sch:report>
-        </sch:rule>
-        <sch:rule context="xs:complexType/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type'))"
-            >The data definition for a type SHOULD begin with the standard opening phrase "a data type...".</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-33. Standard opening phrase for simple type
-
-   [Rule 11-33] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:simpleType/xs:annotation/xs:documentation[1]">
-          <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type'))"
-            >The data definition for a type SHOULD begin with a standard opening phrase "a data type...".</sch:report>
-        </sch:rule>
-      </sch:pattern>
-
-11.7. Schema as a whole
-
-11.7.1. xs:schema document element restrictions
-
-Rule 11-34. Same namespace means same components
-
-   [Rule 11-34] (REF, EXT)
-
-      Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, if and only if they represent the same set of components.
-
-Rule 11-35. Different version means different view
-
-   [Rule 11-35] (REF, EXT)
-
-      Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, and different values for attribute version carried by the element xs:schema if and only if they are different views of the same set of components.
-
-   These rules embody the basic philosophy behind NIEM's use of namespaced components: A component is uniquely identified by its class (e.g. element, attribute, type), its namespace (a URI), and its local name (an unqualified string). Any two matching component identifiers refer to the same component, even if the versions of the schemas containing each are different.
-
-11.8. Schema assembly
-
-Rule 11-36. Reference schema imports reference schema
-
-   [Rule 11-36] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:import[
-                               nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))
-                               and exists(@namespace)
-                               and empty(@appinfo:externalImportIndicator)
-                               and not(xs:anyURI(@namespace) = (xs:anyURI('http://release.niem.gov/niem/structures/34.0/'),
-                                                                xs:anyURI('http://www.w3.org/XML/1998/namespace')))]">
-          <sch:assert test="some $schema in nf:resolve-namespace(., @namespace) satisfies
-                              nf:has-effective-conformance-target-identifier($schema, xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))"
-            >A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the term [reference schema document].
-
-Rule 11-37. Extension schema document imports reference or extension schema
-
-   [Rule 11-37] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:import[
-                               nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument'))
-                               and exists(@namespace)
-                               and empty(@appinfo:externalImportIndicator)
-                               and not(xs:anyURI(@namespace) = (xs:anyURI('http://release.niem.gov/niem/structures/34.0/'),
-                                                                xs:anyURI('http://www.w3.org/XML/1998/namespace')))]">
-          <sch:assert test="some $schema in nf:resolve-namespace(., @namespace) satisfies (
-                              nf:has-effective-conformance-target-identifier($schema, xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ReferenceSchemaDocument'))
-                              or nf:has-effective-conformance-target-identifier($schema, xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/34.0/#ExtensionSchemaDocument')))"
-            >A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This document defines the terms [extension schema document] and [reference schema document].
-
-11.8.1. Supporting namespaces are imported as conformant
-
-   There are several namespaces that are treated specially by the NIEM NDR. When the following namespaces are imported into a conformant schema document, they must be imported as if they are conformant. That is, the xs:import element must not have an attribute appinfo:externalImportIndicator with a value of "true".
-
-Rule 11-38. Structures imported as conformant
-
-   [Rule 11-38] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:import[exists(@namespace)
-                                     and xs:anyURI(@namespace) = xs:anyURI('http://release.niem.gov/niem/structures/34.0/')]">
-          <sch:assert test="empty(@appinfo:externalImportIndicator)"
-            >An import of the structures namespace MUST NOT be labeled as an external import.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-39. XML namespace imported as conformant
-
-   [Rule 11-39] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:import[exists(@namespace)
-                                     and xs:anyURI(@namespace) = xs:anyURI('http://www.w3.org/XML/1998/namespace')]">
-          <sch:assert test="empty(@appinfo:externalImportIndicator)"
-            >An import of the XML namespace MUST NOT be labeld labeled as an external import.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-40. Each namespace may have only a single root schema in a schema set
-
-   [Rule 11-40] (SET)
-
-      <sch:pattern>
-        <sch:rule context="xs:schema[exists(@targetNamespace)
-                                     and (some $element
-                                         in nf:resolve-namespace(., xs:anyURI(@targetNamespace))
-                                         satisfies $element is .)]">
-          <sch:assert test="count(nf:resolve-namespace(., xs:anyURI(@targetNamespace))) = 1"
-                      >A namespace may appear as a root schema in a schema set only once.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 11-41. Consistently marked namespace imports
-
-   XML Schemas allows multiple xs:import elements for the same namespace, which allows for multiple sets of annotations and schema locations. 
-
-   [Rule 11-41] (REF, EXT)
-
-      <sch:pattern>
-        <sch:rule context="xs:import">
-          <sch:let name="namespace" value="@namespace"/>
-          <sch:let name="is-conformant" value="empty(@appinfo:externalImportIndicator)"/>
-          <sch:let name="first" value="exactly-one(parent::xs:schema/xs:import[@namespace = $namespace][1])"/>
-          <sch:assert test=". is $first
-                            or $is-conformant = empty($first/@appinfo:externalImportIndicator)"
-                  >All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-12. XML instance document rules
-
-   This specification attempts to restrict XML instance data as little as possible while still maintaining interoperability.
-
-   NIEM does not require a specific encoding or specific requirements for the XML prologue, except as specified by [XML].
-
-Rule 12-1. Instance must be schema-valid
-
-   [Rule 12-1] (INS)
-
-      The XML document MUST be schema-valid, as assessed against a [conformant schema document set], composed of authoritative, comprehensive schema documents for the relevant namespaces.
-
-   The schemas that define the exchange must be authoritative. Each is the reference schema or extension schema for the namespace it defines. Application developers may use other schemas for various purposes, but for the purposes of determining conformance, the authoritative schemas are relevant.
-
-   This rule should not be construed to mean that XML validation must be performed on all XML instances as they are served or consumed; only that the XML instances validate if XML validation is performed. The XML Schema component definitions specify XML documents and element information items, and the instances should follow the rules given by the schemas, even when validation is not performed.
-
-   NIEM embraces the use of XML Schema instance attributes, including xsi:type, xsi:nil, and xsi:schemaLocation, as specified by [XML Schema Structures].
-
-12.1. Content elements
-
-   In XML instances, relationships between data objects are expressed as XML elements:
-
-      1. Data objects are expressed as XML elements.
-
-      2. XML elements contain attributes and other elements.
-
-   In this way, there is a relationship between the outer element (the containing element, also called the parent element) and the inner elements (the contained elements, also called as the child elements). An element that contains its content in this way is called a [content element].
-
-   [Definition: content element]
-
-      A content element is an element information item that does not contain an attribute structures:ref. A content element expresses its value as text and element content of the element information item.
-
-   The most common NIEM patterns use content elements to represent most data. The following is an example of a content element in use. All elements in this example are content elements.
-
-   Figure 12-1: Example of content elements
-
-      <nc:Item>
-        <nc:ItemOwner>
-          <nc:EntityPerson>
-            <nc:PersonName>
-              <nc:PersonFullName>John Doe</nc:PersonFullName>
-            </nc:PersonName>
-          </nc:EntityPerson>
-        </nc:ItemOwner>
-      </nc:Item>
-
-12.2. Reference elements
-
-   Content elements are sufficient to represent data that takes the form of a tree. However, use of content elements has limitations; expression of all relationships via element containment is not always possible. Situations that cause problems include:
-
-      *  Cycles: the relationships transitively held by an object include a relationship to itself.
-
-         For example, suppose that object 1 has a relationship to object 2 and object 2 has a relationship to object 1. This is not a tree, and so needs some representation other than a simple tree.
-
-      *  Reuse: multiple objects have a relationshp relationship to a common object.
-
-         For example, suppose object 1 has a relationship to object 2 and object 3 has a relationship to object 2. Expressed via containment, this would result in a duplicate of object 2.
-
-   A method that solves this problem is the use of references. In a C or assembler, you could use a pointer. In C++, a reference might be used. In Java, a reference value might be used. The method defined by the XML standard is the use of ID and IDREF. An IDREF refers to an ID. NIEM uses this method and assigns to it specific semantics.
-
-   Naive solutions to these problems that use only content elements require techniques such as repeating data and identifying and excluding duplicate data; these operation entail the use of excess storage and processing time.
-
-   It is good to avoid these problems; in order to avoid them, NIEM allows [reference elements]. A reference element expresses a relationship to another object by using a reference attribute, structures:ref. In Figure 12-2, Example of reference element, below, the outer object is the content of nc:Item, which is an object of type nc:ItemType. It has a relationship nc:ItemOwner to the object that is the content of the nc:Entity element.
-
-   Figure 12-2: Example of reference element
-
-      <nc:Item>
-        <nc:ItemOwner structures:ref="m82"/>
-      </nc:Item>
-      <nc:Entity structures:id="m82">
-        <nc:EntityPerson>
-          <nc:PersonName>
-            <nc:PersonFullName>John Doe</nc:PersonFullName>
-          </nc:PersonName>
-        </nc:EntityPerson>
-      </nc:Entity>
-
-   NIEM XML instances use IDREF attributes to establish links between XML elements.
-
-   [Definition: reference element]
-
-      A reference element is an element information item that has an attribute structures:ref. A reference element refers to its value by reference, instead of carrying it as content.
-
-Rule 12-2. Element with structures:ref does not have content
-
-   [Rule 12-2] (INS)
-
-      <sch:pattern>
-        <sch:rule context="*[@structures:ref]">
-          <sch:assert test="empty(element() | text())"
-            >An element that has attribute structures:ref MUST NOT have element or text content.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-Rule 12-3. Attribute structures:ref must reference structures:id
-
-   [Rule 12-32] (INS)
-
-      <sch:pattern>
-        <sch:rule context="*[@structures:ref]">
-          <sch:let name="ref" value="@structures:ref"/>
-          <sch:assert test="exists(//*[@structures:id = $ref])"
-            >The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   This mirrors the terminology in [XML] subsection Validity constraint: IDREF within Section 3.3.1, Attribute Types, except it requires the target attribute to be structures:id, rather than any attribute of type ID.
-
-Rule 12-43. Linked elements have same validation root
-
-   [Rule 12-43] (INS)
-
-      Given that:
-
-         *  $element is an element information item
-
-         *  $element has attribute structures:ref with value $ref
-
-         *  $element has property [validation context] with value called the referencing element validation root
-
-         *  $target is an element information item
-
-         *  $target has attribute structures:id with value $ref
-
-         *  $target has property [validation context] with value called the referenced element validation root
-
-      Every element that has an attribute structures:ref MUST have a referencing element validation root that is equal to the referenced element validation root.
-
-   The term "validation root" is defined by [XML Schema Structures] Section 5.2, Assessing Schema-Validity. It is established as a part of validity assessment of an XML document. It is required because relationships between the types of elements cannot be established if those elements were not assessed together.
-
-Rule 12-54. Attribute structures:ref references element of correct type
-
-   [Rule 12-54] (INS)
-
-      Given that:
-
-         *  $element is an element information item
-
-         *  $element has attribute structures:ref with value $ref
-
-         *  $element has property [element declarationtype definition] with value $element-declaration
-
-         *  $element-declaration has property {type definition} with value called the referencing element type definition.
-
-         *  $target is an element information item
-
-         *  $target has attribute structures:id with value $ref
-
-         *  $target has property [type definition] with value called the referenced element type definition
-
-      Every element that has an attribute structures:ref MUST have a referencing referenced element type definition that is validly derived from the referenced referencing element type definition.
-
-   The term validly derived is as established by [XML Schema Structures] subsection Schema Component Constraint: Type Derivation OK (Complex) within Section 3.4.6, Constraints on Complex Type Definition Schema Components.
-
-   This rule requires that the type of the element information item pointed to by a structures:ref attribute must be of (or derived from) the type that is specified by the element declaration of the reference element.
-
-12.2.1. Reference and content elements have same meaning
-
-   An important aspect of the use of NIEM reference and content elements is that they have the same meaning. The use of a content element versus a reference element is merely for convenience and ease of serialization. There is no change in meaning or semantics between content and reference elements.
-
-   Any claim that content elements represent composition while reference elements represent aggregation is incorrect. Any life cycle dependency is not expressed through the use of content and reference elements, and is not an explicit part of the NIEM model.
-
-Rule 12-65. Reference and content elements have the same meaning
-
-   [Rule 12-65] (INS)
-
-      There MUST NOT be any difference in meaning between a relationship established via an element declaration instantiated as a content element and that element declaration instantiated as a reference element.
-
-   There is no difference in meaning between relationships established by content elements and those established by reference elements. They are simply two mechanisms for expressing connections between objects. Neither mechanism implies that properties are intrinsic or extrinsic; such characteristics must be explicitly stated in property definitions.
-
-   Being of type xs:ID and xs:IDREF, validating schema parsers will perform certain checks on the values of structures:id and structures:ref. Specifically, no two IDs may have the same value. This includes structures:id and other IDs that may be used within an XML document. Also, any value of structures:ref must also appear as the value of an ID.
-
-   By this rule, the following two XML fragments have the same meaning. First, Figure 12-3, Example with a backward reference, below, shows a person object being expressed, followed by a backwards reference to it. Second, Figure 12-4, Example with a forward reference, below, shows a person as a forward reference to the person object that is expressed later, within the definition of a witness. Both of these XML fragments have the same semantics.
-
-   Figure 12-3: Example with a backward reference
-
-      <nc:Person structures:id="c58">
-        <nc:PersonName>
-          <nc:PersonFullName>John Doe</nc:PersonFullName>
-        </nc:PersonName>
-      </nc:Person>
-      <j:Witness>
-        <nc:RoleOfPerson structures:ref="c58"/>
-      </j:Witness>
-
-   Figure 12-4: Example with a forward reference
-
-      <nc:Person structures:ref="t85"/>
-      <j:Witness>
-        <nc:RoleOfPerson structures:id="t85">
-          <nc:PersonName>
-            <nc:PersonFullName>John Doe</nc:PersonFullName>
-          </nc:PersonName>
-        </nc:RoleOfPerson>
-      </j:Witness>
-
-   NIEM-conformant data instances may use content elements and reference elements as needed, to represent the meaning of the fundamental data. There is no difference in meaning between reference and content data representations. The two different methods are available for ease of representation. No difference in meaning should be implied by the use of one method or the other.
-
-   Assertions that indicate "included" data is intrinsic, while referenced data is extrinsic, are not valid and are not applicable to NIEM-conformant data instances and data definitions.
-
-Rule 12-76. Empty content has no meaning
-
-   [Rule 12-76] (INS)
-
-      Within the instance, the meaning of an element with no content is that additional properties are not asserted. There MUST NOT be additional meaning interpreted for an element with no content.
-
-   Elements without content only show a lack of asserted information. That is, all that is asserted is what is explicitly stated, through a combination of XML instance data and its schema. Data that is not present makes no claims. It may be absent due to lack of availability, lack of knowledge, or deliberate withholding of information. These cases should be modeled explicitly, if they are required.
-
-12.3. Instance metadata
-
-   NIEM provides the metadata mechanism for giving information about object assertions. An object may have an attribute that refers to one or more metadata objects. A structures:metadata attribute indicates that a data item has the given metadata. A structures:relationshipMetadata attribute asserts that the link (or relationship) established by an element has the given metadata.
-
-   Figure 12-5: Example of metadata used in an instance
-
-      <nc:Person>
-        <nc:PersonBirthDate structures:metadata="j86">
-          <nc:Date>1945-12-01</nc:Date>
-        </nc:PersonBirthDate>
-        <nc:PersonName structures:metadata="s22 j86" structures:relationshipMetadata="k25">
-          <nc:PersonFullName>John Doe</nc:PersonFullName>
-        </nc:PersonName>
-      </nc:Person>
-      <nc:Metadata structures:id="s22">
-        <nc:SourceText>Adam Barber</nc:SourceText>
-      </nc:Metadata>
-      <nc:Metadata structures:id="j86">
-        <nc:ReportedDate>
-          <nc:Date>2005-04-26</nc:Date>
-        </nc:ReportedDate>
-      </nc:Metadata>
-      <nc:Metadata structures:id="k25">
-        <nc:ProbabilityPercent>0.25</nc:ProbabilityPercent>
-      </nc:Metadata>
-
-   This example shows a person named John Doe, born 12/1/1945. This data has several pieces of metadata on it:
-
-      *  Metadata s22 asserts Adam Barber gave the name.
-
-      *  Metadata j86 asserts the name and the birth date were reported on 4/26/2005.
-
-      *  Link metadata o67 asserts a 25% probability that the name goes with the person.
-
-   This shows several characteristics of metadata:
-
-      *  Metadata objects may appear outside the data they describe.
-
-      *  Metadata objects may be reused.
-
-      *  Data may refer to more than one metadata object.
-
-      *  Metadata pertains to an object or simple content, while link metadata pertains to the relationship between objects.
-
-   An instance would not be valid XML if the structures:metadata or structures:relationshipMetadata attributes contained references for which there were no defined IDs. The instance would not be NIEM-conformant if the references were not to IDs defined with the structures:id attribute.
-
-   Application of metadata to a type or element to which it is not applicable is not NIEM-conformant. A metadata element may be labeled as applicable to multiple elements via attribute appinfo:appliesToElements, or to multiple types via attribute appinfo:appliesToTypes. In either case it may apply to an instance of any of the listed elements or types. A metadata element with neither attribute appinfo:appliesToElements nor attribute appinfo:appliesToTypes may be applied to any element of any type.
-
-Rule 12-87. Metadata applies to referring entity
-
-   [Rule 12-87] (INS)
-
-      Within an element instance, when an object $O links to a metadata object via an attribute structures:metadata, the information in the metadata object MUST be applied to the object $O.
-
-   structures:metadata applies metadata to an object.
-
-Rule 12-98. Referent of structures:relationshipMetadata annotates relationship
-
-   [Rule 12-98] (INS)
-
-      Within an element instance, when an object $O1 contains an element $E, with content object $O2 or with a reference to object $O2, and $O2 links to a metadata object via an attribute structures:relationshipMetadata, the information in the metadata object MUST be applied to the relationship $E between $O1 and $O2.
-
-   structures:relationshipMetadata applies metadata to a relationship between two objects.
-
-Rule 12-109. Values of structures:metadata refer to values of structures:id
-
-   [Rule 12-109] (INS)
-
-      Given that each IDREF in the value of an attribute structures:metadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.
-
-Rule 12-1110. Value of structures:relationshipMetadata refers to value of structures:id
-
-   [Rule 12-1110] (INS)
-
-      Given that each IDREF in the value of an attribute structures:relationshipMetadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.
-
-Rule 12-1211. structures:metadata and structures:relationshipMetadata refer to metadata elements
-
-   [Rule 12-1211] (INS)
-
-      Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a [metadata element declaration].
-
-   Although not implemented in Schematron, this rule covers the cases not covered by Rule 12-1312, Attribute structures:metadata references metadata element.
-
-Rule 12-1312. Attribute structures:metadata references metadata element
-
-   [Rule 12-1312] (INS)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@structures:metadata)]">
-          <sch:assert test="every $metadata-ref in tokenize(normalize-space(@structures:metadata), ' ') satisfies
-                              exists(//*[exists(@structures:id[. = $metadata-ref])
-                                         and ends-with(local-name(), 'Metadata')])"
-            >Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that this will NOT diagnose a scenario in which the element with a name ending in "Metadata" is an external element; additional tests would be required to catch that.
-
-Rule 12-1413. Attribute structures:relationshipMetadata references metadata element
-
-   [Rule 12-1413] (INS)
-
-      <sch:pattern>
-        <sch:rule context="*[exists(@structures:relationshipMetadata)]">
-          <sch:assert test="every $metadata-ref in tokenize(normalize-space(@structures:relationshipMetadata), ' ') satisfies
-                              exists(//*[exists(@structures:id[. = $metadata-ref])
-                                         and ends-with(local-name(), 'Metadata')])"
-            >Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element.</sch:assert>
-        </sch:rule>
-      </sch:pattern>
-
-   Note that this will NOT diagnose a scenario in which the element with a name ending in "Metadata" is an external element; additional tests would be required to catch that.
-
-Rule 12-1514. Metadata is applicable to element
-
-   [Rule 12-1514] (INS)
-
-      Given that an element $SUBJECT-ELEMENT uses a metadata element $METADATA-ELEMENT through a value in either an attribute structures:metadata or an attribute structures:relationshipMetadata, the element $SUBJECT-ELEMENT MUST be an applicable element for $METADATA-ELEMENT.
-
-   The applicable elements for a metadata element are identified by Rule 10-40, Metadata element has applicable elements.
-
-Appendix A. References
-
-   [ClarkNS]: Clark, J. "XML Namespaces", 4 February 1999. Available from http://www.jclark.com/xml/xmlns.htm.
-
-   [ConfReq]: Lynne Rosenthal, and Mark Skall, eds. "Conformance Requirements for Specifications v1.0." The Organization for the Advancement of Structured Information Standards (OASIS), March 15, 2002. https://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf.
-
-   [CTAS]: Roberts, Webb. "NIEM Conformance Targets Attribute Specification, Version 3.0." NIEM Technical Architecture Committee, July 31, 2014. http://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/NIEM-CTAS-3.0-2014-07-31.html.
-
-   [ISO 11179-4]: "ISO/IEC 11179-4 Information Technology -- Metadata Registries (MDR) -- Part 4: Formulation of Data Definitions Second Edition", 15 July 2004. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035346_ISO_IEC_11179-4_2004(E).zip.
-
-   [ISO 11179-5]: "ISO/IEC 11179-5:2005, Information technology -- Metadata registries (MDR) -- Part 5: Naming and identification principles". Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035347_ISO_IEC_11179-5_2005(E).zip.
-
-   [JSON LD]: Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, and Niklas Lindstrom. "JSON-LD 1.0, A JSON-Based Serialization for Linked Data, W3C Recommendation." Edited by Manu Sporny, Gregg Kellogg, and Markus Lanthaler. W3C, January 16, 2014. https://www.w3.org/TR/2014/REC-json-ld-20140116/.
-
-   [JLS]: James Gosling, Bill Joy, Guy Steele, Gilad Bracha, and Alex Buckley. "The Java Language Specification, Java SE 8 Edition." Oracle Corp, March 3, 2014. http://docs.oracle.com/javase/specs/jls/se8/html/.
-
-   [N-ary]: "Defining N-ary Relations on the Semantic Web", W3C Working Group Note, 12 April 2006. Available from http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412//.
-
-   [OED]: "Oxford English Dictionary, Third Edition", Oxford University Press, November 2010. http://dictionary.oed.com/.
-
-   [RDF Concepts]: Richard Cyganiak, David Wood, and Markus Lanthaler, eds. "RDF 1.1 Concepts and Abstract Syntax." The World Wide Web Consortium (W3C), February 25, 2014. http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.
-
-   [RFC 2119]: Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997. Available from http://www.ietf.org/rfc/rfc2119.txt.
-
-   [RFC 3986]: Berners-Lee, T., et al. "Uniform Resource Identifier (URI): Generic Syntax", Request for Comments 3986, January 2005. Available from http://tools.ietf.org/html/rfc3986.
-
-   [XML]: "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, 16 August 2006. Available from http://www.w3.org/TR/2008/REC-xml-20081126/.
-
-   [XML Base]: Jonathan Marsh, and Richard Tobin, eds. "XML Base (Second Edition), W3C Recommendation." W3C, January 28, 2009. Available from http://www.w3.org/TR/2009/REC-xmlbase-20090128/.
-
-   [XML Infoset]: Cowan, John, and Richard Tobin. "XML Information Set (Second Edition)", 4 February 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.
-
-   [XML Namespaces]: "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation, 8 December 2009. Available from http://www.w3.org/TR/2009/REC-xml-names-20091208/.
-
-   [XML Namespaces Errata]: "Namespaces in XML Errata", 6 December 2002. Available from http://www.w3.org/XML/xml-names-19990114-errata.
-
-   [XML Schema Structures]: "XML Schema Part 1: Structures Second Edition", W3C Recommendation, 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.
-
-   [XML Schema Datatypes]: "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, 28 October 2004. Available at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
-
-   [Schematron]: "ISO/IEC STANDARD 19757-3: Information technology -- Document Schema Definition Languages (DSDL) Part 3: Rule-based validation -- Schematron", ISO/IEC, 1 June 2006. Retrieved from http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip.
-
-   [XPath 2]: Berglund, Anders, Scott Boag, Don Chamberlin, Mary F. Fernandez, Michael Kay, Jonathan Robie, and Jerome Simeon. "XML Path Language (XPath) 2.0 (Second Edition)", W3C Recommendation, 3 January 2011. http://www.w3.org/TR/2010/REC-xpath20-20101214/.
-
-Appendix B. Structures namespace
-
-   <?xml version="1.0" encoding="US-ASCII"?>
-   <xs:schema
-       targetNamespace="http://release.niem.gov/niem/structures/34.0/"
-       version="14.0alpha1"
-       xmlns:structures="http://release.niem.gov/niem/structures/34.0/"
-       xmlns:xs="http://www.w3.org/2001/XMLSchema">
-   
-       <xs:attribute name="id" type="xs:ID"/>
-       <xs:attribute name="ref" type="xs:IDREF"/>
-       <xs:attribute name="uri" type="xs:anyURI"/>
-       <xs:attribute name="metadata" type="xs:IDREFS"/>
-       <xs:attribute name="relationshipMetadata" type="xs:IDREFS"/>
-      
-       <xs:attributeGroup name="SimpleObjectAttributeGroup">
-           <xs:attribute ref="structures:id"/>
-           <xs:attribute ref="structures:ref"/>
-           <xs:attribute ref="structures:metadata"/>
-           <xs:attribute ref="structures:relationshipMetadata"/>
-           <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
-       </xs:attributeGroup>
-   
-       <xs:complexType name="ObjectType" abstract="true">
-           <xs:sequence>
-               <xs:element ref="structures:ObjectAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-           </xs:sequence>
-           <xs:attribute ref="structures:id"/>
-           <xs:attribute ref="structures:ref"/>
-           <xs:attribute ref="structures:metadata"/>
-           <xs:attribute ref="structures:relationshipMetadata"/>
-           <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
-       </xs:complexType>
-   
-       <xs:element name="ObjectAugmentationPoint" abstract="true">
-           <xs:annotation>
-               <xs:documentation>An augmentation point for ObjectType</xs:documentation>
-           </xs:annotation>
-       </xs:element>
-   
-       <xs:complexType name="AssociationType" abstract="true">
-           <xs:sequence>
-               <xs:element ref="structures:AssociationAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
-           </xs:sequence>
-           <xs:attribute ref="structures:id"/>
-           <xs:attribute ref="structures:ref"/>
-           <xs:attribute ref="structures:metadata"/>
-           <xs:attribute ref="structures:relationshipMetadata"/>
-           <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
-       </xs:complexType>
-   
-       <xs:element name="AssociationAugmentationPoint" abstract="true">
-           <xs:annotation>
-               <xs:documentation>An augmentation point for AssociationType</xs:documentation>
-           </xs:annotation>
-       </xs:element>
-   
-       <xs:complexType name="MetadataType" abstract="true">
-           <xs:attribute ref="structures:id"/>
-           <xs:attribute ref="structures:ref"/>
-           <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
-       </xs:complexType>
-   
-       <xs:complexType name="AugmentationType" abstract="true">
-           <xs:attribute ref="structures:id"/>
-           <xs:attribute ref="structures:ref"/>
-           <xs:attribute ref="structures:metadata"/>
-           <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
-       </xs:complexType>
-   
-   </xs:schema>
-   
-
-Appendix C. Appinfo namespace
-
-   <?xml version="1.0" encoding="US-ASCII"?>
-   <xs:schema
-       attributeFormDefault="qualified"
-       targetNamespace="http://release.niem.gov/niem/appinfo/34.0/"
-       version="14.0alpha1"
-       xmlns:appinfo="http://release.niem.gov/niem/appinfo/34.0/"
-       xmlns:xs="http://www.w3.org/2001/XMLSchema">
-   
-     <xs:annotation>
-       <xs:documentation>The appinfo schema provides support for high level data model concepts and additional syntax to support the NIEM conceptual model and validation of NIEM-conformant instances.</xs:documentation>
-     </xs:annotation>
-   
-     <xs:attribute name="deprecated">
-       <xs:annotation>
-         <xs:documentation>The Deprecated element provides a method for identifying schema components as being deprecated. A deprecated component is one that is provided, but the use of which is not recommended.</xs:documentation>
-       </xs:annotation>
-       <xs:simpleType>
-         <xs:restriction base="xs:boolean">
-           <xs:pattern value="true"/>
-         </xs:restriction>
-       </xs:simpleType>
-     </xs:attribute>
-   
-     <xs:attribute name="appliesToTypes">
-       <xs:annotation>
-         <xs:documentation>The appliesToTypes attribute appears on the element declaration of a metadata element. It indicates a set of types to which the metadata element may be applied. The metadata element will also be applicable to any type that is derived from a listed type.</xs:documentation>
-       </xs:annotation>
-       <xs:simpleType>
-         <xs:list itemType="xs:QName"/>
-       </xs:simpleType>
-     </xs:attribute>
-   
-     <xs:attribute name="appliesToElements">
-       <xs:annotation>
-         <xs:documentation>The appliesToElements attribute appears on the element declaration of a metadata element. It indicates a set of elements to which the metadata element may be applied. The metadata element will also be applicable to any element that is in the substitution group of a listed element.</xs:documentation>
-       </xs:annotation>
-       <xs:simpleType>
-         <xs:list itemType="xs:QName"/>
-       </xs:simpleType>
-     </xs:attribute>
-   
-     <xs:attribute name="externalAdapterTypeIndicator">
-       <xs:annotation>
-         <xs:documentation>The externalAdapterTypeIndicator attribute indicates that a complex type is an external adapter type. An external adapter type is composed of elements and attributes from non-NIEM-conformant schemas.</xs:documentation>
-       </xs:annotation>
-       <xs:simpleType>
-         <xs:restriction base="xs:boolean">
-           <xs:pattern value="true"/>
-         </xs:restriction>
-       </xs:simpleType>
-     </xs:attribute>
-   
-     <xs:attribute name="externalImportIndicator">
-       <xs:annotation>
-         <xs:documentation>The externalImportIndicator attribute is true if and only if a namespace identified via xs:import is expected to be non-conformant.</xs:documentation>
-       </xs:annotation>
-       <xs:simpleType>
-         <xs:restriction base="xs:boolean">
-           <xs:pattern value="true"/>
-         </xs:restriction>
-       </xs:simpleType>
-     </xs:attribute>
-   
-     </xs:schema>
-   
-
-Appendix D. Local terminology namespace
-
-   <?xml version="1.0" encoding="US-ASCII"?>
-   <xs:schema
-      elementFormDefault="qualified" 
-      targetNamespace="http://release.niem.gov/niem/localTerminology/3.0/"
-      version="1"
-      xmlns:term="http://release.niem.gov/niem/localTerminology/3.0/"
-      xmlns:xs="http://www.w3.org/2001/XMLSchema">
-   
-     <xs:element name="LocalTerm">
-       <xs:complexType>
-         <xs:sequence>
-   	<xs:element name="SourceText" type="termappinfo:NonemptyStringSimpleType" 
-                       minOccurs="0" maxOccurs="unbounded" form="qualified"/>
-         </xs:sequence>
-         <xs:attribute name="term" type="termappinfo:NonemptyStringSimpleType" use="required"/>
-         <xs:attribute name="literal" type="termappinfo:NonemptyStringSimpleType"/>
-         <xs:attribute name="definition" type="termappinfo:NonemptyStringSimpleType"/>
-         <xs:attribute name="sourceURIs">
-           <xs:simpleType>
-             <xs:restriction>
-               <xs:simpleType>
-                 <xs:list itemType="xs:anyURI"/>
-               </xs:simpleType>
-               <xs:minLength value="1"/>
-             </xs:restriction>
-           </xs:simpleType>
-         </xs:attribute>
-       </xs:complexType>
-     </xs:element>
-   
-     <xs:simpleType name="NonemptyStringSimpleType">
-       <xs:restriction base="xs:string">
-         <xs:minLength value="1"/>
-       </xs:restriction>
-     </xs:simpleType>
-   
-   </xs:schema>
-   
-
-Appendix E D. Index of definitions
-
-   The index of definitions is omitted from this edition.
-
-Appendix F E. Index of rules
-
-   Rule 4-1, Schema marked as reference schema document must conform: Section 4.1, Conformance targets defined
-   Rule 4-2, Schema marked as extension schema document must conform: Section 4.1, Conformance targets defined
-   Rule 4-3, Schema is CTAS-conformant: Section 4.3, Conformance target identifiers
-   Rule 4-4, Document element has attribute ct:conformanceTargets: Section 4.3, Conformance target identifiers
-   Rule 4-5, Schema claims reference schema conformance target: Section 4.3, Conformance target identifiers
-   Rule 4-6, Schema claims extension conformance target: Section 4.3, Conformance target identifiers
-   Rule 7-1, Document is an XML document: Section 7.1, Conformance to XML
-   Rule 7-2, Document uses XML namespaces properly: Section 7.2, Conformance to XML Namespaces
-   Rule 7-3, Document is a schema document: Section 7.3, Conformance to XML Schema
-   Rule 7-4, Document element is xs:schema: Section 7.3, Conformance to XML Schema
-   Rule 7-5, Component name follows ISO 11179 Part 5 Annex A: Section 7.5, ISO 11179 Part 5
-   Rule 9-1, No base type in the XML namespace: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-2, No base type of xs:ID: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-3, No base type of xs:IDREF: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-4, No base type of xs:IDREFS: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-5, No base type of xs:anyType: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-6, No base type of xs:anySimpleType: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-7, No base type of xs:NOTATION: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-8, No base type of xs:ENTITY: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-9, No base type of xs:ENTITIES: Section 9.1.1.1, Types prohibited as base types
-   Rule 9-10, Simple type definition is top-level: Section 9.1.2, Simple type definition
-   Rule 9-11, No simple type disallowed derivation: Section 9.1.2, Simple type definition
-   Rule 9-12, Simple type has data definition: Section 9.1.2, Simple type definition
-   Rule 9-13, No list item type of xs:ID: Section 9.1.2.1, Simple types prohibited as list item types
-   Rule 9-14, No list item type of xs:IDREF: Section 9.1.2.1, Simple types prohibited as list item types
-   Rule 9-15, No list item type of xs:anySimpleType: Section 9.1.2.1, Simple types prohibited as list item types
-   Rule 9-16, No list item type of xs:ENTITY: Section 9.1.2.1, Simple types prohibited as list item types
-   Rule 9-17, No union member types of xs:ID: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-18, No union member types of xs:IDREF: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-19, No union member types of xs:IDREFS: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-20, No union member types of xs:anySimpleType: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-21, No union member types of xs:ENTITY: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-22, No union member types of xs:ENTITIES: Section 9.1.2.2, Simple types prohibited as union member types
-   Rule 9-23, Enumeration has data definition: Section 9.1.2, Simple type definition
-   Rule 9-24, Complex type definitions is top-level: Section 9.1.3, Complex type definition
-   Rule 9-25, Complex type has data definition: Section 9.1.3, Complex type definition
-   Rule 9-26, No mixed content on complex type: Section 9.1.3.1, No mixed content
-   Rule 9-27, No mixed content on complex content: Section 9.1.3.1, No mixed content
-   Rule 9-28, Complex type content is explicitly simple or complex: Section 9.1.3, Complex type definition
-   Rule 9-29, Complex content uses extension: Section 9.1.3.2, Complex content
-   Rule 9-30, Base type of complex type with complex content must have complex content: Section 9.1.3.2.1, Base type of complex type with complex content has complex content
-   Rule 9-31, Base type of complex type with complex content must have complex content: Section 9.1.3.2.1, Base type of complex type with complex content has complex content
-   Rule 9-32, Simple content uses extension: Section 9.1.3.3, Simple content
-   Rule 9-33, No complex type disallowed substitutions: Section 9.1.3, Complex type definition
-   Rule 9-34, No complex type disallowed derivation: Section 9.1.3, Complex type definition
-   Rule 9-35, Element declaration is top-level: Section 9.2.1, Element declaration
-   Rule 9-36, Element declaration has data definition: Section 9.2.1, Element declaration
-   Rule 9-37, Untyped element is abstract: Section 9.2.1, Element declaration
-   Rule 9-38, Element of type xs:anySimpleType is abstract: Section 9.2.1, Element declaration
-   Rule 9-39, Element type not in the XML Schema namespace: Section 9.2.1, Element declaration
-   Rule 9-40, Element type not in the XML namespace: Section 9.2.1, Element declaration
-   Rule 9-41, Element type is not simple type: Section 9.2.1, Element declaration
-   Rule 9-42, No element disallowed substitutions : Section 9.2.1, Element declaration
-   Rule 9-43, No element disallowed derivation: Section 9.2.1, Element declaration
-   Rule 9-44, No element default value: Section 9.2.1.1, No element value constraints
-   Rule 9-45, No element fixed value: Section 9.2.1.1, No element value constraints
-   Rule 9-46, Element declaration is nillable: Section 9.2.1, Element declaration
-   Rule 9-47, Attribute declaration is top-level: Section 9.2.3, Attribute declaration
-   Rule 9-48, Attribute declaration has data definition: Section 9.2.3, Attribute declaration
-   Rule 9-49, Attribute declaration has type: Section 9.2.3, Attribute declaration
-   Rule 9-50, No attribute type of xs:ID: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-51, No attribute type of xs:IDREF: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-52, No attribute type of xs:IDREFS: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-53, No attribute type of xs:ENTITY: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-54, No attribute type of xs:ENTITIES: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-55, No attribute type of xs:anySimpleType: Section 9.2.3.1, Prohibited attribute types
-   Rule 9-56, No attribute default values: Section 9.2.3.2, No attribute value constraints
-   Rule 9-57, No attribute fixed values: Section 9.2.3.2, No attribute value constraints
-   Rule 9-58, No use of element xs:notation: Section 9.2.4, Notation declaration
-   Rule 9-59, Model group does not affect meaning: Section 9.3.1, Model group
-   Rule 9-60, No xs:all: Section 9.3.1, Model group
-   Rule 9-61, xs:sequence must be child of xs:extension: Section 9.3.1.1, Sequence
-   Rule 9-62, xs:sequence must be child of xs:extension or xs:restriction: Section 9.3.1.1, Sequence
-   Rule 9-63, No xs:choice: Section 9.3.1.2, Choice
-   Rule 9-64, xs:choice must be child of xs:sequence: Section 9.3.1.2, Choice
-   Rule 9-65, Sequence has minimum cardinality 1: Section 9.3.2.1, Sequence cardinality
-   Rule 9-66, Sequence has maximum cardinality 1: Section 9.3.2.1, Sequence cardinality
-   Rule 9-67, Choice has minimum cardinality 1: Section 9.3.2.2, Choice cardinality
-   Rule 9-68, Choice has maximum cardinality 1: Section 9.3.2.2, Choice cardinality
-   Rule 9-69, No use of xs:any: Section 9.3.4, Wildcard
-   Rule 9-70, No use of xs:anyAttribute: Section 9.3.4, Wildcard
-   Rule 9-71, No use of xs:unique: Section 9.4, Identity-constraint definition components
-   Rule 9-72, No use of xs:key: Section 9.4, Identity-constraint definition components
-   Rule 9-73, No use of xs:keyref: Section 9.4, Identity-constraint definition components
-   Rule 9-74, No use of xs:group: Section 9.5.1, Model group definition
-   Rule 9-75, No definition of attribute groups: Section 9.5.2, Attribute group definition
-   Rule 9-76, Comment is not recommended: Section 9.6, Annotation components
-   Rule 9-77, Documentation element has no element children: Section 9.6, Annotation components
-   Rule 9-78, xs:appinfo children are comments, elements, or whitespace: Section 9.6.1, Application information annotation
-   Rule 9-79, Appinfo child elements have namespaces: Section 9.6.1, Application information annotation
-   Rule 9-80, Appinfo descendants are not XML Schema elements: Section 9.6.1, Application information annotation
-   Rule 9-81, Schema has data definition: Section 9.7, Schema as a whole
-   Rule 9-82, Schema document defines target namespace: Section 9.7, Schema as a whole
-   Rule 9-83, Target namespace is absolute URI: Section 9.7, Schema as a whole
-   Rule 9-84, Schema has version: Section 9.7, Schema as a whole
-   Rule 9-85, No disallowed substitutions: Section 9.7, Schema as a whole
-   Rule 9-86, No disallowed derivations: Section 9.7, Schema as a whole
-   Rule 9-87, No use of xs:redefine: Section 9.8, Schema assembly
-   Rule 9-88, No use of xs:include: Section 9.8, Schema assembly
-   Rule 9-89, xs:import must have namespace: Section 9.8, Schema assembly
-   Rule 9-90, XML Schema document set must be complete: Section 9.8, Schema assembly
-   Rule 9-91, Namespace referenced by attribute type is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 9-92, Namespace referenced by attribute base is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 9-93, Namespace referenced by attribute itemType is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 9-94, Namespaces referenced by attribute memberTypes is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 9-95, Namespace referenced by attribute ref is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 9-96, Namespace referenced by attribute substitutionGroup is imported: Section 9.8.1, Namespaces for referenced components are imported
-   Rule 10-1, Complex type has a category: Section 10.1, Categories of NIEM type definitions
-   Rule 10-2, Object type with complex content is derived from object type: Section 10.2.1.1, Object types with complex content
-   Rule 10-3, RoleOf element type is an object type: Section 10.2.2, Role types and roles
-   Rule 10-4, Only object type has RoleOf element: Section 10.2.2, Role types and roles
-   Rule 10-5, RoleOf elements indicate the base types of a role type: Section 10.2.2, Role types and roles
-   Rule 10-6, Instance of RoleOf element indicates a role object: Section 10.2.2, Role types and roles
-   Rule 10-7, Import of external namespace has data definition: Section 10.2.3.1, Import of external namespace
-   Rule 10-8, External adapter type has indicator: Section 10.2.3.2, External adapter types
-   Rule 10-9, Structure of external adapter type definition follows pattern: Section 10.2.3.2, External adapter types
-   Rule 10-10, Element use from external adapter type defined by external schema documents: Section 10.2.3.2, External adapter types
-   Rule 10-11, External adapter type not a base type: Section 10.2.3.2, External adapter types
-   Rule 10-12, External adapter type not a base type: Section 10.2.3.2, External adapter types
-   Rule 10-13, External attribute use only in external adapter type: Section 10.2.3.3, External attribute use
-   Rule 10-14, External attribute use has data definition: Section 10.2.3.3, External attribute use
-   Rule 10-15, External attribute use not an ID: Section 10.2.3.3, External attribute use
-   Rule 10-16, External element use has data definition: Section 10.2.3.4, External element use
-   Rule 10-17, Name of code type ends in "CodeType": Section 10.2.4, Code types
-   Rule 10-18, Proxy type has designated structure: Section 10.2.5, Proxy types
-   Rule 10-19, Association types type is derived from association type: Section 10.3.1, Association types
-   Rule 10-20, Association element type is an association type: Section 10.3.2, Association element declarations
-   Rule 10-21, Augmentable type has augmentation point element: Section 10.4.1, Augmentable types
-   Rule 10-22, Augmentable type has at most one augmentation point element: Section 10.4.1, Augmentable types
-   Rule 10-23, Augmentation point corresponds to augmentable type: Section 10.4.2, Augmentation point element declarations
-   Rule 10-24, An augmentation point has no type: Section 10.4.2, Augmentation point element declarations
-   Rule 10-25, An augmentation point has no substitution group: Section 10.4.2, Augmentation point element declarations
-   Rule 10-26, Augmentation point element may only be referenced by its type: Section 10.4.3, Augmentation point element use
-   Rule 10-27, Augmentation point reference is optional: Section 10.4.3, Augmentation point element use
-   Rule 10-28, Augmentation point reference is unbounded: Section 10.4.3, Augmentation point element use
-   Rule 10-29, Augmentation point reference must be last particle: Section 10.4.3, Augmentation point element use
-   Rule 10-30, Element within instance of augmentation type modifies base: Section 10.4.4, Augmentation types
-   Rule 10-31, Only an augmentation type name ends in "AugmentationType": Section 10.4.4, Augmentation types
-   Rule 10-32, Schema component with name ending in "AugmentationType" is an augmentation type: Section 10.4.4, Augmentation types
-   Rule 10-33, Type derived from augmentation type is an augmentation type: Section 10.4.4, Augmentation types
-   Rule 10-34, Augmentation element type is an augmentation type: Section 10.4.5, Augmentation element declarations
-   Rule 10-35, Augmentation elements are not used directly: Section 10.4.5, Augmentation element declarations
-   Rule 10-36, Metadata type has data about data: Section 10.5.1, Metadata types
-   Rule 10-37, Metadata type derived from structures:MetadataType: Section 10.5.1, Metadata types
-   Rule 10-38, Metadata types are derived from metadata types: Section 10.5.1, Metadata types
-   Rule 10-39, Metadata element declaration type is a metadata type: Section 10.5.2, Metadata element declarations
-   Rule 10-40, Metadata element has applicable elements: Section 10.5.2, Metadata element declarations
-   Rule 10-41, Name of element that ends in "Representation" is abstract: Section 10.7, The "Representation" pattern
-   Rule 10-42, A substitution for a representation element declaration is a value for a type: Section 10, Rules for NIEM modeling, by NIEM concept
-   Rule 10-43, Schema component name composed of English words: Section 10.8, Naming rules
-   Rule 10-44, Schema component names have only specific characters: Section 10.8, Naming rules
-   Rule 10-45, Hyphen in component name is a separator: Section 10.8, Naming rules
-   Rule 10-46, Names use camel case: Section 10.8.1, Character case
-   Rule 10-47, Attribute name begins with lower case letter: Section 10.8.1, Character case
-   Rule 10-48, Name of schema component other than attribute begins with upper case letter: Section 10.8.1, Character case
-   Rule 10-49, Names use common abbreviations: Section 10.8.2, Use of acronyms and abbreviations
-   Rule 10-50, Local term declaration is local to its schema document: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon
-   Rule 10-51, Local terminology interpretation: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon
-   Rule 10-52, Singular form is preferred in name: Section 10.8.3, Word forms
-   Rule 10-53, Present tense is preferred in name: Section 10.8.3, Word forms
-   Rule 10-54, Name does not have nonessential words: Section 10.8.3, Word forms
-   Rule 10-55, Component name follows pattern: Section 10.8, Naming rules
-   Rule 10-56, Object-class term identifies concrete category: Section 10.8.4, Object-class term
-   Rule 10-57, Property term describes characteristic or subpart: Section 10.8.5, Property term
-   Rule 10-58, Name may have multiple qualifier terms: Section 10.8.6, Qualifier terms
-   Rule 10-59, Name has minimum necessary number of qualifier terms: Section 10.8.6, Qualifier terms
-   Rule 10-60, Order of qualifies is not significant: Section 10.8.6, Qualifier terms
-   Rule 10-61, Redundant term in name is omitted: Section 10.8.7, Representation terms
-   Rule 10-62, Element with simple content has representation term: Section 10.8.7, Representation terms
-   Rule 10-63, Name has representation term when appropriate: Section 10.8.7, Representation terms
-   Rule 10-64, Name has representation term only when appropriate: Section 10.8.7, Representation terms
-   Rule 10-65, Machine-readable annotations are valid: Section 10.9, Machine-readable annotations
-   Rule 10-66, Component marked as deprecated is deprecated component: Section 10.9.1.1, Deprecation
-   Rule 10-67, Deprecated annotates schema component: Section 10.9.1.1, Deprecation
-   Rule 10-68, External import indicator annotates import: Section 10.9.1, The NIEM appinfo namespace
-   Rule 10-69, External adapter type indicator annotates complex type: Section 10.9.1, The NIEM appinfo namespace
-   Rule 10-70, appinfo:appliesToTypes annotates metadata element: Section 10.9.1.2, appinfo:appliesToTypes annotation
-   Rule 10-71, appinfo:appliesToTypes references types: Section 10.9.1.2, appinfo:appliesToTypes annotation
-   Rule 10-72, appinfo:appliesToElements annotates metadata element: Section 10.9.1.3, appinfo:appliesToElements annotation
-   Rule 10-73, appinfo:appliesToElements references elements: Section 10.9.1.3, appinfo:appliesToElements annotation
-   Rule 10-74, term appinfo:LocalTerm annotates schema: Section 10.9.2, The NIEM local Local terminology namespace
-   Rule 10-75, term appinfo:LocalTerm has literal or definition: Section 10.9.2, The NIEM local Local terminology namespace
-   Rule 10-76, Use structures as specified: Section 10.10, NIEM structural facilities
-   Rule 11-1, Name of type ends in "Type": Section 11.1, Type definition components
-   Rule 11-2, Name of type other than proxy type is in upper camel case: Section 11.1, Type definition components
-   Rule 11-3, Base type definition defined by conformant schema: Section 11.1.1, Type definition hierarchy
-   Rule 11-4, Name of simple type ends in "SimpleType": Section 11.1.2, Simple type definition
-   Rule 11-5, Name of simple type is upper camel case: Section 11.1.2, Simple type definition
-   Rule 11-6, Use lists only when data is uniform: Section 11.1.2.1, Derivation by list
-   Rule 11-7, List item type defined by conformant schemas: Section 11.1.2.1, Derivation by list
-   Rule 11-8, Union member types defined by conformant schemas: Section 11.1.2.2, Derivation by union
-   Rule 11-9, Name of a code simple type has standard suffix: Section 11.1.2.3, Code simple types
-   Rule 11-10, Code simple type has enumerations: Section 11.1.2.3, Code simple types
-   Rule 11-11, Complex type with simple content has structures:SimpleObjectAttributeGroup: Section 11.1.3, Complex type definition
-   Rule 11-12, Element name is upper camel case: Section 11.2.1, Element declaration
-   Rule 11-13, Element type does not have a simple type name: Section 11.2.1, Element declaration
-   Rule 11-14, Element type is from conformant namespace: Section 11.2.1, Element declaration
-   Rule 11-15, Name of element that ends in "Abstract" is abstract: Section 11.2.1, Element declaration
-   Rule 11-16, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations
-   Rule 11-17, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations
-   Rule 11-18, Element substitution group defined by conformant schema: Section 11.2.2, Element substitution group
-   Rule 11-19, Attribute type defined by conformant schema: Section 11.2.3, Attribute declaration
-   Rule 11-20, Attribute name uses representation term: Section 11.2.3, Attribute declaration
-   Rule 11-21, Element or attribute declaration introduced only once into a type: Section 11.3.2.1, Element use
-   Rule 11-22, Element reference defined by conformant schema: Section 11.3.2.1, Element use
-   Rule 11-23, Referenced attribute defined by conformant schemas: Section 11.3.3, Attribute use
-   Rule 11-24, Schema uses only known attribute groups: Section 11.3.3.1, Attribute group use
-   Rule 11-25, Data definition does not introduce ambiguity: Section 11.6.1, Human-readable documentation
-   Rule 11-26, Object class has only one meaning: Section 11.6.1, Human-readable documentation
-   Rule 11-27, Data definition of a part does not redefine the whole: Section 11.6.1, Human-readable documentation
-   Rule 11-28, Do not leak representation into data definition: Section 11.6.1, Human-readable documentation
-   Rule 11-29, Data definition follows 11179-4 requirements: Section 11.6.1, Human-readable documentation
-   Rule 11-30, Data definition follows 11179-4 recommendations: Section 11.6.1, Human-readable documentation
-   Rule 11-31, Standard opening phrase for element: Section 11.6.1.1, Data definition opening phrases
-   Rule 11-32, Standard opening phrase for complex type: Section 11.6.1.1, Data definition opening phrases
-   Rule 11-33, Standard opening phrase for simple type: Section 11.6.1.1, Data definition opening phrases
-   Rule 11-34, Same namespace means same components: Section 11.7.1, xs:schema document element restrictions
-   Rule 11-35, Different version means different view: Section 11.7.1, xs:schema document element restrictions
-   Rule 11-36, Reference schema imports reference schema: Section 11.8, Schema assembly
-   Rule 11-37, Extension schema document imports reference or extension schema: Section 11.8, Schema assembly
-   Rule 11-38, Structures imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant
-   Rule 11-39, XML namespace imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant
-   Rule 11-40, Each namespace may have only a single root schema in a schema set: Section 11.8, Schema assembly
-   Rule 11-41, Consistently marked namespace imports: Section 11.8, Schema assembly
-   Rule 12-1, Instance must be schema-valid: Section 12, XML instance document rules
-   Rule 12-2, Element with structures:ref does not have content: Section 12.2, Reference elements
-   Rule 12-3, Attribute structures:ref must reference structures:id: Section 12.2, Reference elements
-   Rule 12-43, Linked elements have same validation root: Section 12.2, Reference elements
-   Rule 12-54, Attribute structures:ref references element of correct type: Section 12.2, Reference elements
-   Rule 12-65, Reference and content elements have the same meaning: Section 12.2.1, Reference and content elements have same meaning
-   Rule 12-76, Empty content has no meaning: Section 12, XML instance document rules
-   Rule 12-87, Metadata applies to referring entity: Section 12.3, Instance metadata
-   Rule 12-98, Referent of structures:relationshipMetadata annotates relationship: Section 12.3, Instance metadata
-   Rule 12-109, Values of structures:metadata refer to values of structures:id: Section 12.3, Instance metadata
-   Rule 12-1110, Value of structures:relationshipMetadata refers to value of structures:id: Section 12.3, Instance metadata
-   Rule 12-1211, structures:metadata and structures:relationshipMetadata refer to metadata elements: Section 12.3, Instance metadata
-   Rule 12-1312, Attribute structures:metadata references metadata element: Section 12.3, Instance metadata
-   Rule 12-1413, Attribute structures:relationshipMetadata references metadata element: Section 12.3, Instance metadata
-   Rule 12-1514, Metadata is applicable to element: Section 12.3, Instance metadata
-
-Appendix G F. General index
-
-   The index is omitted from this edition.
-
-
-
-

Go back to top

- diff --git a/ndr-functions-interface.xsl b/ndr-functions-interface.xsl deleted file mode 100644 index e64c83c..0000000 --- a/ndr-functions-interface.xsl +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/ndr-functions.xsl b/ndr-functions.xsl index b1bd0d9..172a7c2 100644 --- a/ndr-functions.xsl +++ b/ndr-functions.xsl @@ -1,44 +1,60 @@ - - - + + - - - - - - + + - + + - : impl:get-target-namespace(.): document element is not xs:schema. + : nf:get-target-namespace(): document element is not xs:schema. - + - + + - + - + @@ -64,17 +80,23 @@ - + + - + - + @@ -93,18 +115,23 @@ - + + - + - + - + @@ -121,128 +148,140 @@ - + - - + + + + + + + - + - - - - + + + + - + - + - + - \ No newline at end of file + diff --git a/ndr-id-map.xml b/ndr-id-map.xml index ffafd85..82b4746 100644 --- a/ndr-id-map.xml +++ b/ndr-id-map.xml @@ -26,93 +26,94 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ruleID="rule_9-39"/> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + @@ -130,49 +131,51 @@ - - + + + - - - - - - - - - - - - + + + + + + + + + + + + + ruleID="rule_10-35"/> - - - + ruleID="rule_10-36"/> + + + + ruleID="rule_10-40"/> - - - - + ruleID="rule_10-41"/> + + - + - - - - - + + + + + @@ -181,80 +184,99 @@ - + - + - + + + + ruleID="rule_10-70"/> + ruleID="rule_10-71"/> - - - - - - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + - - + ruleID="rule_12-5"/> - - - + + + - - + + + + + + diff --git a/ndr-rules-conformance-target-ext.sch b/ndr-rules-conformance-target-ext.sch index dd0f035..7963245 100644 --- a/ndr-rules-conformance-target-ext.sch +++ b/ndr-rules-conformance-target-ext.sch @@ -1,4 +1,8 @@ -Rules for extension XML Schema documents + + Rules for extension XML Schema documents + + + @@ -6,14 +10,7 @@ - -Schema is CTAS-conformant - - Rule 4-3: The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - - - Document element has attribute ct:conformanceTargets Rule 4-4: The [document element] of the XML document, and only the [document element], MUST own an attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets. @@ -26,24 +23,6 @@ -Document is an XML document - - Rule 7-1: The document MUST be an XML document. - - - -Document uses XML namespaces properly - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - -Document is a schema document - - Rule 7-3: The document MUST be a schema document. - - - Document element is xs:schema Rule 7-4: The [document element] of the XML document MUST have the name xs:schema. @@ -116,411 +95,409 @@ -No list item type of xs:ID +No list item type of xs:ID - Rule 9-13: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. + Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. -No list item type of xs:IDREF +No list item type of xs:IDREF - Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. + Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. -No list item type of xs:anySimpleType +No list item type of xs:anySimpleType - Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. + Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. -No list item type of xs:ENTITY +No list item type of xs:ENTITY - Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. + Rule 9-17: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. -No union member types of xs:ID +No union member types of xs:ID - Rule 9-17: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. + Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. -No union member types of xs:IDREF +No union member types of xs:IDREF - Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. + Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. -No union member types of xs:IDREFS +No union member types of xs:IDREFS - Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. + Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. -No union member types of xs:anySimpleType +No union member types of xs:anySimpleType - Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. + Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. -No union member types of xs:ENTITY +No union member types of xs:ENTITY - Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. + Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. -No union member types of xs:ENTITIES +No union member types of xs:ENTITIES - Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. + Rule 9-23: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. -Enumeration has data definition +Enumeration has data definition - Rule 9-23: An enumeration facet MUST have a data definition. + Rule 9-24: An enumeration facet MUST have a data definition. -Complex type definitions is top-level +Complex type definitions is top-level - Rule 9-24: A complex type definition MUST be top-level. + Rule 9-25: A complex type definition MUST be top-level. -Complex type has data definition +Complex type has data definition - Rule 9-25: A complex type MUST have a data definition. + Rule 9-26: A complex type MUST have a data definition. -No mixed content on complex type +No mixed content on complex type - Rule 9-26: A complex type definition MUST NOT have mixed content. + Rule 9-27: A complex type definition MUST NOT have mixed content. -No mixed content on complex content +No mixed content on complex content - Rule 9-27: A complex type definition with complex content MUST NOT have mixed content. + Rule 9-28: A complex type definition with complex content MUST NOT have mixed content. -Complex type content is explicitly simple or complex +Complex type content is explicitly simple or complex - Rule 9-28: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. + Rule 9-29: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. -Base type of complex type with complex content must have complex content +Base type of complex type with complex content must have complex content - Rule 9-30: The base type of complex type that has complex content MUST be a complex type with complex content. + Rule 9-31: The base type of complex type that has complex content MUST be a complex type with complex content. -Element declaration is top-level +Element declaration is top-level - Rule 9-35: An element declaration MUST be top-level. + Rule 9-36: An element declaration MUST be top-level. -Element declaration has data definition +Element declaration has data definition - Rule 9-36: An element declaration MUST have a data definition. + Rule 9-37: An element declaration MUST have a data definition. -Untyped element is abstract +Untyped element is abstract - Rule 9-37: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". + Rule 9-38: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". -Element of type xs:anySimpleType is abstract +Element of type xs:anySimpleType is abstract - Rule 9-38: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". + Rule 9-39: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". -Element type not in the XML Schema namespace +Element type not in the XML Schema namespace - Rule 9-39: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. + Rule 9-40: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. -Element type not in the XML namespace +Element type not in the XML namespace - Rule 9-40: An element type MUST NOT have a namespace name that is in the XML namespace. + Rule 9-41: An element type MUST NOT have a namespace name that is in the XML namespace. -Element type is not simple type +Element type is not simple type - Rule 9-41: An element type that is not xs:anySimpleType MUST NOT be a simple type. + Rule 9-42: An element type that is not xs:anySimpleType MUST NOT be a simple type. -No element default value +No element default value - Rule 9-44: An element xs:element MUST NOT have an attribute {}default. + Rule 9-45: An element xs:element MUST NOT have an attribute {}default. -No element fixed value +No element fixed value - Rule 9-45: An element xs:element MUST NOT have an attribute {}fixed. + Rule 9-46: An element xs:element MUST NOT have an attribute {}fixed. -Attribute declaration is top-level +Attribute declaration is top-level - Rule 9-47: An attribute declaration MUST be top-level. + Rule 9-48: An attribute declaration MUST be top-level. -Attribute declaration has data definition +Attribute declaration has data definition - Rule 9-48: An attribute declaration MUST have a data definition. + Rule 9-49: An attribute declaration MUST have a data definition. -Attribute declaration has type +Attribute declaration has type - Rule 9-49: A top-level attribute declaration MUST have a type. + Rule 9-50: A top-level attribute declaration MUST have a type. -No attribute type of xs:ID +No attribute type of xs:ID - Rule 9-50: A schema component MUST NOT have an attribute {}type with a value of xs:ID. + Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:ID. -No attribute type of xs:IDREF +No attribute type of xs:IDREF - Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. + Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. -No attribute type of xs:IDREFS +No attribute type of xs:IDREFS - Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. + Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. -No attribute type of xs:ENTITY +No attribute type of xs:ENTITY - Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. + Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. -No attribute type of xs:ENTITIES +No attribute type of xs:ENTITIES - Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. + Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. -No attribute type of xs:anySimpleType +No attribute type of xs:anySimpleType - Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. + Rule 9-56: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. -No attribute default values +No attribute default values - Rule 9-56: An element xs:attribute MUST NOT have an attribute {}default. + Rule 9-57: An element xs:attribute MUST NOT have an attribute {}default. -No attribute fixed values +No attribute fixed values + + Rule 9-58: This rule does not constrain attribute uses that are required + - Rule 9-57: An element xs:attribute MUST NOT have an attribute {}fixed. + Rule 9-58: An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed. -No use of element xs:notation +No use of element xs:notation - Rule 9-58: The schema MUST NOT contain the element xs:notation. + Rule 9-59: The schema MUST NOT contain the element xs:notation. -No xs:all +No xs:all - Rule 9-60: The schema MUST NOT contain the element xs:all + Rule 9-61: The schema MUST NOT contain the element xs:all -xs:sequence must be child of xs:extension or xs:restriction +xs:sequence must be child of xs:extension + or xs:restriction - Rule 9-62: An element xs:sequence MUST be a child of element xs:extension or xs:restriction. + Rule 9-63: An element xs:sequence MUST be a child of element xs:extension or xs:restriction. -xs:choice must be child of xs:sequence +xs:choice must be child of xs:sequence - Rule 9-64: An element xs:choice MUST be a child of element xs:sequence. + Rule 9-65: An element xs:choice MUST be a child of element xs:sequence. -Sequence has minimum cardinality 1 +Sequence has minimum cardinality 1 - Rule 9-65: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-66: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. -Sequence has maximum cardinality 1 +Sequence has maximum cardinality 1 - Rule 9-66: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-67: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. -Choice has minimum cardinality 1 +Choice has minimum cardinality 1 - Rule 9-67: An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-68: An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. -Choice has maximum cardinality 1 +Choice has maximum cardinality 1 - Rule 9-68: An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-69: An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. -No use of xs:unique +No use of xs:unique - Rule 9-71: The schema MUST NOT contain the element xs:unique. + Rule 9-72: The schema MUST NOT contain the element xs:unique. -No use of xs:key +No use of xs:key - Rule 9-72: The schema MUST NOT contain the element xs:key. + Rule 9-73: The schema MUST NOT contain the element xs:key. -No use of xs:keyref +No use of xs:keyref - Rule 9-73: The schema MUST NOT contain the element xs:keyref. + Rule 9-74: The schema MUST NOT contain the element xs:keyref. -No use of xs:group +No use of xs:group - Rule 9-74: The schema MUST NOT contain the element xs:group. + Rule 9-75: The schema MUST NOT contain the element xs:group. -No definition of attribute groups +No definition of attribute groups - Rule 9-75: The schema MUST NOT contain an attribute group definition schema component. + Rule 9-76: The schema MUST NOT contain an attribute group definition schema component. -Comment is not recommended +Comment is not recommended - Rule 9-76: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. + Rule 9-77: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. -Documentation element has no element children +Documentation element has no element children - Rule 9-77: A child of element xs:documentation MUST be text or an XML comment. + Rule 9-78: A child of element xs:documentation MUST be text or an XML comment. -xs:appinfo children are comments, elements, or whitespace +xs:appinfo children are comments, elements, or whitespace - Rule 9-78: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. + Rule 9-79: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. -Appinfo child elements have namespaces +Appinfo child elements have namespaces - Rule 9-79: An element that is a child of xs:appinfo MUST have a namespace name. + Rule 9-80: An element that is a child of xs:appinfo MUST have a namespace name. -Appinfo descendants are not XML Schema elements +Appinfo descendants are not XML Schema elements - Rule 9-80: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. + Rule 9-81: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. -Schema has data definition +Schema has data definition - Rule 9-81: An element xs:schema MUST have a data definition. + Rule 9-82: An element xs:schema MUST have a data definition. -Schema document defines target namespace +Schema document defines target namespace - Rule 9-82: The schema MUST define a target namespace. - - - -Target namespace is absolute URI - - Rule 9-83: The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986. + Rule 9-83: The schema MUST define a target namespace. -Schema has version +Schema has version - Rule 9-84: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. + Rule 9-85: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. -No use of xs:redefine +No use of xs:redefine - Rule 9-87: The schema MUST NOT contain the element xs:redefine. + Rule 9-88: The schema MUST NOT contain the element xs:redefine. -No use of xs:include +No use of xs:include - Rule 9-88: The schema MUST NOT contain the element xs:include. + Rule 9-89: The schema MUST NOT contain the element xs:include. -xs:import must have namespace +xs:import must have namespace - Rule 9-89: An element xs:import MUST have an attribute {}namespace. + Rule 9-90: An element xs:import MUST have an attribute {}namespace. -Namespace referenced by attribute type is imported +Namespace referenced by attribute type is imported - Rule 9-91: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-92: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute base is imported +Namespace referenced by attribute base is imported - Rule 9-92: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-93: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute itemType is imported +Namespace referenced by attribute itemType is imported - Rule 9-93: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-94: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. -Namespaces referenced by attribute memberTypes is imported +Namespaces referenced by attribute memberTypes is imported - Rule 9-94: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-95: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute ref is imported +Namespace referenced by attribute ref is imported - Rule 9-95: The namespace of a component referenced by @ref MUST be the target namespace or be imported. + Rule 9-96: The namespace of a component referenced by @ref MUST be the target namespace or be imported. -Namespace referenced by attribute substitutionGroup is imported +Namespace referenced by attribute substitutionGroup is imported - Rule 9-96: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. + Rule 9-97: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. @@ -579,143 +556,178 @@ Name of code type ends in "CodeType" - - - - Rule 10-17: A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type. + + Rule 10-17: A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'. + + + +Element of code type has code representation term + + Rule 10-19: An element with a type that is a code type SHOULD have a name with representation term "Code" -Proxy type has designated structure +Proxy type has designated structure - Rule 10-18: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. + Rule 10-20: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. -Association type is derived from association type +Association type is derived from association type - Rule 10-19: A type MUST have an association type name if and only if it is derived from an association type. + Rule 10-21: A type MUST have an association type name if and only if it is derived from an association type. -Association element type is an association type +Association element type is an association type - Rule 10-20: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. + Rule 10-22: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. -Augmentable type has at most one augmentation point element +Augmentable type has at most one augmentation point element - Rule 10-22: An augmentable type MUST contain no more than one element use of its augmentation point element. + Rule 10-24: An augmentable type MUST contain no more than one element use of its augmentation point element. -Augmentation point corresponds to augmentable type +Augmentation point corresponds to augmentable type - Rule 10-23: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. + Rule 10-25: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. -An augmentation point has no type +An augmentation point has no type - Rule 10-24: An augmentation point element MUST have no type. + Rule 10-26: An augmentation point element MUST have no type. -An augmentation point has no substitution group +An augmentation point has no substitution group - Rule 10-25: An augmentation point element MUST have no substitution group. + Rule 10-27: An augmentation point element MUST have no substitution group. -Augmentation point element may only be referenced by its type +Augmentation point element may only be referenced by its type - Rule 10-26: An augmentation point element MUST only be referenced by its corresponding type. + Rule 10-28: An augmentation point element MUST only be referenced by its corresponding type. -Augmentation point reference must be last particle +Augmentation point reference must be last particle - Rule 10-29: An augmentation point element particle MUST be the last element occurrence in its content model. + Rule 10-31: An augmentation point element particle MUST be the last element occurrence in its content model. -Schema component with name ending in "AugmentationType" is an augmentation type +Schema component with name ending in "AugmentationType" is an augmentation type - Rule 10-32: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. + Rule 10-34: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. -Type derived from augmentation type is an augmentation type +Type derived from augmentation type is an augmentation type - Rule 10-33: A type definition derived from an augmentation type MUST be an augmentation type definition + Rule 10-35: A type definition derived from an augmentation type MUST be an augmentation type definition -Augmentation element type is an augmentation type +Augmentation element type is an augmentation type - Rule 10-34: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. + Rule 10-36: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. -Metadata types are derived from metadata types +Metadata types are derived from metadata types - Rule 10-38: A type MUST have a metadata type name if an only if it is derived from a metadata type. + Rule 10-40: A type MUST have a metadata type name if an only if it is derived from a metadata type. -Metadata element declaration type is a metadata type +Metadata element declaration type is a metadata type - Rule 10-39: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. + Rule 10-41: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. -Name of element that ends in "Representation" is abstract +Name of element that ends in "Representation" is abstract - Rule 10-41: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". + Rule 10-43: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". -Deprecated annotates schema component +Schema component names have only specific characters + + Rule 10-46: The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period. + + + +Attribute name begins with lower case letter + + Rule 10-49: Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter + ('a'-'z'). + + + +Name of schema component other than attribute and proxy type begins with upper case letter + + Rule 10-50: This rule does not apply to an attribute. + + + Rule 10-50: This rule does not apply to a proxy types. + + + Rule 10-50: Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z'). + + + +Deprecated annotates schema component - Rule 10-67: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. + Rule 10-69: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. -External import indicator annotates import +External import indicator annotates import - Rule 10-68: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. + Rule 10-70: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. + + + +External adapter type indicator annotates complex type + + Rule 10-71: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. -appinfo:appliesToTypes annotates metadata element +appinfo:appliesToTypes annotates metadata element - Rule 10-70: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. + Rule 10-72: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. -appinfo:appliesToElements annotates metadata element +appinfo:appliesToElements annotates metadata element - Rule 10-72: The attribute appinfo:appliesToElements MUST be owned by a metadata element. + Rule 10-74: The attribute appinfo:appliesToElements MUST be owned by a metadata element. -appinfo:LocalTerm annotates schema +appinfo:LocalTerm annotates schema - Rule 10-74: The element appinfo:LocalTerm MUST be application information on an element xs:schema. + Rule 10-76: The element appinfo:LocalTerm MUST be application information on an element xs:schema. -appinfo:LocalTerm has literal or definition +appinfo:LocalTerm has literal or definition - Rule 10-75: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. + Rule 10-77: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. @@ -728,212 +740,233 @@ -Name of type other than proxy type is in upper camel case - - Rule 11-2: The name of a proxy type is not upper camel case. - - - Rule 11-2: A type definition schema component that does not define a proxy type MUST be in upper camel case. - - - -Base type definition defined by conformant schema +Base type definition defined by conformant schema - Rule 11-3: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-2: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. -Name of simple type ends in "SimpleType" +Name of simple type ends in "SimpleType" - Rule 11-4: A simple type definition schema component MUST have a name that ends in "SimpleType". + Rule 11-3: A simple type definition schema component MUST have a name that ends in "SimpleType". -Name of simple type is upper camel case - - Rule 11-5: The name of a simple type definition schema component MUST be upper camel case. - - - -List item type defined by conformant schemas +List item type defined by conformant schemas - Rule 11-7: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-5: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. -Union member types defined by conformant schemas +Union member types defined by conformant schemas - Rule 11-8: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-6: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. -Name of a code simple type has standard suffix +Name of a code simple type has standard suffix - Rule 11-9: A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType". + Rule 11-7: A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType". -Code simple type has enumerations - - Rule 11-10: A code simple type MUST be derived from a code simple type or have an enumeration facet. +Attribute of code simple type has code representation term + + Rule 11-9: An attribute with a type that is a code simple type SHOULD have a name with representation term "Code" -Complex type with simple content has structures:SimpleObjectAttributeGroup +Complex type with simple content has structures:SimpleObjectAttributeGroup - Rule 11-11: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. + Rule 11-10: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. -Element name is upper camel case - - Rule 11-12: The name of an element declaration MUST be upper camel case. - - - -Element type does not have a simple type name +Element type does not have a simple type name - Rule 11-13: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. + Rule 11-11: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. -Element type is from conformant namespace +Element type is from conformant namespace - Rule 11-14: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. + Rule 11-12: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. -Name of element that ends in "Abstract" is abstract - - Rule 11-15: An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true". +Name of element that ends in "Abstract" is abstract + + Rule 11-13: An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true". -Name of element declaration with simple content has representation term +Name of element declaration with simple content has representation term - Rule 11-16: The name of an element declaration that is of simple content MUST use a representation term. + Rule 11-14: The name of an element declaration that is of simple content SHOULD use a representation term. -Element substitution group defined by conformant schema +Element substitution group defined by conformant schema - Rule 11-18: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. + Rule 11-16: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. -Attribute type defined by conformant schema +Attribute type defined by conformant schema - Rule 11-19: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-17: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. -Attribute name uses representation term +Attribute name uses representation term - Rule 11-20: An attribute name MUST end with a representation term. + Rule 11-18: An attribute name SHOULD end with a representation term. -Element reference defined by conformant schema +Element reference defined by conformant schema - Rule 11-22: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. + Rule 11-20: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. -Referenced attribute defined by conformant schemas +Referenced attribute defined by conformant schemas - Rule 11-23: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. + Rule 11-21: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. -Schema uses only known attribute groups +Schema uses only known attribute groups - Rule 11-24: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. + Rule 11-22: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. -Standard opening phrase for element +Standard opening phrase for augmentation point element - Rule 11-31: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + Rule 11-29: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + + +Standard opening phrase for augmentation element - Rule 11-31: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". + Rule 11-30: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". - + + +Standard opening phrase for metadata element + Rule 11-31: The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". - - Rule 11-31: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". + + +Standard opening phrase for association element + + Rule 11-32: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". - - Rule 11-31: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + + +Standard opening phrase for abstract element + + Rule 11-33: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". - - Rule 11-31: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". + + +Standard opening phrase for date element + + Rule 11-34: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". - - Rule 11-31: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". + + +Standard opening phrase for quantity element + + Rule 11-35: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". - - Rule 11-31: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". + + +Standard opening phrase for picture element + + Rule 11-36: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". - - Rule 11-31: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". + + +Standard opening phrase for indicator element + + Rule 11-37: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". - - Rule 11-31: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". + + +Standard opening phrase for identification element + + Rule 11-38: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". - - Rule 11-31: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". + + +Standard opening phrase for name element + + Rule 11-39: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". - - Rule 11-31: The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)". + + +Standard opening phrase for element + + Rule 11-40: The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)". -Standard opening phrase for complex type +Standard opening phrase for association type - Rule 11-32: The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...". + Rule 11-41: The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...". + + +Standard opening phrase for augmentation type - Rule 11-32: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + Rule 11-42: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + + +Standard opening phrase for metadata type - Rule 11-32: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + Rule 11-43: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + + +Standard opening phrase for complex type - Rule 11-32: The data definition for a type SHOULD begin with the standard opening phrase "a data type...". + Rule 11-44: The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...". -Standard opening phrase for simple type +Standard opening phrase for simple type - Rule 11-33: The data definition for a type SHOULD begin with a standard opening phrase "a data type...". + Rule 11-45: The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...". -Structures imported as conformant +Structures imported as conformant - Rule 11-38: An import of the structures namespace MUST NOT be labeled as an external import. + Rule 11-50: An import of the structures namespace MUST NOT be labeled as an external import. -XML namespace imported as conformant +XML namespace imported as conformant - Rule 11-39: An import of the XML namespace MUST NOT be labeled as an external import. + Rule 11-51: An import of the XML namespace MUST NOT be labeled as an external import. -Consistently marked namespace imports +Consistently marked namespace imports - Rule 11-41: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. + Rule 11-53: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. \ No newline at end of file diff --git a/ndr-rules-conformance-target-ext.sch.xsl b/ndr-rules-conformance-target-ext.sch.xsl index 666a5c4..916bcb4 100644 --- a/ndr-rules-conformance-target-ext.sch.xsl +++ b/ndr-rules-conformance-target-ext.sch.xsl @@ -11,7 +11,6 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:appinfo="http://release.niem.gov/niem/appinfo/4.0/" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" - xmlns:term="http://release.niem.gov/niem/appinfo/4.0/" version="2.0"> @@ -183,16 +182,6 @@ - - - - - - rule_4-3 - Schema is CTAS-conformant - - - @@ -201,7 +190,7 @@ Document element has attribute ct:conformanceTargets - + @@ -210,34 +199,7 @@ Schema claims extension conformance target - - - - - - rule_7-1 - Document is an XML document - - - - - - - - rule_7-2 - Document uses XML namespaces properly - - - - - - - - rule_7-3 - Document is a schema document - - - + @@ -246,7 +208,7 @@ Document element is xs:schema - + @@ -255,7 +217,7 @@ No base type in the XML namespace - + @@ -264,7 +226,7 @@ No base type of xs:ID - + @@ -273,7 +235,7 @@ No base type of xs:IDREF - + @@ -282,7 +244,7 @@ No base type of xs:IDREFS - + @@ -291,7 +253,7 @@ No base type of xs:anyType - + @@ -300,7 +262,7 @@ No base type of xs:anySimpleType - + @@ -309,7 +271,7 @@ No base type of xs:NOTATION - + @@ -318,7 +280,7 @@ No base type of xs:ENTITY - + @@ -327,7 +289,7 @@ No base type of xs:ENTITIES - + @@ -336,7 +298,7 @@ Simple type definition is top-level - + @@ -345,619 +307,611 @@ Simple type has data definition - + - rule_9-13 + rule_9-14 No list item type of xs:ID - + - rule_9-14 + rule_9-15 No list item type of xs:IDREF - + - rule_9-15 + rule_9-16 No list item type of xs:anySimpleType - + - rule_9-16 + rule_9-17 No list item type of xs:ENTITY - + - rule_9-17 + rule_9-18 No union member types of xs:ID - + - rule_9-18 + rule_9-19 No union member types of xs:IDREF - + - rule_9-19 + rule_9-20 No union member types of xs:IDREFS - + - rule_9-20 + rule_9-21 No union member types of xs:anySimpleType - + - rule_9-21 + rule_9-22 No union member types of xs:ENTITY - + - rule_9-22 + rule_9-23 No union member types of xs:ENTITIES - + - rule_9-23 + rule_9-24 Enumeration has data definition - + - rule_9-24 + rule_9-25 Complex type definitions is top-level - + - rule_9-25 + rule_9-26 Complex type has data definition - + - rule_9-26 + rule_9-27 No mixed content on complex type - + - rule_9-27 + rule_9-28 No mixed content on complex content - + - rule_9-28 + rule_9-29 Complex type content is explicitly simple or complex - + - rule_9-30 + rule_9-31 Base type of complex type with complex content must have complex content - + - rule_9-35 + rule_9-36 Element declaration is top-level - + - rule_9-36 + rule_9-37 Element declaration has data definition - + - rule_9-37 + rule_9-38 Untyped element is abstract - + - rule_9-38 + rule_9-39 Element of type xs:anySimpleType is abstract - + - rule_9-39 + rule_9-40 Element type not in the XML Schema namespace - + - rule_9-40 + rule_9-41 Element type not in the XML namespace - + - rule_9-41 + rule_9-42 Element type is not simple type - + - rule_9-44 + rule_9-45 No element default value - + - rule_9-45 + rule_9-46 No element fixed value - + - rule_9-47 + rule_9-48 Attribute declaration is top-level - + - rule_9-48 + rule_9-49 Attribute declaration has data definition - + - rule_9-49 + rule_9-50 Attribute declaration has type - + - rule_9-50 + rule_9-51 No attribute type of xs:ID - + - rule_9-51 + rule_9-52 No attribute type of xs:IDREF - + - rule_9-52 + rule_9-53 No attribute type of xs:IDREFS - + - rule_9-53 + rule_9-54 No attribute type of xs:ENTITY - + - rule_9-54 + rule_9-55 No attribute type of xs:ENTITIES - + - rule_9-55 + rule_9-56 No attribute type of xs:anySimpleType - + - rule_9-56 + rule_9-57 No attribute default values - + - rule_9-57 + rule_9-58 No attribute fixed values - + - rule_9-58 + rule_9-59 No use of element xs:notation - + - rule_9-60 + rule_9-61 No xs:all - + - rule_9-62 - xs:sequence must be child of xs:extension or xs:restriction + rule_9-63 + xs:sequence must be child of xs:extension + or xs:restriction - + - rule_9-64 + rule_9-65 xs:choice must be child of xs:sequence - + - rule_9-65 + rule_9-66 Sequence has minimum cardinality 1 - + - rule_9-66 + rule_9-67 Sequence has maximum cardinality 1 - + - rule_9-67 + rule_9-68 Choice has minimum cardinality 1 - + - rule_9-68 + rule_9-69 Choice has maximum cardinality 1 - + - rule_9-71 + rule_9-72 No use of xs:unique - + - rule_9-72 + rule_9-73 No use of xs:key - + - rule_9-73 + rule_9-74 No use of xs:keyref - + - rule_9-74 + rule_9-75 No use of xs:group - + - rule_9-75 + rule_9-76 No definition of attribute groups - + - rule_9-76 + rule_9-77 Comment is not recommended - + - rule_9-77 + rule_9-78 Documentation element has no element children - + - rule_9-78 + rule_9-79 xs:appinfo children are comments, elements, or whitespace - + - rule_9-79 + rule_9-80 Appinfo child elements have namespaces - + - rule_9-80 + rule_9-81 Appinfo descendants are not XML Schema elements - - - - - - rule_9-81 - Schema has data definition - - - + rule_9-82 - Schema document defines target namespace + Schema has data definition - + rule_9-83 - Target namespace is absolute URI + Schema document defines target namespace - + - rule_9-84 + rule_9-85 Schema has version - + - rule_9-87 + rule_9-88 No use of xs:redefine - + - rule_9-88 + rule_9-89 No use of xs:include - + - rule_9-89 + rule_9-90 xs:import must have namespace - + - rule_9-91 + rule_9-92 Namespace referenced by attribute type is imported - + - rule_9-92 + rule_9-93 Namespace referenced by attribute base is imported - + - rule_9-93 + rule_9-94 Namespace referenced by attribute itemType is imported - + - rule_9-94 + rule_9-95 Namespaces referenced by attribute memberTypes is imported - + - rule_9-95 + rule_9-96 Namespace referenced by attribute ref is imported - + - rule_9-96 + rule_9-97 Namespace referenced by attribute substitutionGroup is imported - + @@ -966,7 +920,7 @@ Object type with complex content is derived from object type - + @@ -975,7 +929,7 @@ RoleOf element type is an object type - + @@ -984,7 +938,7 @@ Only object type has RoleOf element - + @@ -993,7 +947,7 @@ Import of external namespace has data definition - + @@ -1002,7 +956,7 @@ Structure of external adapter type definition follows pattern - + @@ -1011,7 +965,7 @@ Element use from external adapter type defined by external schema documents - + @@ -1020,7 +974,7 @@ External adapter type not a base type - + @@ -1029,7 +983,7 @@ External attribute use has data definition - + @@ -1038,7 +992,7 @@ External element use has data definition - + @@ -1047,196 +1001,241 @@ Name of code type ends in "CodeType" - + + + + + + rule_10-19 + Element of code type has code representation term + + + - rule_10-18 + rule_10-20 Proxy type has designated structure - + - rule_10-19 + rule_10-21 Association type is derived from association type - + - rule_10-20 + rule_10-22 Association element type is an association type - + - rule_10-22 + rule_10-24 Augmentable type has at most one augmentation point element - + - rule_10-23 + rule_10-25 Augmentation point corresponds to augmentable type - + - rule_10-24 + rule_10-26 An augmentation point has no type - + - rule_10-25 + rule_10-27 An augmentation point has no substitution group - + - rule_10-26 + rule_10-28 Augmentation point element may only be referenced by its type - + - rule_10-29 + rule_10-31 Augmentation point reference must be last particle - + - rule_10-32 + rule_10-34 Schema component with name ending in "AugmentationType" is an augmentation type - + - rule_10-33 + rule_10-35 Type derived from augmentation type is an augmentation type - + - rule_10-34 + rule_10-36 Augmentation element type is an augmentation type - + - rule_10-38 + rule_10-40 Metadata types are derived from metadata types - + - rule_10-39 + rule_10-41 Metadata element declaration type is a metadata type - + - rule_10-41 + rule_10-43 Name of element that ends in "Representation" is abstract - + + + + + + rule_10-46 + Schema component names have only specific characters + + + + + + + + rule_10-49 + Attribute name begins with lower case letter + + + + + + + + rule_10-50 + Name of schema component other than attribute and proxy type begins with upper case letter + + + - rule_10-67 + rule_10-69 Deprecated annotates schema component - + - rule_10-68 + rule_10-70 External import indicator annotates import - + - rule_10-70 - appinfo:appliesToTypes annotates metadata element + rule_10-71 + External adapter type indicator annotates complex type - + rule_10-72 - appinfo:appliesToElements annotates metadata element + appinfo:appliesToTypes annotates metadata element - + rule_10-74 + appinfo:appliesToElements annotates metadata element + + + + + + + + rule_10-76 appinfo:LocalTerm annotates schema - + - rule_10-75 + rule_10-77 appinfo:LocalTerm has literal or definition - + @@ -1245,22 +1244,31 @@ Name of type ends in "Type" - + rule_11-2 - Name of type other than proxy type is in upper camel case + Base type definition defined by conformant schema - + rule_11-3 - Base type definition defined by conformant schema + Name of simple type ends in "SimpleType" + + + + + + + + rule_11-5 + List item type defined by conformant schemas @@ -1268,8 +1276,8 @@ - rule_11-4 - Name of simple type ends in "SimpleType" + rule_11-6 + Union member types defined by conformant schemas @@ -1277,8 +1285,8 @@ - rule_11-5 - Name of simple type is upper camel case + rule_11-7 + Name of a code simple type has standard suffix @@ -1286,8 +1294,8 @@ - rule_11-7 - List item type defined by conformant schemas + rule_11-9 + Attribute of code simple type has code representation term @@ -1295,8 +1303,8 @@ - rule_11-8 - Union member types defined by conformant schemas + rule_11-10 + Complex type with simple content has structures:SimpleObjectAttributeGroup @@ -1304,8 +1312,8 @@ - rule_11-9 - Name of a code simple type has standard suffix + rule_11-11 + Element type does not have a simple type name @@ -1313,8 +1321,8 @@ - rule_11-10 - Code simple type has enumerations + rule_11-12 + Element type is from conformant namespace @@ -1322,8 +1330,8 @@ - rule_11-11 - Complex type with simple content has structures:SimpleObjectAttributeGroup + rule_11-13 + Name of element that ends in "Abstract" is abstract @@ -1331,8 +1339,8 @@ - rule_11-12 - Element name is upper camel case + rule_11-14 + Name of element declaration with simple content has representation term @@ -1340,8 +1348,8 @@ - rule_11-13 - Element type does not have a simple type name + rule_11-16 + Element substitution group defined by conformant schema @@ -1349,8 +1357,8 @@ - rule_11-14 - Element type is from conformant namespace + rule_11-17 + Attribute type defined by conformant schema @@ -1358,8 +1366,8 @@ - rule_11-15 - Name of element that ends in "Abstract" is abstract + rule_11-18 + Attribute name uses representation term @@ -1367,8 +1375,8 @@ - rule_11-16 - Name of element declaration with simple content has representation term + rule_11-20 + Element reference defined by conformant schema @@ -1376,8 +1384,8 @@ - rule_11-18 - Element substitution group defined by conformant schema + rule_11-21 + Referenced attribute defined by conformant schemas @@ -1385,8 +1393,8 @@ - rule_11-19 - Attribute type defined by conformant schema + rule_11-22 + Schema uses only known attribute groups @@ -1394,8 +1402,8 @@ - rule_11-20 - Attribute name uses representation term + rule_11-29 + Standard opening phrase for augmentation point element @@ -1403,8 +1411,8 @@ - rule_11-22 - Element reference defined by conformant schema + rule_11-30 + Standard opening phrase for augmentation element @@ -1412,8 +1420,8 @@ - rule_11-23 - Referenced attribute defined by conformant schemas + rule_11-31 + Standard opening phrase for metadata element @@ -1421,8 +1429,8 @@ - rule_11-24 - Schema uses only known attribute groups + rule_11-32 + Standard opening phrase for association element @@ -1430,8 +1438,8 @@ - rule_11-31 - Standard opening phrase for element + rule_11-33 + Standard opening phrase for abstract element @@ -1439,8 +1447,8 @@ - rule_11-32 - Standard opening phrase for complex type + rule_11-34 + Standard opening phrase for date element @@ -1448,8 +1456,8 @@ - rule_11-33 - Standard opening phrase for simple type + rule_11-35 + Standard opening phrase for quantity element @@ -1457,8 +1465,8 @@ - rule_11-38 - Structures imported as conformant + rule_11-36 + Standard opening phrase for picture element @@ -1466,8 +1474,8 @@ - rule_11-39 - XML namespace imported as conformant + rule_11-37 + Standard opening phrase for indicator element @@ -1475,51 +1483,115 @@ - rule_11-41 - Consistently marked namespace imports + rule_11-38 + Standard opening phrase for identification element - - + + + + + rule_11-39 + Standard opening phrase for name element + + + + + + + + rule_11-40 + Standard opening phrase for element + + + + + + + + rule_11-41 + Standard opening phrase for association type + + + + + + + + rule_11-42 + Standard opening phrase for augmentation type + + + + + + + + rule_11-43 + Standard opening phrase for metadata type + + + + + + + + rule_11-44 + Standard opening phrase for complex type + + + + + + + + rule_11-45 + Standard opening phrase for simple type + + + + + + + + rule_11-50 + Structures imported as conformant + + + + + + + + rule_11-51 + XML namespace imported as conformant + + + + + + + + rule_11-53 + Consistently marked namespace imports + + + + + Rules for extension XML Schema documents - - Schema is CTAS-conformant - - - - - - - - - - - - Rule 4-3: The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - - - - - - - - - Document element has attribute ct:conformanceTargets + mode="M9"> @@ -1536,11 +1608,11 @@ - + - - - + + + @@ -1549,7 +1621,7 @@ + mode="M10"> @@ -1566,89 +1638,11 @@ - - - - - - - - - Document is an XML document - - - - - - - - - - - - Rule 7-1: The document MUST be an XML document. - - - - - - - - - - - Document uses XML namespaces properly - - - - - - - - - - - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - - - - - - - - - Document is a schema document - - - - - - - - - - - - Rule 7-3: The document MUST be a schema document. - - - + - - - + + + @@ -1657,7 +1651,7 @@ + mode="M11"> @@ -1673,18 +1667,18 @@ - + - - - + + + No base type in the XML namespace - + @@ -1700,18 +1694,18 @@ - + - - - + + + No base type of xs:ID - + @@ -1727,18 +1721,18 @@ - + - - - + + + No base type of xs:IDREF - + @@ -1754,18 +1748,18 @@ - + - - - + + + No base type of xs:IDREFS - + @@ -1781,18 +1775,18 @@ - + - - - + + + No base type of xs:anyType - + @@ -1808,18 +1802,18 @@ - + - - - + + + No base type of xs:anySimpleType - + @@ -1835,18 +1829,18 @@ - + - - - + + + No base type of xs:NOTATION - + @@ -1862,18 +1856,18 @@ - + - - - + + + No base type of xs:ENTITY - + @@ -1889,18 +1883,18 @@ - + - - - + + + No base type of xs:ENTITIES - + @@ -1916,18 +1910,18 @@ - + - - - + + + Simple type definition is top-level - + @@ -1943,18 +1937,18 @@ - + - - - + + + Simple type has data definition - + @@ -1970,18 +1964,18 @@ - + - - - + + + - + No list item type of xs:ID - + @@ -1994,22 +1988,22 @@ - Rule 9-13: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. + Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. - + - - - + + + - + No list item type of xs:IDREF - + @@ -2022,22 +2016,22 @@ - Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. + Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. - + - - - + + + - + No list item type of xs:anySimpleType - + @@ -2050,22 +2044,22 @@ - Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. + Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. - + - - - + + + - + No list item type of xs:ENTITY - + @@ -2078,22 +2072,22 @@ - Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. + Rule 9-17: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. - + - - - + + + - + No union member types of xs:ID - + @@ -2106,22 +2100,22 @@ - Rule 9-17: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. + Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. - + - - - + + + - + No union member types of xs:IDREF - + @@ -2134,22 +2128,22 @@ - Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. + Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. - + - - - + + + - + No union member types of xs:IDREFS - + @@ -2162,22 +2156,22 @@ - Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. + Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. - + - - - + + + - + No union member types of xs:anySimpleType - + @@ -2190,22 +2184,22 @@ - Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. + Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. - + - - - + + + - + No union member types of xs:ENTITY - + @@ -2218,22 +2212,22 @@ - Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. + Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. - + - - - + + + - + No union member types of xs:ENTITIES - + @@ -2246,22 +2240,22 @@ - Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. + Rule 9-23: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. - + - - - + + + - + Enumeration has data definition - + @@ -2273,22 +2267,22 @@ - Rule 9-23: An enumeration facet MUST have a data definition. + Rule 9-24: An enumeration facet MUST have a data definition. - + - - - + + + - + Complex type definitions is top-level - + @@ -2300,22 +2294,22 @@ - Rule 9-24: A complex type definition MUST be top-level. + Rule 9-25: A complex type definition MUST be top-level. - + - - - + + + - + Complex type has data definition - + @@ -2327,22 +2321,22 @@ - Rule 9-25: A complex type MUST have a data definition. + Rule 9-26: A complex type MUST have a data definition. - + - - - + + + - + No mixed content on complex type - + @@ -2355,24 +2349,24 @@ - Rule 9-26: A complex type definition MUST NOT have mixed content. + Rule 9-27: A complex type definition MUST NOT have mixed content. - + - - - + + + - + No mixed content on complex content + mode="M37"> @@ -2385,22 +2379,22 @@ - Rule 9-27: A complex type definition with complex content MUST NOT have mixed content. + Rule 9-28: A complex type definition with complex content MUST NOT have mixed content. - + - - - + + + - + Complex type content is explicitly simple or complex - + @@ -2412,24 +2406,24 @@ - Rule 9-28: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. + Rule 9-29: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. - + - - - + + + - + Base type of complex type with complex content must have complex content + mode="M39"> @@ -2442,22 +2436,22 @@ - Rule 9-30: The base type of complex type that has complex content MUST be a complex type with complex content. + Rule 9-31: The base type of complex type that has complex content MUST be a complex type with complex content. - + - - - + + + - + Element declaration is top-level - + @@ -2470,22 +2464,22 @@ - Rule 9-35: An element declaration MUST be top-level. + Rule 9-36: An element declaration MUST be top-level. - + - - - + + + - + Element declaration has data definition - + @@ -2498,24 +2492,24 @@ - Rule 9-36: An element declaration MUST have a data definition. + Rule 9-37: An element declaration MUST have a data definition. - + - - - + + + - + Untyped element is abstract + mode="M42"> @@ -2528,24 +2522,24 @@ - Rule 9-37: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". + Rule 9-38: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". - + - - - + + + - + Element of type xs:anySimpleType is abstract + mode="M43"> @@ -2558,22 +2552,22 @@ - Rule 9-38: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". + Rule 9-39: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". - + - - - + + + - + Element type not in the XML Schema namespace - + @@ -2586,23 +2580,23 @@ - Rule 9-39: An element type that is not xs:anySimpleType MUST NOT have a namespace name Rule 9-40: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. - + - - - + + + - + Element type not in the XML namespace - + @@ -2615,22 +2609,22 @@ - Rule 9-40: An element type MUST NOT have a namespace name that is in the XML namespace. + Rule 9-41: An element type MUST NOT have a namespace name that is in the XML namespace. - + - - - + + + - + Element type is not simple type - + @@ -2642,22 +2636,22 @@ - Rule 9-41: An element type that is not xs:anySimpleType MUST NOT be a simple type. + Rule 9-42: An element type that is not xs:anySimpleType MUST NOT be a simple type. - + - - - + + + - + No element default value - + @@ -2668,22 +2662,22 @@ - Rule 9-44: An element xs:element MUST NOT have an attribute {}default. + Rule 9-45: An element xs:element MUST NOT have an attribute {}default. - + - - - + + + - + No element fixed value - + @@ -2694,22 +2688,22 @@ - Rule 9-45: An element xs:element MUST NOT have an attribute {}fixed. + Rule 9-46: An element xs:element MUST NOT have an attribute {}fixed. - + - - - + + + - + Attribute declaration is top-level - + @@ -2722,22 +2716,22 @@ - Rule 9-47: An attribute declaration MUST be top-level. + Rule 9-48: An attribute declaration MUST be top-level. - + - - - + + + - + Attribute declaration has data definition - + @@ -2750,22 +2744,22 @@ - Rule 9-48: An attribute declaration MUST have a data definition. + Rule 9-49: An attribute declaration MUST have a data definition. - + - - - + + + - + Attribute declaration has type - + @@ -2777,22 +2771,22 @@ - Rule 9-49: A top-level attribute declaration MUST have a type. + Rule 9-50: A top-level attribute declaration MUST have a type. - + - - - + + + - + No attribute type of xs:ID - + @@ -2805,22 +2799,22 @@ - Rule 9-50: A schema component MUST NOT have an attribute {}type with a value of xs:ID. + Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:ID. - + - - - + + + - + No attribute type of xs:IDREF - + @@ -2833,22 +2827,22 @@ - Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. + Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. - + - - - + + + - + No attribute type of xs:IDREFS - + @@ -2861,22 +2855,22 @@ - Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. + Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. - + - - - + + + - + No attribute type of xs:ENTITY - + @@ -2889,22 +2883,22 @@ - Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. + Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. - + - - - + + + - + No attribute type of xs:ENTITIES - + @@ -2917,22 +2911,22 @@ - Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. + Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. - + - - - + + + - + No attribute type of xs:anySimpleType - + @@ -2945,22 +2939,22 @@ - Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. + Rule 9-56: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. - + - - - + + + - + No attribute default values - + @@ -2971,22 +2965,41 @@ - Rule 9-56: An element xs:attribute MUST NOT have an attribute {}default. + Rule 9-57: An element xs:attribute MUST NOT have an attribute {}default. - + - - - + + + - + No attribute fixed values - + + + + + + + + + + Rule 9-58: This rule does not constrain attribute uses that are required + + + + + + + @@ -2997,22 +3010,22 @@ - Rule 9-57: An element xs:attribute MUST NOT have an attribute {}fixed. + Rule 9-58: An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed. - + - - - + + + - + No use of element xs:notation - + @@ -3023,22 +3036,22 @@ - Rule 9-58: The schema MUST NOT contain the element xs:notation. + Rule 9-59: The schema MUST NOT contain the element xs:notation. - + - - - + + + - + No xs:all - + @@ -3049,22 +3062,24 @@ - Rule 9-60: The schema MUST NOT contain the element xs:all + Rule 9-61: The schema MUST NOT contain the element xs:all - + - - - + + + - - xs:sequence must be child of xs:extension or xs:restriction + + xs:sequence must be child of xs:extension + or xs:restriction - + @@ -3076,22 +3091,22 @@ - Rule 9-62: An element xs:sequence MUST be a child of element xs:extension or xs:restriction. + Rule 9-63: An element xs:sequence MUST be a child of element xs:extension or xs:restriction. - + - - - + + + - + xs:choice must be child of xs:sequence - + @@ -3103,22 +3118,22 @@ - Rule 9-64: An element xs:choice MUST be a child of element xs:sequence. + Rule 9-65: An element xs:choice MUST be a child of element xs:sequence. - + - - - + + + - + Sequence has minimum cardinality 1 - + @@ -3130,22 +3145,22 @@ - Rule 9-65: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-66: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + Sequence has maximum cardinality 1 - + @@ -3157,22 +3172,22 @@ - Rule 9-66: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-67: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + Choice has minimum cardinality 1 - + @@ -3184,22 +3199,22 @@ - Rule 9-67: An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-68: An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + Choice has maximum cardinality 1 - + @@ -3211,22 +3226,22 @@ - Rule 9-68: An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-69: An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + No use of xs:unique - + @@ -3237,22 +3252,22 @@ - Rule 9-71: The schema MUST NOT contain the element xs:unique. + Rule 9-72: The schema MUST NOT contain the element xs:unique. - + - - - + + + - + No use of xs:key - + @@ -3263,22 +3278,22 @@ - Rule 9-72: The schema MUST NOT contain the element xs:key. + Rule 9-73: The schema MUST NOT contain the element xs:key. - + - - - + + + - + No use of xs:keyref - + @@ -3289,22 +3304,22 @@ - Rule 9-73: The schema MUST NOT contain the element xs:keyref. + Rule 9-74: The schema MUST NOT contain the element xs:keyref. - + - - - + + + - + No use of xs:group - + @@ -3315,22 +3330,22 @@ - Rule 9-74: The schema MUST NOT contain the element xs:group. + Rule 9-75: The schema MUST NOT contain the element xs:group. - + - - - + + + - + No definition of attribute groups - + @@ -3342,22 +3357,22 @@ - Rule 9-75: The schema MUST NOT contain an attribute group definition schema component. + Rule 9-76: The schema MUST NOT contain an attribute group definition schema component. - + - - - + + + - + Comment is not recommended - + @@ -3366,21 +3381,21 @@ - Rule 9-76: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. + Rule 9-77: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. - + - - - + + + - + Documentation element has no element children - + @@ -3393,22 +3408,22 @@ - Rule 9-77: A child of element xs:documentation MUST be text or an XML comment. + Rule 9-78: A child of element xs:documentation MUST be text or an XML comment. - + - - - + + + - + xs:appinfo children are comments, elements, or whitespace - + @@ -3420,22 +3435,22 @@ - Rule 9-78: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. + Rule 9-79: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. - + - - - + + + - + Appinfo child elements have namespaces - + @@ -3447,22 +3462,22 @@ - Rule 9-79: An element that is a child of xs:appinfo MUST have a namespace name. + Rule 9-80: An element that is a child of xs:appinfo MUST have a namespace name. - + - - - + + + - + Appinfo descendants are not XML Schema elements - + @@ -3473,22 +3488,22 @@ - Rule 9-80: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. + Rule 9-81: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. - + - - - + + + - + Schema has data definition - + @@ -3500,22 +3515,22 @@ - Rule 9-81: An element xs:schema MUST have a data definition. + Rule 9-82: An element xs:schema MUST have a data definition. - + - - - + + + - + Schema document defines target namespace - + @@ -3526,48 +3541,22 @@ - Rule 9-82: The schema MUST define a target namespace. + Rule 9-83: The schema MUST define a target namespace. - - - - - - - - - Target namespace is absolute URI - - - - - - - - - - - - Rule 9-83: The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986. - - - + - - - + + + - + Schema has version - + @@ -3579,22 +3568,22 @@ - Rule 9-84: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. + Rule 9-85: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. - + - - - + + + - + No use of xs:redefine - + @@ -3605,22 +3594,22 @@ - Rule 9-87: The schema MUST NOT contain the element xs:redefine. + Rule 9-88: The schema MUST NOT contain the element xs:redefine. - + - - - + + + - + No use of xs:include - + @@ -3631,22 +3620,22 @@ - Rule 9-88: The schema MUST NOT contain the element xs:include. + Rule 9-89: The schema MUST NOT contain the element xs:include. - + - - - + + + - + xs:import must have namespace - + @@ -3657,22 +3646,22 @@ - Rule 9-89: An element xs:import MUST have an attribute {}namespace. + Rule 9-90: An element xs:import MUST have an attribute {}namespace. - + - - - + + + - + Namespace referenced by attribute type is imported - + @@ -3684,22 +3673,22 @@ - Rule 9-91: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-92: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute base is imported - + @@ -3711,22 +3700,22 @@ - Rule 9-92: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-93: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute itemType is imported - + @@ -3738,22 +3727,22 @@ - Rule 9-93: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-94: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespaces referenced by attribute memberTypes is imported - + @@ -3765,22 +3754,22 @@ - Rule 9-94: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-95: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute ref is imported - + @@ -3792,22 +3781,22 @@ - Rule 9-95: The namespace of a component referenced by @ref MUST be the target namespace or be imported. + Rule 9-96: The namespace of a component referenced by @ref MUST be the target namespace or be imported. - + - - - + + + - + Namespace referenced by attribute substitutionGroup is imported - + @@ -3820,15 +3809,15 @@ - Rule 9-96: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. + Rule 9-97: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. - + - - - + + + @@ -3837,7 +3826,7 @@ + mode="M90"> @@ -3854,11 +3843,11 @@ - + - - - + + + @@ -3867,7 +3856,7 @@ + mode="M91"> @@ -3884,11 +3873,11 @@ - + - - - + + + @@ -3897,7 +3886,7 @@ + mode="M92"> @@ -3914,11 +3903,11 @@ - + - - - + + + @@ -3927,7 +3916,7 @@ + mode="M93"> @@ -3944,11 +3933,11 @@ - + - - - + + + @@ -3957,7 +3946,7 @@ + mode="M94"> @@ -3974,11 +3963,11 @@ - + - - - + + + @@ -3987,7 +3976,7 @@ + mode="M95"> @@ -4004,11 +3993,11 @@ - + - - - + + + @@ -4017,7 +4006,7 @@ + mode="M96"> @@ -4034,11 +4023,11 @@ - + - - - + + + @@ -4047,7 +4036,7 @@ + mode="M97"> @@ -4064,11 +4053,11 @@ - + - - - + + + @@ -4077,7 +4066,7 @@ + mode="M98"> @@ -4094,50 +4083,74 @@ - + - - - + + + Name of code type ends in "CodeType" - - - - + + - - - - - - - - - Rule 10-17: A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type. - - - - + + + + + + + Rule 10-17: A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'. + + + - - - + + + + + + + Element of code type has code representation term + + + + + + + + + + + + Rule 10-19: An element with a type that is a code type SHOULD have a name with representation term "Code" + + + + + + + - + Proxy type has designated structure + mode="M101"> @@ -4150,22 +4163,22 @@ - Rule 10-18: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. + Rule 10-20: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. - - - - - + + + + + - + Association type is derived from association type - + @@ -4181,22 +4194,22 @@ - Rule 10-19: A type MUST have an association type name if and only if it is derived from an association type. + Rule 10-21: A type MUST have an association type name if and only if it is derived from an association type. - + - - - + + + - + Association element type is an association type - + @@ -4209,24 +4222,24 @@ - Rule 10-20: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. + Rule 10-22: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. - + - - - + + + - + Augmentable type has at most one augmentation point element + mode="M104"> - + + test="count(xs:complexContent/xs:extension/xs:sequence/xs:element[ @ref[resolve-QName(., ..) = $augmentation-point-qname]]) le 1"> - Rule 10-22: An augmentable type MUST contain no more than one element use of its augmentation point element. + Rule 10-24: An augmentable type MUST contain no more than one element use of its augmentation point element. - + - - - + + + - + Augmentation point corresponds to augmentable type + mode="M105"> @@ -4272,24 +4285,24 @@ - Rule 10-23: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. + Rule 10-25: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. - + - - - + + + - + An augmentation point has no type + mode="M106"> @@ -4301,24 +4314,24 @@ - Rule 10-24: An augmentation point element MUST have no type. + Rule 10-26: An augmentation point element MUST have no type. - + - - - + + + - + An augmentation point has no substitution group + mode="M107"> @@ -4331,24 +4344,24 @@ - Rule 10-25: An augmentation point element MUST have no substitution group. + Rule 10-27: An augmentation point element MUST have no substitution group. - + - - - + + + - + Augmentation point element may only be referenced by its type + mode="M108"> @@ -4361,24 +4374,24 @@ - Rule 10-26: An augmentation point element MUST only be referenced by its corresponding type. + Rule 10-28: An augmentation point element MUST only be referenced by its corresponding type. - + - - - + + + - + Augmentation point reference must be last particle + mode="M109"> @@ -4391,24 +4404,24 @@ - Rule 10-29: An augmentation point element particle MUST be the last element occurrence in its content model. + Rule 10-31: An augmentation point element particle MUST be the last element occurrence in its content model. - + - - - + + + - + Schema component with name ending in "AugmentationType" is an augmentation type + mode="M110"> @@ -4421,24 +4434,24 @@ - Rule 10-32: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. + Rule 10-34: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. - + - - - + + + - + Type derived from augmentation type is an augmentation type + mode="M111"> @@ -4451,22 +4464,22 @@ - Rule 10-33: A type definition derived from an augmentation type MUST be an augmentation type definition + Rule 10-35: A type definition derived from an augmentation type MUST be an augmentation type definition - + - - - + + + - + Augmentation element type is an augmentation type - + @@ -4479,22 +4492,22 @@ - Rule 10-34: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. + Rule 10-36: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. - + - - - + + + - + Metadata types are derived from metadata types - + @@ -4510,22 +4523,22 @@ - Rule 10-38: A type MUST have a metadata type name if an only if it is derived from a metadata type. + Rule 10-40: A type MUST have a metadata type name if an only if it is derived from a metadata type. - + - - - + + + - + Metadata element declaration type is a metadata type - + @@ -4538,24 +4551,24 @@ - Rule 10-39: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. + Rule 10-41: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. - + - - - + + + - + Name of element that ends in "Representation" is abstract + mode="M115"> @@ -4566,21 +4579,137 @@ - Rule 10-41: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". + Rule 10-43: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". - + - - - + + + - + + Schema component names have only specific characters + + + + + + + + + + + + + + Rule 10-46: The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period. + + + + + + + + + + + + Attribute name begins with lower case letter + + + + + + + + + + + + + + Rule 10-49: Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter + ('a'-'z'). + + + + + + + + + + + + Name of schema component other than attribute and proxy type begins with upper case letter + + + + + + + + + + + + Rule 10-50: This rule does not apply to an attribute. + + + + + + + + + + + + + + + + Rule 10-50: This rule does not apply to a proxy types. + + + + + + + + + + + + + + + + + + Rule 10-50: Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z'). + + + + + + + + + + + Deprecated annotates schema component - + @@ -4593,25 +4722,25 @@ - Rule 10-67: The attribute appinfo:deprecated MUST be owned by an element with a namespace name Rule 10-69: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. - + - - - + + + - + External import indicator annotates import + mode="M120"> @@ -4623,24 +4752,54 @@ - Rule 10-68: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. + Rule 10-70: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. - + - - - + + + + + + + External adapter type indicator annotates complex type + + + + + + + + + + + + + + Rule 10-71: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. + + + + + + + + - + appinfo:appliesToTypes annotates metadata element + mode="M122"> @@ -4653,24 +4812,24 @@ - Rule 10-70: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. + Rule 10-72: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. - + - - - + + + - + appinfo:appliesToElements annotates metadata element + mode="M123"> @@ -4683,22 +4842,22 @@ - Rule 10-72: The attribute appinfo:appliesToElements MUST be owned by a metadata element. + Rule 10-74: The attribute appinfo:appliesToElements MUST be owned by a metadata element. - + - - - + + + - + appinfo:LocalTerm annotates schema - + @@ -4710,22 +4869,22 @@ - Rule 10-74: The element appinfo:LocalTerm MUST be application information on an element xs:schema. + Rule 10-76: The element appinfo:LocalTerm MUST be application information on an element xs:schema. - + - - - + + + - + appinfo:LocalTerm has literal or definition - + @@ -4737,15 +4896,15 @@ - Rule 10-75: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. + Rule 10-77: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. - + - - - + + + @@ -4754,7 +4913,7 @@ + mode="M126"> @@ -4767,13 +4926,13 @@ Rule 11-1: The name of a proxy type does not end in "Type". - + + mode="M126"> @@ -4789,67 +4948,18 @@ - - - - - - - - - Name of type other than proxy type is in upper camel case - - - - - - - - - - - - Rule 11-2: The name of a proxy type is not upper camel case. - - - - - - - - - - - - - - - - - - Rule 11-2: A type definition schema component that does not define a proxy type MUST be in upper camel case. - - - - + - - - + + + - + Base type definition defined by conformant schema - + @@ -4861,22 +4971,22 @@ - Rule 11-3: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-2: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. - + - - - + + + - + Name of simple type ends in "SimpleType" - + @@ -4888,50 +4998,22 @@ - Rule 11-4: A simple type definition schema component MUST have a name that ends in "SimpleType". - - - - - - - - - - - - Name of simple type is upper camel case - - - - - - - - - - - - - - Rule 11-5: The name of a simple type definition schema component MUST be upper camel case. + Rule 11-3: A simple type definition schema component MUST have a name that ends in "SimpleType". - + - - - + + + - + List item type defined by conformant schemas - + - Rule 11-7: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-5: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. - + - - - + + + - + Union member types defined by conformant schemas - + @@ -4974,84 +5056,78 @@ - Rule 11-8: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-6: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. - + - - - + + + - + Name of a code simple type has standard suffix + mode="M131"> - - - - - - - - - Rule 11-9: A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType". - - - - + + + + + + + Rule 11-7: A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType". + + + - - - + + + - - Code simple type has enumerations + + Attribute of code simple type has code representation term - + mode="M132"> + context="xs:attribute[exists(@name) and exists(@type) and ends-with(@type, 'CodeSimpleType')]"/> - - - - - - - - - Rule 11-10: A code simple type MUST be derived from a code simple type or have an enumeration facet. - - - - + + + + + + + Rule 11-9: An attribute with a type that is a code simple type SHOULD have a name with representation term "Code" + + + - - - + + + - + Complex type with simple content has structures:SimpleObjectAttributeGroup + mode="M133"> @@ -5064,50 +5140,22 @@ - Rule 11-11: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. - - - - - - - - - - - - Element name is upper camel case - - - - - - - - - - - - - - Rule 11-12: The name of an element declaration MUST be upper camel case. + Rule 11-10: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. - + - - - + + + - + Element type does not have a simple type name - + @@ -5120,22 +5168,22 @@ - Rule 11-13: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. + Rule 11-11: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. - + - - - + + + - + Element type is from conformant namespace - + @@ -5148,84 +5196,75 @@ - Rule 11-14: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. + Rule 11-12: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. - + - - - + + + - + Name of element that ends in "Abstract" is abstract - - - - - - - - - - - - - Rule 11-15: An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true". - - - - + + + + + + + + + + + Rule 11-13: An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true". + + + - - - + + + - + Name of element declaration with simple content has representation term + mode="M137"> - - - - - - - - - Rule 11-16: The name of an element declaration that is of simple content MUST use a representation term. - - - - + + + + + + + Rule 11-14: The name of an element declaration that is of simple content SHOULD use a representation term. + + + - - - + + + - + Element substitution group defined by conformant schema + mode="M138"> - Rule 11-18: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. + Rule 11-16: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. - + - - - + + + - + Attribute type defined by conformant schema - + - Rule 11-19: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-17: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. - + - - - + + + - + Attribute name uses representation term - + - - - - - - - - - Rule 11-20: An attribute name MUST end with a representation term. - - - - + + + + + + + Rule 11-18: An attribute name SHOULD end with a representation term. + + + - - - + + + - + Element reference defined by conformant schema + mode="M141"> - Rule 11-22: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. + Rule 11-20: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. - + - - - + + + - + Referenced attribute defined by conformant schemas - + @@ -5359,22 +5395,22 @@ - Rule 11-23: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. + Rule 11-21: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. - + - - - + + + - + Schema uses only known attribute groups - + @@ -5387,24 +5423,24 @@ - Rule 11-24: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. + Rule 11-22: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. - + - - - + + + - - Standard opening phrase for element + + Standard opening phrase for augmentation point element + priority="1000" + mode="M144"> @@ -5415,38 +5451,52 @@ - Rule 11-31: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + Rule 11-29: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". - + + + + + + + Standard opening phrase for augmentation element + + priority="1000" + mode="M145"> - + + test="every $phrase in ('supplements ', 'additional information about ') satisfies not(starts-with(lower-case(normalize-space(.)), $phrase))"> - Rule 11-31: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". + Rule 11-30: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". - + + + + + + + Standard opening phrase for metadata element + - + + context="xs:element[ends-with(@name, 'Metadata') and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]"/> @@ -5458,15 +5508,22 @@ Rule 11-31: The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". - + + + + + + + Standard opening phrase for association element + - + + context="xs:element[ends-with(@name, 'Association') and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]"/> @@ -5475,18 +5532,25 @@ - Rule 11-31: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". + Rule 11-32: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". - + + + + + + + Standard opening phrase for abstract element + - + context="xs:element[xs:boolean(@abstract) = true() and not(ends-with(@name, 'AugmentationPoint'))]/xs:annotation/xs:documentation[1]"/> @@ -5495,18 +5559,25 @@ - Rule 11-31: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + Rule 11-33: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + + + + + + + Standard opening phrase for date element - + + context="xs:element[ends-with(@name, 'Date') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5515,18 +5586,25 @@ - Rule 11-31: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". + Rule 11-34: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". - + + + + + + + Standard opening phrase for quantity element + - + + context="xs:element[ends-with(@name, 'Quantity') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5535,18 +5613,25 @@ - Rule 11-31: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". + Rule 11-35: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". - + + + + + + + Standard opening phrase for picture element + - + + context="xs:element[ends-with(@name, 'Picture') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5555,18 +5640,25 @@ - Rule 11-31: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". + Rule 11-36: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". - + + + + + + + Standard opening phrase for indicator element + - + + context="xs:element[ends-with(@name, 'Indicator') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5575,18 +5667,25 @@ - Rule 11-31: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". + Rule 11-37: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". - + + + + + + + Standard opening phrase for identification element + - + + context="xs:element[ends-with(@name, 'Identification') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5595,18 +5694,25 @@ - Rule 11-31: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". + Rule 11-38: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". - + + + + + + + Standard opening phrase for name element + - + + context="xs:element[ends-with(@name, 'Name') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5615,18 +5721,25 @@ - Rule 11-31: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". + Rule 11-39: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". - + + + + + + + + Standard opening phrase for element - + mode="M155"> + context="xs:element[@name and not(ends-with(@name, 'Indicator')) and not(ends-with(@name, 'Augmentation')) and not(ends-with(@name, 'Metadata')) and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -5635,23 +5748,23 @@ - Rule 11-31: The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)". + Rule 11-40: The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)". - + - - - + + + - - Standard opening phrase for complex type + + Standard opening phrase for association type + priority="1000" + mode="M156"> @@ -5662,16 +5775,23 @@ - Rule 11-32: The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...". + Rule 11-41: The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...". - + + + + + + + + Standard opening phrase for augmentation type + priority="1000" + mode="M157"> @@ -5682,16 +5802,23 @@ - Rule 11-32: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + Rule 11-42: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". - + + + + + + + Standard opening phrase for metadata type + + priority="1000" + mode="M158"> @@ -5702,16 +5829,23 @@ - Rule 11-32: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + Rule 11-43: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". - + + + + + + + Standard opening phrase for complex type + + mode="M159"> @@ -5722,23 +5856,23 @@ - Rule 11-32: The data definition for a type SHOULD begin with the standard opening phrase "a data type...". + Rule 11-44: The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...". - + - - - + + + - + Standard opening phrase for simple type + mode="M160"> @@ -5749,23 +5883,23 @@ - Rule 11-33: The data definition for a type SHOULD begin with a standard opening phrase "a data type...". + Rule 11-45: The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...". - + - - - + + + - + Structures imported as conformant + mode="M161"> @@ -5778,24 +5912,24 @@ - Rule 11-38: An import of the structures namespace MUST NOT be labeled as an external import. + Rule 11-50: An import of the structures namespace MUST NOT be labeled as an external import. - + - - - + + + - + XML namespace imported as conformant + mode="M162"> @@ -5808,22 +5942,22 @@ - Rule 11-39: An import of the XML namespace MUST NOT be labeled as an external import. + Rule 11-51: An import of the XML namespace MUST NOT be labeled as an external import. - + - - - + + + - + Consistently marked namespace imports - + @@ -5839,14 +5973,14 @@ - Rule 11-41: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. + Rule 11-53: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. - + - - - + + + diff --git a/ndr-rules-conformance-target-ins.sch b/ndr-rules-conformance-target-ins.sch index bd54bc2..73ea449 100644 --- a/ndr-rules-conformance-target-ins.sch +++ b/ndr-rules-conformance-target-ins.sch @@ -1,4 +1,8 @@ -Rules for instance XML documents + + Rules for instance XML documents + + + @@ -6,36 +10,29 @@ - -Document is an XML document - - Rule 7-1: The document MUST be an XML document. +Element has only one resource identifying attribute + + Rule 12-3: An element MUST NOT have more than one attribute that is structures:id, structures:ref, or structures:uri. - -Document uses XML namespaces properly - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - -Attribute structures:ref must reference structures:id + +Attribute structures:ref must reference structures:id - Rule 12-2: The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document. + Rule 12-4: The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document. -Attribute structures:metadata references metadata element +Attribute structures:metadata references metadata element - Rule 12-12: Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. + Rule 12-16: Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. -Attribute structures:relationshipMetadata references metadata element +Attribute structures:relationshipMetadata references metadata element - Rule 12-13: Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. + Rule 12-17: Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. \ No newline at end of file diff --git a/ndr-rules-conformance-target-ins.sch.xsl b/ndr-rules-conformance-target-ins.sch.xsl index 65f1385..358909b 100644 --- a/ndr-rules-conformance-target-ins.sch.xsl +++ b/ndr-rules-conformance-target-ins.sch.xsl @@ -11,7 +11,6 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:appinfo="http://release.niem.gov/niem/appinfo/4.0/" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" - xmlns:term="http://release.niem.gov/niem/appinfo/4.0/" version="2.0"> @@ -183,52 +182,42 @@ - - rule_7-1 - Document is an XML document + rule_12-3 + Element has only one resource identifying attribute - - - - - - rule_7-2 - Document uses XML namespaces properly - - - + - rule_12-2 + rule_12-4 Attribute structures:ref must reference structures:id - + - rule_12-12 + rule_12-16 Attribute structures:metadata references metadata element - + - rule_12-13 + rule_12-17 Attribute structures:relationshipMetadata references metadata element - + @@ -236,63 +225,41 @@ Rules for instance XML documents - - Document is an XML document + + Element has only one resource identifying attribute - + mode="M9"> + context="*[exists(@structures:id) or exists(@structures:ref) or exists(@structures:uri)]"/> - - - - - - - Rule 7-1: The document MUST be an XML document. - - - - - - - - - - - Document uses XML namespaces properly - - - - - - - - - - - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - + + + + + + + + + Rule 12-3: An element MUST NOT have more than one attribute that is structures:id, structures:ref, or structures:uri. + + + + - - - + + + - + Attribute structures:ref must reference structures:id - + @@ -305,22 +272,22 @@ - Rule 12-2: The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document. + Rule 12-4: The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document. - + - - - + + + - + Attribute structures:metadata references metadata element - + @@ -333,24 +300,24 @@ - Rule 12-12: Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. + Rule 12-16: Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. - + - - - + + + - + Attribute structures:relationshipMetadata references metadata element + mode="M12"> @@ -363,14 +330,14 @@ - Rule 12-13: Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. + Rule 12-17: Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element. - + - - - + + + diff --git a/ndr-rules-conformance-target-ref.sch b/ndr-rules-conformance-target-ref.sch index 5be85b3..de8757b 100644 --- a/ndr-rules-conformance-target-ref.sch +++ b/ndr-rules-conformance-target-ref.sch @@ -1,4 +1,8 @@ -Rules for reference XML Schema documents + + Rules for reference XML Schema documents + + + @@ -6,14 +10,7 @@ - -Schema is CTAS-conformant - - Rule 4-3: The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - - - Document element has attribute ct:conformanceTargets Rule 4-4: The [document element] of the XML document, and only the [document element], MUST own an attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets. @@ -26,24 +23,6 @@ -Document is an XML document - - Rule 7-1: The document MUST be an XML document. - - - -Document uses XML namespaces properly - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - -Document is a schema document - - Rule 7-3: The document MUST be a schema document. - - - Document element is xs:schema Rule 7-4: The [document element] of the XML document MUST have the name xs:schema. @@ -122,465 +101,468 @@ -No list item type of xs:ID +No use of "fixed" on simple type facets + + Rule 9-13: A simple type constraining facet MUST NOT have an attribute {}fixed. + + + +No list item type of xs:ID - Rule 9-13: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. + Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. -No list item type of xs:IDREF +No list item type of xs:IDREF - Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. + Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. -No list item type of xs:anySimpleType +No list item type of xs:anySimpleType - Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. + Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. -No list item type of xs:ENTITY +No list item type of xs:ENTITY - Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. + Rule 9-17: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. -No union member types of xs:ID +No union member types of xs:ID - Rule 9-17: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. + Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. -No union member types of xs:IDREF +No union member types of xs:IDREF - Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. + Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. -No union member types of xs:IDREFS +No union member types of xs:IDREFS - Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. + Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. -No union member types of xs:anySimpleType +No union member types of xs:anySimpleType - Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. + Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. -No union member types of xs:ENTITY +No union member types of xs:ENTITY - Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. + Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. -No union member types of xs:ENTITIES +No union member types of xs:ENTITIES - Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. + Rule 9-23: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. -Enumeration has data definition +Enumeration has data definition - Rule 9-23: An enumeration facet MUST have a data definition. + Rule 9-24: An enumeration facet MUST have a data definition. -Complex type definitions is top-level +Complex type definitions is top-level - Rule 9-24: A complex type definition MUST be top-level. + Rule 9-25: A complex type definition MUST be top-level. -Complex type has data definition +Complex type has data definition - Rule 9-25: A complex type MUST have a data definition. + Rule 9-26: A complex type MUST have a data definition. -No mixed content on complex type +No mixed content on complex type - Rule 9-26: A complex type definition MUST NOT have mixed content. + Rule 9-27: A complex type definition MUST NOT have mixed content. -No mixed content on complex content +No mixed content on complex content - Rule 9-27: A complex type definition with complex content MUST NOT have mixed content. + Rule 9-28: A complex type definition with complex content MUST NOT have mixed content. -Complex type content is explicitly simple or complex +Complex type content is explicitly simple or complex - Rule 9-28: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. + Rule 9-29: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. -Complex content uses extension +Complex content uses extension - Rule 9-29: An element xs:complexContent MUST have a child xs:extension. + Rule 9-30: An element xs:complexContent MUST have a child xs:extension. -Base type of complex type with complex content must have complex content +Base type of complex type with complex content must have complex content - Rule 9-30: The base type of complex type that has complex content MUST be a complex type with complex content. + Rule 9-31: The base type of complex type that has complex content MUST be a complex type with complex content. -Simple content uses extension +Simple content uses extension - Rule 9-32: A complex type definition with simple content schema component MUST have a derivation method of extension. + Rule 9-33: A complex type definition with simple content schema component MUST have a derivation method of extension. -No complex type disallowed substitutions +No complex type disallowed substitutions - Rule 9-33: An element xs:complexType MUST NOT have an attribute {}block. + Rule 9-34: An element xs:complexType MUST NOT have an attribute {}block. -No complex type disallowed derivation +No complex type disallowed derivation - Rule 9-34: An element xs:complexType MUST NOT have an attribute {}final. + Rule 9-35: An element xs:complexType MUST NOT have an attribute {}final. -Element declaration is top-level +Element declaration is top-level - Rule 9-35: An element declaration MUST be top-level. + Rule 9-36: An element declaration MUST be top-level. -Element declaration has data definition +Element declaration has data definition - Rule 9-36: An element declaration MUST have a data definition. + Rule 9-37: An element declaration MUST have a data definition. -Untyped element is abstract +Untyped element is abstract - Rule 9-37: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". + Rule 9-38: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". -Element of type xs:anySimpleType is abstract +Element of type xs:anySimpleType is abstract - Rule 9-38: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". + Rule 9-39: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". -Element type not in the XML Schema namespace +Element type not in the XML Schema namespace - Rule 9-39: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. + Rule 9-40: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. -Element type not in the XML namespace +Element type not in the XML namespace - Rule 9-40: An element type MUST NOT have a namespace name that is in the XML namespace. + Rule 9-41: An element type MUST NOT have a namespace name that is in the XML namespace. -Element type is not simple type +Element type is not simple type - Rule 9-41: An element type that is not xs:anySimpleType MUST NOT be a simple type. + Rule 9-42: An element type that is not xs:anySimpleType MUST NOT be a simple type. -No element disallowed substitutions +No element disallowed substitutions - Rule 9-42: An element xs:element MUST NOT have an attribute {}block. + Rule 9-43: An element xs:element MUST NOT have an attribute {}block. -No element disallowed derivation +No element disallowed derivation - Rule 9-43: An element xs:element MUST NOT have an attribute {}final. + Rule 9-44: An element xs:element MUST NOT have an attribute {}final. -No element default value +No element default value - Rule 9-44: An element xs:element MUST NOT have an attribute {}default. + Rule 9-45: An element xs:element MUST NOT have an attribute {}default. -No element fixed value +No element fixed value - Rule 9-45: An element xs:element MUST NOT have an attribute {}fixed. + Rule 9-46: An element xs:element MUST NOT have an attribute {}fixed. -Element declaration is nillable +Element declaration is nillable - Rule 9-46: An element declaration MUST have the {nillable} property with a value of true. + Rule 9-47: An element declaration MUST have the {nillable} property with a value of true. -Attribute declaration is top-level +Attribute declaration is top-level - Rule 9-47: An attribute declaration MUST be top-level. + Rule 9-48: An attribute declaration MUST be top-level. -Attribute declaration has data definition +Attribute declaration has data definition - Rule 9-48: An attribute declaration MUST have a data definition. + Rule 9-49: An attribute declaration MUST have a data definition. -Attribute declaration has type +Attribute declaration has type - Rule 9-49: A top-level attribute declaration MUST have a type. + Rule 9-50: A top-level attribute declaration MUST have a type. -No attribute type of xs:ID +No attribute type of xs:ID - Rule 9-50: A schema component MUST NOT have an attribute {}type with a value of xs:ID. + Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:ID. -No attribute type of xs:IDREF +No attribute type of xs:IDREF - Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. + Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. -No attribute type of xs:IDREFS +No attribute type of xs:IDREFS - Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. + Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. -No attribute type of xs:ENTITY +No attribute type of xs:ENTITY - Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. + Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. -No attribute type of xs:ENTITIES +No attribute type of xs:ENTITIES - Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. + Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. -No attribute type of xs:anySimpleType +No attribute type of xs:anySimpleType - Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. + Rule 9-56: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. -No attribute default values +No attribute default values - Rule 9-56: An element xs:attribute MUST NOT have an attribute {}default. + Rule 9-57: An element xs:attribute MUST NOT have an attribute {}default. -No attribute fixed values +No attribute fixed values + + Rule 9-58: This rule does not constrain attribute uses that are required + - Rule 9-57: An element xs:attribute MUST NOT have an attribute {}fixed. + Rule 9-58: An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed. -No use of element xs:notation +No use of element xs:notation - Rule 9-58: The schema MUST NOT contain the element xs:notation. + Rule 9-59: The schema MUST NOT contain the element xs:notation. -No xs:all +No xs:all - Rule 9-60: The schema MUST NOT contain the element xs:all + Rule 9-61: The schema MUST NOT contain the element xs:all -xs:sequence must be child of xs:extension +xs:sequence must be child of xs:extension - Rule 9-61: An element xs:sequence MUST be a child of element xs:extension. + Rule 9-62: An element xs:sequence MUST be a child of element xs:extension. -No xs:choice +No xs:choice - Rule 9-63: The schema MUST NOT contain the element xs:choice + Rule 9-64: The schema MUST NOT contain the element xs:choice -Sequence has minimum cardinality 1 +Sequence has minimum cardinality 1 - Rule 9-65: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-66: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. -Sequence has maximum cardinality 1 +Sequence has maximum cardinality 1 - Rule 9-66: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-67: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. -No use of xs:any +No use of xs:any - Rule 9-69: The schema MUST NOT contain the element xs:any. + Rule 9-70: The schema MUST NOT contain the element xs:any. -No use of xs:anyAttribute +No use of xs:anyAttribute - Rule 9-70: The schema MUST NOT contain the element xs:anyAttribute. + Rule 9-71: The schema MUST NOT contain the element xs:anyAttribute. -No use of xs:unique +No use of xs:unique - Rule 9-71: The schema MUST NOT contain the element xs:unique. + Rule 9-72: The schema MUST NOT contain the element xs:unique. -No use of xs:key +No use of xs:key - Rule 9-72: The schema MUST NOT contain the element xs:key. + Rule 9-73: The schema MUST NOT contain the element xs:key. -No use of xs:keyref +No use of xs:keyref - Rule 9-73: The schema MUST NOT contain the element xs:keyref. + Rule 9-74: The schema MUST NOT contain the element xs:keyref. -No use of xs:group +No use of xs:group - Rule 9-74: The schema MUST NOT contain the element xs:group. + Rule 9-75: The schema MUST NOT contain the element xs:group. -No definition of attribute groups +No definition of attribute groups - Rule 9-75: The schema MUST NOT contain an attribute group definition schema component. + Rule 9-76: The schema MUST NOT contain an attribute group definition schema component. -Comment is not recommended +Comment is not recommended - Rule 9-76: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. + Rule 9-77: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. -Documentation element has no element children +Documentation element has no element children - Rule 9-77: A child of element xs:documentation MUST be text or an XML comment. + Rule 9-78: A child of element xs:documentation MUST be text or an XML comment. -xs:appinfo children are comments, elements, or whitespace +xs:appinfo children are comments, elements, or whitespace - Rule 9-78: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. + Rule 9-79: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. -Appinfo child elements have namespaces +Appinfo child elements have namespaces - Rule 9-79: An element that is a child of xs:appinfo MUST have a namespace name. + Rule 9-80: An element that is a child of xs:appinfo MUST have a namespace name. -Appinfo descendants are not XML Schema elements +Appinfo descendants are not XML Schema elements - Rule 9-80: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. + Rule 9-81: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. -Schema has data definition +Schema has data definition - Rule 9-81: An element xs:schema MUST have a data definition. + Rule 9-82: An element xs:schema MUST have a data definition. -Schema document defines target namespace +Schema document defines target namespace - Rule 9-82: The schema MUST define a target namespace. - - - -Target namespace is absolute URI - - Rule 9-83: The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986. + Rule 9-83: The schema MUST define a target namespace. -Schema has version +Schema has version - Rule 9-84: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. + Rule 9-85: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. -No disallowed substitutions +No disallowed substitutions - Rule 9-85: An element xs:schema MUST NOT have an attribute {}blockDefault. + Rule 9-86: An element xs:schema MUST NOT have an attribute {}blockDefault. -No disallowed derivations +No disallowed derivations - Rule 9-86: An element xs:schema MUST NOT have an attribute {}finalDefault. + Rule 9-87: An element xs:schema MUST NOT have an attribute {}finalDefault. -No use of xs:redefine +No use of xs:redefine - Rule 9-87: The schema MUST NOT contain the element xs:redefine. + Rule 9-88: The schema MUST NOT contain the element xs:redefine. -No use of xs:include +No use of xs:include - Rule 9-88: The schema MUST NOT contain the element xs:include. + Rule 9-89: The schema MUST NOT contain the element xs:include. -xs:import must have namespace +xs:import must have namespace - Rule 9-89: An element xs:import MUST have an attribute {}namespace. + Rule 9-90: An element xs:import MUST have an attribute {}namespace. -Namespace referenced by attribute type is imported +Namespace referenced by attribute type is imported - Rule 9-91: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-92: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute base is imported +Namespace referenced by attribute base is imported - Rule 9-92: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-93: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute itemType is imported +Namespace referenced by attribute itemType is imported - Rule 9-93: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-94: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. -Namespaces referenced by attribute memberTypes is imported +Namespaces referenced by attribute memberTypes is imported - Rule 9-94: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-95: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. -Namespace referenced by attribute ref is imported +Namespace referenced by attribute ref is imported - Rule 9-95: The namespace of a component referenced by @ref MUST be the target namespace or be imported. + Rule 9-96: The namespace of a component referenced by @ref MUST be the target namespace or be imported. -Namespace referenced by attribute substitutionGroup is imported +Namespace referenced by attribute substitutionGroup is imported - Rule 9-96: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. + Rule 9-97: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. @@ -645,168 +627,197 @@ Name of code type ends in "CodeType" - - - - Rule 10-17: A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type. + + Rule 10-17: A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'. -Proxy type has designated structure +Element of code type has code representation term + + Rule 10-19: An element with a type that is a code type SHOULD have a name with representation term "Code" + + + +Proxy type has designated structure - Rule 10-18: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. + Rule 10-20: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. -Association type is derived from association type +Association type is derived from association type - Rule 10-19: A type MUST have an association type name if and only if it is derived from an association type. + Rule 10-21: A type MUST have an association type name if and only if it is derived from an association type. -Association element type is an association type +Association element type is an association type - Rule 10-20: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. + Rule 10-22: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. -Augmentable type has augmentation point element +Augmentable type has augmentation point element - Rule 10-21: An augmentable type MUST contain an element use of its augmentation point element. + Rule 10-23: An augmentable type MUST contain an element use of its augmentation point element. -Augmentable type has at most one augmentation point element +Augmentable type has at most one augmentation point element - Rule 10-22: An augmentable type MUST contain no more than one element use of its augmentation point element. + Rule 10-24: An augmentable type MUST contain no more than one element use of its augmentation point element. -Augmentation point corresponds to augmentable type +Augmentation point corresponds to augmentable type - Rule 10-23: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. + Rule 10-25: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. -An augmentation point has no type +An augmentation point has no type - Rule 10-24: An augmentation point element MUST have no type. + Rule 10-26: An augmentation point element MUST have no type. -An augmentation point has no substitution group +An augmentation point has no substitution group - Rule 10-25: An augmentation point element MUST have no substitution group. + Rule 10-27: An augmentation point element MUST have no substitution group. -Augmentation point element may only be referenced by its type +Augmentation point element may only be referenced by its type - Rule 10-26: An augmentation point element MUST only be referenced by its corresponding type. + Rule 10-28: An augmentation point element MUST only be referenced by its corresponding type. -Augmentation point reference is optional +Augmentation point reference is optional - Rule 10-27: An augmentation point element particle MUST have attribute minOccurs equal to 0. + Rule 10-29: An augmentation point element particle MUST have attribute minOccurs equal to 0. -Augmentation point reference is unbounded +Augmentation point reference is unbounded - Rule 10-28: An augmentation point element particle MUST have attribute maxOccurs set to unbounded. + Rule 10-30: An augmentation point element particle MUST have attribute maxOccurs set to unbounded. -Augmentation point reference must be last particle +Augmentation point reference must be last particle - Rule 10-29: An augmentation point element particle MUST be the last element occurrence in its content model. + Rule 10-31: An augmentation point element particle MUST be the last element occurrence in its content model. -Schema component with name ending in "AugmentationType" is an augmentation type +Schema component with name ending in "AugmentationType" is an augmentation type - Rule 10-32: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. + Rule 10-34: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. -Type derived from augmentation type is an augmentation type +Type derived from augmentation type is an augmentation type - Rule 10-33: A type definition derived from an augmentation type MUST be an augmentation type definition + Rule 10-35: A type definition derived from an augmentation type MUST be an augmentation type definition -Augmentation element type is an augmentation type +Augmentation element type is an augmentation type - Rule 10-34: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. + Rule 10-36: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. -Metadata types are derived from metadata types +Metadata types are derived from metadata types - Rule 10-38: A type MUST have a metadata type name if an only if it is derived from a metadata type. + Rule 10-40: A type MUST have a metadata type name if an only if it is derived from a metadata type. -Metadata element declaration type is a metadata type +Metadata element declaration type is a metadata type - Rule 10-39: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. + Rule 10-41: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. -Name of element that ends in "Representation" is abstract +Name of element that ends in "Representation" is abstract - Rule 10-41: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". + Rule 10-43: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". -Deprecated annotates schema component +Schema component names have only specific characters + + Rule 10-46: The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period. + + + +Attribute name begins with lower case letter + + Rule 10-49: Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter + ('a'-'z'). + + + +Name of schema component other than attribute and proxy type begins with upper case letter + + Rule 10-50: This rule does not apply to an attribute. + + + Rule 10-50: This rule does not apply to a proxy types. + + + Rule 10-50: Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z'). + + + +Deprecated annotates schema component - Rule 10-67: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. + Rule 10-69: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. -External import indicator annotates import +External import indicator annotates import - Rule 10-68: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. + Rule 10-70: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. -External adapter type indicator annotates complex type +External adapter type indicator annotates complex type - Rule 10-69: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. + Rule 10-71: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. -appinfo:appliesToTypes annotates metadata element +appinfo:appliesToTypes annotates metadata element - Rule 10-70: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. + Rule 10-72: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. -appinfo:appliesToElements annotates metadata element +appinfo:appliesToElements annotates metadata element - Rule 10-72: The attribute appinfo:appliesToElements MUST be owned by a metadata element. + Rule 10-74: The attribute appinfo:appliesToElements MUST be owned by a metadata element. -appinfo:LocalTerm annotates schema +appinfo:LocalTerm annotates schema - Rule 10-74: The element appinfo:LocalTerm MUST be application information on an element xs:schema. + Rule 10-76: The element appinfo:LocalTerm MUST be application information on an element xs:schema. -appinfo:LocalTerm has literal or definition +appinfo:LocalTerm has literal or definition - Rule 10-75: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. + Rule 10-77: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. @@ -819,212 +830,233 @@ -Name of type other than proxy type is in upper camel case - - Rule 11-2: The name of a proxy type is not upper camel case. - - - Rule 11-2: A type definition schema component that does not define a proxy type MUST be in upper camel case. - - - -Base type definition defined by conformant schema +Base type definition defined by conformant schema - Rule 11-3: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-2: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. -Name of simple type ends in "SimpleType" +Name of simple type ends in "SimpleType" - Rule 11-4: A simple type definition schema component MUST have a name that ends in "SimpleType". + Rule 11-3: A simple type definition schema component MUST have a name that ends in "SimpleType". -Name of simple type is upper camel case - - Rule 11-5: The name of a simple type definition schema component MUST be upper camel case. - - - -List item type defined by conformant schemas +List item type defined by conformant schemas - Rule 11-7: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-5: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. -Union member types defined by conformant schemas +Union member types defined by conformant schemas - Rule 11-8: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-6: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. -Name of a code simple type has standard suffix +Name of a code simple type has standard suffix - Rule 11-9: A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType". + Rule 11-7: A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType". -Code simple type has enumerations - - Rule 11-10: A code simple type MUST be derived from a code simple type or have an enumeration facet. +Attribute of code simple type has code representation term + + Rule 11-9: An attribute with a type that is a code simple type SHOULD have a name with representation term "Code" -Complex type with simple content has structures:SimpleObjectAttributeGroup +Complex type with simple content has structures:SimpleObjectAttributeGroup - Rule 11-11: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. + Rule 11-10: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. -Element name is upper camel case - - Rule 11-12: The name of an element declaration MUST be upper camel case. - - - -Element type does not have a simple type name +Element type does not have a simple type name - Rule 11-13: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. + Rule 11-11: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. -Element type is from conformant namespace +Element type is from conformant namespace - Rule 11-14: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. + Rule 11-12: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. -Name of element that ends in "Abstract" is abstract - - Rule 11-15: An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true". +Name of element that ends in "Abstract" is abstract + + Rule 11-13: An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true". -Name of element declaration with simple content has representation term +Name of element declaration with simple content has representation term - Rule 11-16: The name of an element declaration that is of simple content MUST use a representation term. + Rule 11-14: The name of an element declaration that is of simple content SHOULD use a representation term. -Element substitution group defined by conformant schema +Element substitution group defined by conformant schema - Rule 11-18: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. + Rule 11-16: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. -Attribute type defined by conformant schema +Attribute type defined by conformant schema - Rule 11-19: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-17: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. -Attribute name uses representation term +Attribute name uses representation term - Rule 11-20: An attribute name MUST end with a representation term. + Rule 11-18: An attribute name SHOULD end with a representation term. -Element reference defined by conformant schema +Element reference defined by conformant schema - Rule 11-22: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. + Rule 11-20: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. -Referenced attribute defined by conformant schemas +Referenced attribute defined by conformant schemas - Rule 11-23: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. + Rule 11-21: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. -Schema uses only known attribute groups +Schema uses only known attribute groups - Rule 11-24: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. + Rule 11-22: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. -Standard opening phrase for element +Standard opening phrase for augmentation point element - Rule 11-31: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + Rule 11-29: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + + +Standard opening phrase for augmentation element - Rule 11-31: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". + Rule 11-30: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". - + + +Standard opening phrase for metadata element + Rule 11-31: The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". - - Rule 11-31: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". + + +Standard opening phrase for association element + + Rule 11-32: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". - - Rule 11-31: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + + +Standard opening phrase for abstract element + + Rule 11-33: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". - - Rule 11-31: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". + + +Standard opening phrase for date element + + Rule 11-34: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". - - Rule 11-31: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". + + +Standard opening phrase for quantity element + + Rule 11-35: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". - - Rule 11-31: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". + + +Standard opening phrase for picture element + + Rule 11-36: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". - - Rule 11-31: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". + + +Standard opening phrase for indicator element + + Rule 11-37: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". - - Rule 11-31: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". + + +Standard opening phrase for identification element + + Rule 11-38: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". - - Rule 11-31: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". + + +Standard opening phrase for name element + + Rule 11-39: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". - - Rule 11-31: The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)". + + +Standard opening phrase for element + + Rule 11-40: The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)". -Standard opening phrase for complex type +Standard opening phrase for association type - Rule 11-32: The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...". + Rule 11-41: The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...". + + +Standard opening phrase for augmentation type - Rule 11-32: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + Rule 11-42: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + + +Standard opening phrase for metadata type - Rule 11-32: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + Rule 11-43: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + + +Standard opening phrase for complex type - Rule 11-32: The data definition for a type SHOULD begin with the standard opening phrase "a data type...". + Rule 11-44: The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...". -Standard opening phrase for simple type +Standard opening phrase for simple type - Rule 11-33: The data definition for a type SHOULD begin with a standard opening phrase "a data type...". + Rule 11-45: The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...". -Structures imported as conformant +Structures imported as conformant - Rule 11-38: An import of the structures namespace MUST NOT be labeled as an external import. + Rule 11-50: An import of the structures namespace MUST NOT be labeled as an external import. -XML namespace imported as conformant +XML namespace imported as conformant - Rule 11-39: An import of the XML namespace MUST NOT be labeled as an external import. + Rule 11-51: An import of the XML namespace MUST NOT be labeled as an external import. -Consistently marked namespace imports +Consistently marked namespace imports - Rule 11-41: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. + Rule 11-53: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. \ No newline at end of file diff --git a/ndr-rules-conformance-target-ref.sch.xsl b/ndr-rules-conformance-target-ref.sch.xsl index aa5ed13..3505eb5 100644 --- a/ndr-rules-conformance-target-ref.sch.xsl +++ b/ndr-rules-conformance-target-ref.sch.xsl @@ -11,7 +11,6 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:appinfo="http://release.niem.gov/niem/appinfo/4.0/" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" - xmlns:term="http://release.niem.gov/niem/appinfo/4.0/" version="2.0"> @@ -183,16 +182,6 @@ - - - - - - rule_4-3 - Schema is CTAS-conformant - - - @@ -201,7 +190,7 @@ Document element has attribute ct:conformanceTargets - + @@ -210,34 +199,7 @@ Schema claims reference schema conformance target - - - - - - rule_7-1 - Document is an XML document - - - - - - - - rule_7-2 - Document uses XML namespaces properly - - - - - - - - rule_7-3 - Document is a schema document - - - + @@ -246,7 +208,7 @@ Document element is xs:schema - + @@ -255,7 +217,7 @@ No base type in the XML namespace - + @@ -264,7 +226,7 @@ No base type of xs:ID - + @@ -273,7 +235,7 @@ No base type of xs:IDREF - + @@ -282,7 +244,7 @@ No base type of xs:IDREFS - + @@ -291,7 +253,7 @@ No base type of xs:anyType - + @@ -300,7 +262,7 @@ No base type of xs:anySimpleType - + @@ -309,7 +271,7 @@ No base type of xs:NOTATION - + @@ -318,7 +280,7 @@ No base type of xs:ENTITY - + @@ -327,7 +289,7 @@ No base type of xs:ENTITIES - + @@ -336,7 +298,7 @@ Simple type definition is top-level - + @@ -345,7 +307,7 @@ No simple type disallowed derivation - + @@ -354,700 +316,700 @@ Simple type has data definition - + rule_9-13 - No list item type of xs:ID + No use of "fixed" on simple type facets - + rule_9-14 - No list item type of xs:IDREF + No list item type of xs:ID - + rule_9-15 - No list item type of xs:anySimpleType + No list item type of xs:IDREF - + rule_9-16 - No list item type of xs:ENTITY + No list item type of xs:anySimpleType - + rule_9-17 - No union member types of xs:ID + No list item type of xs:ENTITY - + rule_9-18 - No union member types of xs:IDREF + No union member types of xs:ID - + rule_9-19 - No union member types of xs:IDREFS + No union member types of xs:IDREF - + rule_9-20 - No union member types of xs:anySimpleType + No union member types of xs:IDREFS - + rule_9-21 - No union member types of xs:ENTITY + No union member types of xs:anySimpleType - + rule_9-22 - No union member types of xs:ENTITIES + No union member types of xs:ENTITY - + rule_9-23 - Enumeration has data definition + No union member types of xs:ENTITIES - + rule_9-24 - Complex type definitions is top-level + Enumeration has data definition - + rule_9-25 - Complex type has data definition + Complex type definitions is top-level - + rule_9-26 - No mixed content on complex type + Complex type has data definition - + rule_9-27 - No mixed content on complex content + No mixed content on complex type - + rule_9-28 - Complex type content is explicitly simple or complex + No mixed content on complex content - + rule_9-29 - Complex content uses extension + Complex type content is explicitly simple or complex - + rule_9-30 + Complex content uses extension + + + + + + + + rule_9-31 Base type of complex type with complex content must have complex content - + - rule_9-32 + rule_9-33 Simple content uses extension - + - rule_9-33 + rule_9-34 No complex type disallowed substitutions - + - rule_9-34 + rule_9-35 No complex type disallowed derivation - + - rule_9-35 + rule_9-36 Element declaration is top-level - + - rule_9-36 + rule_9-37 Element declaration has data definition - + - rule_9-37 + rule_9-38 Untyped element is abstract - + - rule_9-38 + rule_9-39 Element of type xs:anySimpleType is abstract - + - rule_9-39 + rule_9-40 Element type not in the XML Schema namespace - + - rule_9-40 + rule_9-41 Element type not in the XML namespace - + - rule_9-41 + rule_9-42 Element type is not simple type - + - rule_9-42 + rule_9-43 No element disallowed substitutions - + - rule_9-43 + rule_9-44 No element disallowed derivation - + - rule_9-44 + rule_9-45 No element default value - + - rule_9-45 + rule_9-46 No element fixed value - + - rule_9-46 + rule_9-47 Element declaration is nillable - + - rule_9-47 + rule_9-48 Attribute declaration is top-level - + - rule_9-48 + rule_9-49 Attribute declaration has data definition - + - rule_9-49 + rule_9-50 Attribute declaration has type - + - rule_9-50 + rule_9-51 No attribute type of xs:ID - + - rule_9-51 + rule_9-52 No attribute type of xs:IDREF - + - rule_9-52 + rule_9-53 No attribute type of xs:IDREFS - + - rule_9-53 + rule_9-54 No attribute type of xs:ENTITY - + - rule_9-54 + rule_9-55 No attribute type of xs:ENTITIES - + - rule_9-55 + rule_9-56 No attribute type of xs:anySimpleType - + - rule_9-56 + rule_9-57 No attribute default values - + - rule_9-57 + rule_9-58 No attribute fixed values - + - rule_9-58 + rule_9-59 No use of element xs:notation - + - rule_9-60 + rule_9-61 No xs:all - + - rule_9-61 + rule_9-62 xs:sequence must be child of xs:extension - + - rule_9-63 + rule_9-64 No xs:choice - + - rule_9-65 + rule_9-66 Sequence has minimum cardinality 1 - + - rule_9-66 + rule_9-67 Sequence has maximum cardinality 1 - + - rule_9-69 + rule_9-70 No use of xs:any - - - - - - rule_9-70 - No use of xs:anyAttribute - - - + rule_9-71 - No use of xs:unique + No use of xs:anyAttribute - + rule_9-72 - No use of xs:key + No use of xs:unique - + rule_9-73 - No use of xs:keyref + No use of xs:key - + rule_9-74 - No use of xs:group + No use of xs:keyref - + rule_9-75 - No definition of attribute groups + No use of xs:group - + rule_9-76 - Comment is not recommended + No definition of attribute groups - + rule_9-77 - Documentation element has no element children + Comment is not recommended - + rule_9-78 - xs:appinfo children are comments, elements, or whitespace + Documentation element has no element children - + rule_9-79 - Appinfo child elements have namespaces + xs:appinfo children are comments, elements, or whitespace - + rule_9-80 - Appinfo descendants are not XML Schema elements + Appinfo child elements have namespaces - + rule_9-81 - Schema has data definition + Appinfo descendants are not XML Schema elements - + rule_9-82 - Schema document defines target namespace + Schema has data definition - + rule_9-83 - Target namespace is absolute URI + Schema document defines target namespace - + - rule_9-84 + rule_9-85 Schema has version - + - rule_9-85 + rule_9-86 No disallowed substitutions - + - rule_9-86 + rule_9-87 No disallowed derivations - + - rule_9-87 + rule_9-88 No use of xs:redefine - + - rule_9-88 + rule_9-89 No use of xs:include - + - rule_9-89 + rule_9-90 xs:import must have namespace - + - rule_9-91 + rule_9-92 Namespace referenced by attribute type is imported - + - rule_9-92 + rule_9-93 Namespace referenced by attribute base is imported - + - rule_9-93 + rule_9-94 Namespace referenced by attribute itemType is imported - + - rule_9-94 + rule_9-95 Namespaces referenced by attribute memberTypes is imported - + - rule_9-95 + rule_9-96 Namespace referenced by attribute ref is imported - + - rule_9-96 + rule_9-97 Namespace referenced by attribute substitutionGroup is imported - + @@ -1056,7 +1018,7 @@ Object type with complex content is derived from object type - + @@ -1065,7 +1027,7 @@ RoleOf element type is an object type - + @@ -1074,7 +1036,7 @@ Only object type has RoleOf element - + @@ -1083,7 +1045,7 @@ Import of external namespace has data definition - + @@ -1092,7 +1054,7 @@ Structure of external adapter type definition follows pattern - + @@ -1101,7 +1063,7 @@ Element use from external adapter type defined by external schema documents - + @@ -1110,7 +1072,7 @@ External adapter type not a base type - + @@ -1119,7 +1081,7 @@ External attribute use only in external adapter type - + @@ -1128,7 +1090,7 @@ External attribute use has data definition - + @@ -1137,7 +1099,7 @@ External element use has data definition - + @@ -1146,232 +1108,268 @@ Name of code type ends in "CodeType" - + + + + + + rule_10-19 + Element of code type has code representation term + + + - rule_10-18 + rule_10-20 Proxy type has designated structure - + - rule_10-19 + rule_10-21 Association type is derived from association type - + - rule_10-20 + rule_10-22 Association element type is an association type - + - rule_10-21 + rule_10-23 Augmentable type has augmentation point element - + - rule_10-22 + rule_10-24 Augmentable type has at most one augmentation point element - + - rule_10-23 + rule_10-25 Augmentation point corresponds to augmentable type - + - rule_10-24 + rule_10-26 An augmentation point has no type - + - rule_10-25 + rule_10-27 An augmentation point has no substitution group - + - rule_10-26 + rule_10-28 Augmentation point element may only be referenced by its type - + - rule_10-27 + rule_10-29 Augmentation point reference is optional - + - rule_10-28 + rule_10-30 Augmentation point reference is unbounded - + - rule_10-29 + rule_10-31 Augmentation point reference must be last particle - + - rule_10-32 + rule_10-34 Schema component with name ending in "AugmentationType" is an augmentation type - + - rule_10-33 + rule_10-35 Type derived from augmentation type is an augmentation type - + - rule_10-34 + rule_10-36 Augmentation element type is an augmentation type - + - rule_10-38 + rule_10-40 Metadata types are derived from metadata types - + - rule_10-39 + rule_10-41 Metadata element declaration type is a metadata type - + - rule_10-41 + rule_10-43 Name of element that ends in "Representation" is abstract - + + + + + + rule_10-46 + Schema component names have only specific characters + + + + + + + + rule_10-49 + Attribute name begins with lower case letter + + + + + + + + rule_10-50 + Name of schema component other than attribute and proxy type begins with upper case letter + + + - rule_10-67 + rule_10-69 Deprecated annotates schema component - + - rule_10-68 + rule_10-70 External import indicator annotates import - + - rule_10-69 + rule_10-71 External adapter type indicator annotates complex type - + - rule_10-70 + rule_10-72 appinfo:appliesToTypes annotates metadata element - + - rule_10-72 + rule_10-74 appinfo:appliesToElements annotates metadata element - + - rule_10-74 + rule_10-76 appinfo:LocalTerm annotates schema - + - rule_10-75 + rule_10-77 appinfo:LocalTerm has literal or definition - + @@ -1380,49 +1378,58 @@ Name of type ends in "Type" - + rule_11-2 - Name of type other than proxy type is in upper camel case + Base type definition defined by conformant schema - + rule_11-3 - Base type definition defined by conformant schema + Name of simple type ends in "SimpleType" - + - rule_11-4 - Name of simple type ends in "SimpleType" + rule_11-5 + List item type defined by conformant schemas - + - rule_11-5 - Name of simple type is upper camel case + rule_11-6 + Union member types defined by conformant schemas - + rule_11-7 - List item type defined by conformant schemas + Name of a code simple type has standard suffix + + + + + + + + rule_11-9 + Attribute of code simple type has code representation term @@ -1430,8 +1437,8 @@ - rule_11-8 - Union member types defined by conformant schemas + rule_11-10 + Complex type with simple content has structures:SimpleObjectAttributeGroup @@ -1439,8 +1446,8 @@ - rule_11-9 - Name of a code simple type has standard suffix + rule_11-11 + Element type does not have a simple type name @@ -1448,8 +1455,8 @@ - rule_11-10 - Code simple type has enumerations + rule_11-12 + Element type is from conformant namespace @@ -1457,8 +1464,8 @@ - rule_11-11 - Complex type with simple content has structures:SimpleObjectAttributeGroup + rule_11-13 + Name of element that ends in "Abstract" is abstract @@ -1466,8 +1473,8 @@ - rule_11-12 - Element name is upper camel case + rule_11-14 + Name of element declaration with simple content has representation term @@ -1475,8 +1482,8 @@ - rule_11-13 - Element type does not have a simple type name + rule_11-16 + Element substitution group defined by conformant schema @@ -1484,8 +1491,8 @@ - rule_11-14 - Element type is from conformant namespace + rule_11-17 + Attribute type defined by conformant schema @@ -1493,8 +1500,8 @@ - rule_11-15 - Name of element that ends in "Abstract" is abstract + rule_11-18 + Attribute name uses representation term @@ -1502,8 +1509,8 @@ - rule_11-16 - Name of element declaration with simple content has representation term + rule_11-20 + Element reference defined by conformant schema @@ -1511,8 +1518,8 @@ - rule_11-18 - Element substitution group defined by conformant schema + rule_11-21 + Referenced attribute defined by conformant schemas @@ -1520,8 +1527,8 @@ - rule_11-19 - Attribute type defined by conformant schema + rule_11-22 + Schema uses only known attribute groups @@ -1529,8 +1536,8 @@ - rule_11-20 - Attribute name uses representation term + rule_11-29 + Standard opening phrase for augmentation point element @@ -1538,8 +1545,8 @@ - rule_11-22 - Element reference defined by conformant schema + rule_11-30 + Standard opening phrase for augmentation element @@ -1547,8 +1554,8 @@ - rule_11-23 - Referenced attribute defined by conformant schemas + rule_11-31 + Standard opening phrase for metadata element @@ -1556,8 +1563,8 @@ - rule_11-24 - Schema uses only known attribute groups + rule_11-32 + Standard opening phrase for association element @@ -1565,8 +1572,8 @@ - rule_11-31 - Standard opening phrase for element + rule_11-33 + Standard opening phrase for abstract element @@ -1574,8 +1581,8 @@ - rule_11-32 - Standard opening phrase for complex type + rule_11-34 + Standard opening phrase for date element @@ -1583,8 +1590,8 @@ - rule_11-33 - Standard opening phrase for simple type + rule_11-35 + Standard opening phrase for quantity element @@ -1592,8 +1599,8 @@ - rule_11-38 - Structures imported as conformant + rule_11-36 + Standard opening phrase for picture element @@ -1601,20 +1608,110 @@ - rule_11-39 - XML namespace imported as conformant + rule_11-37 + Standard opening phrase for indicator element + + + + + rule_11-38 + Standard opening phrase for identification element + + + + + + + + rule_11-39 + Standard opening phrase for name element + + + + + + + + rule_11-40 + Standard opening phrase for element + + + rule_11-41 + Standard opening phrase for association type + + + + + + + + rule_11-42 + Standard opening phrase for augmentation type + + + + + + + + rule_11-43 + Standard opening phrase for metadata type + + + + + + + + rule_11-44 + Standard opening phrase for complex type + + + + + + + + rule_11-45 + Standard opening phrase for simple type + + + + + + + + rule_11-50 + Structures imported as conformant + + + + + + + + rule_11-51 + XML namespace imported as conformant + + + + + + + + rule_11-53 Consistently marked namespace imports - + @@ -1622,39 +1719,13 @@ Rules for reference XML Schema documents - - Schema is CTAS-conformant - - - - - - - - - - - - Rule 4-3: The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - - - - - - - - - Document element has attribute ct:conformanceTargets + mode="M9"> @@ -1671,11 +1742,11 @@ - + - - - + + + @@ -1684,7 +1755,7 @@ + mode="M10"> @@ -1701,89 +1772,11 @@ - - - - - - - - - Document is an XML document - - - - - - - - - - - - Rule 7-1: The document MUST be an XML document. - - - - - - - - - - - Document uses XML namespaces properly - - - - - - - - - - - - Rule 7-2: The document MUST be namespace-well-formed and namespace-valid. - - - - - - - - - - - Document is a schema document - - - - - - - - - - - - Rule 7-3: The document MUST be a schema document. - - - + - - - + + + @@ -1792,7 +1785,7 @@ + mode="M11"> @@ -1808,18 +1801,18 @@ - + - - - + + + No base type in the XML namespace - + @@ -1835,18 +1828,18 @@ - + - - - + + + No base type of xs:ID - + @@ -1862,18 +1855,18 @@ - + - - - + + + No base type of xs:IDREF - + @@ -1889,18 +1882,18 @@ - + - - - + + + No base type of xs:IDREFS - + @@ -1916,18 +1909,18 @@ - + - - - + + + No base type of xs:anyType - + @@ -1943,18 +1936,18 @@ - + - - - + + + No base type of xs:anySimpleType - + @@ -1970,18 +1963,18 @@ - + - - - + + + No base type of xs:NOTATION - + @@ -1997,18 +1990,18 @@ - + - - - + + + No base type of xs:ENTITY - + @@ -2024,18 +2017,18 @@ - + - - - + + + No base type of xs:ENTITIES - + @@ -2051,18 +2044,18 @@ - + - - - + + + Simple type definition is top-level - + @@ -2078,18 +2071,18 @@ - + - - - + + + No simple type disallowed derivation - + @@ -2104,18 +2097,18 @@ - + - - - + + + Simple type has data definition - + @@ -2131,18 +2124,47 @@ - + - - - + + + - + + No use of "fixed" on simple type facets + + + + + + + + + + + + + + Rule 9-13: A simple type constraining facet MUST NOT have an attribute {}fixed. + + + + + + + + + + + No list item type of xs:ID - + @@ -2155,22 +2177,22 @@ - Rule 9-13: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. + Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:ID. - + - - - + + + - + No list item type of xs:IDREF - + @@ -2183,22 +2205,22 @@ - Rule 9-14: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. + Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF. - + - - - + + + - + No list item type of xs:anySimpleType - + @@ -2211,22 +2233,22 @@ - Rule 9-15: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. + Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType. - + - - - + + + - + No list item type of xs:ENTITY - + @@ -2239,22 +2261,22 @@ - Rule 9-16: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. + Rule 9-17: A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY. - + - - - + + + - + No union member types of xs:ID - + @@ -2267,22 +2289,22 @@ - Rule 9-17: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. + Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID. - + - - - + + + - + No union member types of xs:IDREF - + @@ -2295,22 +2317,22 @@ - Rule 9-18: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. + Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF. - + - - - + + + - + No union member types of xs:IDREFS - + @@ -2323,22 +2345,22 @@ - Rule 9-19: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. + Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS. - + - - - + + + - + No union member types of xs:anySimpleType - + @@ -2351,22 +2373,22 @@ - Rule 9-20: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. + Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType. - + - - - + + + - + No union member types of xs:ENTITY - + @@ -2379,22 +2401,22 @@ - Rule 9-21: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. + Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY. - + - - - + + + - + No union member types of xs:ENTITIES - + @@ -2407,22 +2429,22 @@ - Rule 9-22: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. + Rule 9-23: A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES. - + - - - + + + - + Enumeration has data definition - + @@ -2434,22 +2456,22 @@ - Rule 9-23: An enumeration facet MUST have a data definition. + Rule 9-24: An enumeration facet MUST have a data definition. - + - - - + + + - + Complex type definitions is top-level - + @@ -2461,22 +2483,22 @@ - Rule 9-24: A complex type definition MUST be top-level. + Rule 9-25: A complex type definition MUST be top-level. - + - - - + + + - + Complex type has data definition - + @@ -2488,22 +2510,22 @@ - Rule 9-25: A complex type MUST have a data definition. + Rule 9-26: A complex type MUST have a data definition. - + - - - + + + - + No mixed content on complex type - + @@ -2516,24 +2538,24 @@ - Rule 9-26: A complex type definition MUST NOT have mixed content. + Rule 9-27: A complex type definition MUST NOT have mixed content. - + - - - + + + - + No mixed content on complex content + mode="M39"> @@ -2546,22 +2568,22 @@ - Rule 9-27: A complex type definition with complex content MUST NOT have mixed content. + Rule 9-28: A complex type definition with complex content MUST NOT have mixed content. - + - - - + + + - + Complex type content is explicitly simple or complex - + @@ -2573,22 +2595,22 @@ - Rule 9-28: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. + Rule 9-29: An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent. - + - - - + + + - + Complex content uses extension - + @@ -2599,24 +2621,24 @@ - Rule 9-29: An element xs:complexContent MUST have a child xs:extension. + Rule 9-30: An element xs:complexContent MUST have a child xs:extension. - + - - - + + + - + Base type of complex type with complex content must have complex content + mode="M42"> @@ -2629,22 +2651,22 @@ - Rule 9-30: The base type of complex type that has complex content MUST be a complex type with complex content. + Rule 9-31: The base type of complex type that has complex content MUST be a complex type with complex content. - + - - - + + + - + Simple content uses extension - + @@ -2655,22 +2677,22 @@ - Rule 9-32: A complex type definition with simple content schema component MUST have a derivation method of extension. + Rule 9-33: A complex type definition with simple content schema component MUST have a derivation method of extension. - + - - - + + + - + No complex type disallowed substitutions - + @@ -2681,22 +2703,22 @@ - Rule 9-33: An element xs:complexType MUST NOT have an attribute {}block. + Rule 9-34: An element xs:complexType MUST NOT have an attribute {}block. - + - - - + + + - + No complex type disallowed derivation - + @@ -2707,22 +2729,22 @@ - Rule 9-34: An element xs:complexType MUST NOT have an attribute {}final. + Rule 9-35: An element xs:complexType MUST NOT have an attribute {}final. - + - - - + + + - + Element declaration is top-level - + @@ -2735,22 +2757,22 @@ - Rule 9-35: An element declaration MUST be top-level. + Rule 9-36: An element declaration MUST be top-level. - + - - - + + + - + Element declaration has data definition - + @@ -2763,24 +2785,24 @@ - Rule 9-36: An element declaration MUST have a data definition. + Rule 9-37: An element declaration MUST have a data definition. - + - - - + + + - + Untyped element is abstract + mode="M48"> @@ -2793,24 +2815,24 @@ - Rule 9-37: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". + Rule 9-38: A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true". - + - - - + + + - + Element of type xs:anySimpleType is abstract + mode="M49"> @@ -2823,22 +2845,22 @@ - Rule 9-38: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". + Rule 9-39: An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true". - + - - - + + + - + Element type not in the XML Schema namespace - + @@ -2851,23 +2873,23 @@ - Rule 9-39: An element type that is not xs:anySimpleType MUST NOT have a namespace name Rule 9-40: An element type that is not xs:anySimpleType MUST NOT have a namespace name xs. - + - - - + + + - + Element type not in the XML namespace - + @@ -2880,22 +2902,22 @@ - Rule 9-40: An element type MUST NOT have a namespace name that is in the XML namespace. + Rule 9-41: An element type MUST NOT have a namespace name that is in the XML namespace. - + - - - + + + - + Element type is not simple type - + @@ -2907,22 +2929,22 @@ - Rule 9-41: An element type that is not xs:anySimpleType MUST NOT be a simple type. + Rule 9-42: An element type that is not xs:anySimpleType MUST NOT be a simple type. - + - - - + + + - + No element disallowed substitutions - + @@ -2933,22 +2955,22 @@ - Rule 9-42: An element xs:element MUST NOT have an attribute {}block. + Rule 9-43: An element xs:element MUST NOT have an attribute {}block. - + - - - + + + - + No element disallowed derivation - + @@ -2959,22 +2981,22 @@ - Rule 9-43: An element xs:element MUST NOT have an attribute {}final. + Rule 9-44: An element xs:element MUST NOT have an attribute {}final. - + - - - + + + - + No element default value - + @@ -2985,22 +3007,22 @@ - Rule 9-44: An element xs:element MUST NOT have an attribute {}default. + Rule 9-45: An element xs:element MUST NOT have an attribute {}default. - + - - - + + + - + No element fixed value - + @@ -3011,24 +3033,24 @@ - Rule 9-45: An element xs:element MUST NOT have an attribute {}fixed. + Rule 9-46: An element xs:element MUST NOT have an attribute {}fixed. - + - - - + + + - + Element declaration is nillable + mode="M57"> @@ -3041,22 +3063,22 @@ - Rule 9-46: An element declaration MUST have the {nillable} property with a value of true. + Rule 9-47: An element declaration MUST have the {nillable} property with a value of true. - + - - - + + + - + Attribute declaration is top-level - + @@ -3069,22 +3091,22 @@ - Rule 9-47: An attribute declaration MUST be top-level. + Rule 9-48: An attribute declaration MUST be top-level. - + - - - + + + - + Attribute declaration has data definition - + @@ -3097,22 +3119,22 @@ - Rule 9-48: An attribute declaration MUST have a data definition. + Rule 9-49: An attribute declaration MUST have a data definition. - + - - - + + + - + Attribute declaration has type - + @@ -3124,22 +3146,22 @@ - Rule 9-49: A top-level attribute declaration MUST have a type. + Rule 9-50: A top-level attribute declaration MUST have a type. - + - - - + + + - + No attribute type of xs:ID - + @@ -3152,22 +3174,22 @@ - Rule 9-50: A schema component MUST NOT have an attribute {}type with a value of xs:ID. + Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:ID. - + - - - + + + - + No attribute type of xs:IDREF - + @@ -3180,22 +3202,22 @@ - Rule 9-51: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. + Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREF. - + - - - + + + - + No attribute type of xs:IDREFS - + @@ -3208,22 +3230,22 @@ - Rule 9-52: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. + Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS. - + - - - + + + - + No attribute type of xs:ENTITY - + @@ -3236,22 +3258,22 @@ - Rule 9-53: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. + Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY. - + - - - + + + - + No attribute type of xs:ENTITIES - + @@ -3264,22 +3286,22 @@ - Rule 9-54: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. + Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES. - + - - - + + + - + No attribute type of xs:anySimpleType - + @@ -3292,22 +3314,22 @@ - Rule 9-55: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. + Rule 9-56: A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType. - + - - - + + + - + No attribute default values - + @@ -3318,22 +3340,41 @@ - Rule 9-56: An element xs:attribute MUST NOT have an attribute {}default. + Rule 9-57: An element xs:attribute MUST NOT have an attribute {}default. - + - - - + + + - + No attribute fixed values - + + + + + + + + + + Rule 9-58: This rule does not constrain attribute uses that are required + + + + + + + @@ -3344,22 +3385,22 @@ - Rule 9-57: An element xs:attribute MUST NOT have an attribute {}fixed. + Rule 9-58: An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed. - + - - - + + + - + No use of element xs:notation - + @@ -3370,22 +3411,22 @@ - Rule 9-58: The schema MUST NOT contain the element xs:notation. + Rule 9-59: The schema MUST NOT contain the element xs:notation. - + - - - + + + - + No xs:all - + @@ -3396,22 +3437,22 @@ - Rule 9-60: The schema MUST NOT contain the element xs:all + Rule 9-61: The schema MUST NOT contain the element xs:all - + - - - + + + - + xs:sequence must be child of xs:extension - + @@ -3423,22 +3464,22 @@ - Rule 9-61: An element xs:sequence MUST be a child of element xs:extension. + Rule 9-62: An element xs:sequence MUST be a child of element xs:extension. - + - - - + + + - + No xs:choice - + @@ -3449,22 +3490,22 @@ - Rule 9-63: The schema MUST NOT contain the element xs:choice + Rule 9-64: The schema MUST NOT contain the element xs:choice - + - - - + + + - + Sequence has minimum cardinality 1 - + @@ -3476,22 +3517,22 @@ - Rule 9-65: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. + Rule 9-66: An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + Sequence has maximum cardinality 1 - + @@ -3503,22 +3544,22 @@ - Rule 9-66: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. + Rule 9-67: An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1. - + - - - + + + - + No use of xs:any - + @@ -3529,22 +3570,22 @@ - Rule 9-69: The schema MUST NOT contain the element xs:any. + Rule 9-70: The schema MUST NOT contain the element xs:any. - + - - - + + + - + No use of xs:anyAttribute - + @@ -3555,22 +3596,22 @@ - Rule 9-70: The schema MUST NOT contain the element xs:anyAttribute. + Rule 9-71: The schema MUST NOT contain the element xs:anyAttribute. - + - - - + + + - + No use of xs:unique - + @@ -3581,22 +3622,22 @@ - Rule 9-71: The schema MUST NOT contain the element xs:unique. + Rule 9-72: The schema MUST NOT contain the element xs:unique. - + - - - + + + - + No use of xs:key - + @@ -3607,22 +3648,22 @@ - Rule 9-72: The schema MUST NOT contain the element xs:key. + Rule 9-73: The schema MUST NOT contain the element xs:key. - + - - - + + + - + No use of xs:keyref - + @@ -3633,22 +3674,22 @@ - Rule 9-73: The schema MUST NOT contain the element xs:keyref. + Rule 9-74: The schema MUST NOT contain the element xs:keyref. - + - - - + + + - + No use of xs:group - + @@ -3659,22 +3700,22 @@ - Rule 9-74: The schema MUST NOT contain the element xs:group. + Rule 9-75: The schema MUST NOT contain the element xs:group. - + - - - + + + - + No definition of attribute groups - + @@ -3686,22 +3727,22 @@ - Rule 9-75: The schema MUST NOT contain an attribute group definition schema component. + Rule 9-76: The schema MUST NOT contain an attribute group definition schema component. - + - - - + + + - + Comment is not recommended - + @@ -3710,21 +3751,21 @@ - Rule 9-76: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. + Rule 9-77: An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema. - + - - - + + + - + Documentation element has no element children - + @@ -3737,22 +3778,22 @@ - Rule 9-77: A child of element xs:documentation MUST be text or an XML comment. + Rule 9-78: A child of element xs:documentation MUST be text or an XML comment. - + - - - + + + - + xs:appinfo children are comments, elements, or whitespace - + @@ -3764,22 +3805,22 @@ - Rule 9-78: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. + Rule 9-79: A child of element xs:appinfo MUST be an element, a comment, or whitespace text. - + - - - + + + - + Appinfo child elements have namespaces - + @@ -3791,22 +3832,22 @@ - Rule 9-79: An element that is a child of xs:appinfo MUST have a namespace name. + Rule 9-80: An element that is a child of xs:appinfo MUST have a namespace name. - + - - - + + + - + Appinfo descendants are not XML Schema elements - + @@ -3817,22 +3858,22 @@ - Rule 9-80: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. + Rule 9-81: An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo. - + - - - + + + - + Schema has data definition - + @@ -3844,22 +3885,22 @@ - Rule 9-81: An element xs:schema MUST have a data definition. + Rule 9-82: An element xs:schema MUST have a data definition. - + - - - + + + - + Schema document defines target namespace - + @@ -3870,48 +3911,22 @@ - Rule 9-82: The schema MUST define a target namespace. + Rule 9-83: The schema MUST define a target namespace. - - - - - - - - - Target namespace is absolute URI - - - - - - - - - - - - Rule 9-83: The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986. - - - + - - - + + + - + Schema has version - + @@ -3923,22 +3938,22 @@ - Rule 9-84: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. + Rule 9-85: An element xs:schema MUST have an attribute {}version that MUST NOT be empty. - + - - - + + + - + No disallowed substitutions - + @@ -3949,22 +3964,22 @@ - Rule 9-85: An element xs:schema MUST NOT have an attribute {}blockDefault. + Rule 9-86: An element xs:schema MUST NOT have an attribute {}blockDefault. - + - - - + + + - + No disallowed derivations - + @@ -3975,22 +3990,22 @@ - Rule 9-86: An element xs:schema MUST NOT have an attribute {}finalDefault. + Rule 9-87: An element xs:schema MUST NOT have an attribute {}finalDefault. - + - - - + + + - + No use of xs:redefine - + @@ -4001,22 +4016,22 @@ - Rule 9-87: The schema MUST NOT contain the element xs:redefine. + Rule 9-88: The schema MUST NOT contain the element xs:redefine. - + - - - + + + - + No use of xs:include - + @@ -4027,22 +4042,22 @@ - Rule 9-88: The schema MUST NOT contain the element xs:include. + Rule 9-89: The schema MUST NOT contain the element xs:include. - + - - - + + + - + xs:import must have namespace - + @@ -4053,22 +4068,22 @@ - Rule 9-89: An element xs:import MUST have an attribute {}namespace. + Rule 9-90: An element xs:import MUST have an attribute {}namespace. - + - - - + + + - + Namespace referenced by attribute type is imported - + @@ -4080,22 +4095,22 @@ - Rule 9-91: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-92: The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute base is imported - + @@ -4107,22 +4122,22 @@ - Rule 9-92: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-93: The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute itemType is imported - + @@ -4134,22 +4149,22 @@ - Rule 9-93: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-94: The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespaces referenced by attribute memberTypes is imported - + @@ -4161,22 +4176,22 @@ - Rule 9-94: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. + Rule 9-95: The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported. - + - - - + + + - + Namespace referenced by attribute ref is imported - + @@ -4188,22 +4203,22 @@ - Rule 9-95: The namespace of a component referenced by @ref MUST be the target namespace or be imported. + Rule 9-96: The namespace of a component referenced by @ref MUST be the target namespace or be imported. - + - - - + + + - + Namespace referenced by attribute substitutionGroup is imported - + @@ -4216,15 +4231,15 @@ - Rule 9-96: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. + Rule 9-97: The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported. - + - - - + + + @@ -4233,7 +4248,7 @@ + mode="M101"> @@ -4250,11 +4265,11 @@ - + - - - + + + @@ -4263,7 +4278,7 @@ + mode="M102"> @@ -4280,11 +4295,11 @@ - + - - - + + + @@ -4293,7 +4308,7 @@ + mode="M103"> @@ -4310,11 +4325,11 @@ - + - - - + + + @@ -4323,7 +4338,7 @@ + mode="M104"> @@ -4340,11 +4355,11 @@ - + - - - + + + @@ -4353,7 +4368,7 @@ + mode="M105"> @@ -4370,11 +4385,11 @@ - + - - - + + + @@ -4383,7 +4398,7 @@ + mode="M106"> @@ -4400,11 +4415,11 @@ - + - - - + + + @@ -4413,7 +4428,7 @@ + mode="M107"> @@ -4430,11 +4445,11 @@ - + - - - + + + @@ -4443,7 +4458,7 @@ + mode="M108"> @@ -4460,11 +4475,11 @@ - + - - - + + + @@ -4473,7 +4488,7 @@ + mode="M109"> @@ -4490,11 +4505,11 @@ - + - - - + + + @@ -4503,7 +4518,7 @@ + mode="M110"> @@ -4520,50 +4535,74 @@ - + - - - + + + Name of code type ends in "CodeType" - - - - + + - - - - - - - - - Rule 10-17: A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type. - - - - + + + + + + + Rule 10-17: A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'. + + + - - - + + + + + + + Element of code type has code representation term + + + + + + + + + + + + Rule 10-19: An element with a type that is a code type SHOULD have a name with representation term "Code" + + + + + + + - + Proxy type has designated structure + mode="M113"> @@ -4576,22 +4615,22 @@ - Rule 10-18: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. + Rule 10-20: A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup. - + - - - + + + - + Association type is derived from association type - + @@ -4607,22 +4646,22 @@ - Rule 10-19: A type MUST have an association type name if and only if it is derived from an association type. + Rule 10-21: A type MUST have an association type name if and only if it is derived from an association type. - + - - - + + + - + Association element type is an association type - + @@ -4635,24 +4674,24 @@ - Rule 10-20: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. + Rule 10-22: An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type. - - - - - + + + + + - + Augmentable type has augmentation point element + mode="M116"> - Rule 10-21: An augmentable type MUST contain an element use of its augmentation point element. + Rule 10-23: An augmentable type MUST contain an element use of its augmentation point element. - + - - - + + + - + Augmentable type has at most one augmentation point element + mode="M117"> - + + test="count(xs:complexContent/xs:extension/xs:sequence/xs:element[ @ref[resolve-QName(., ..) = $augmentation-point-qname]]) le 1"> - Rule 10-22: An augmentable type MUST contain no more than one element use of its augmentation point element. + Rule 10-24: An augmentable type MUST contain no more than one element use of its augmentation point element. - + - - - + + + - + Augmentation point corresponds to augmentable type + mode="M118"> @@ -4730,24 +4769,24 @@ - Rule 10-23: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. + Rule 10-25: A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition. - + - - - + + + - + An augmentation point has no type + mode="M119"> @@ -4759,24 +4798,24 @@ - Rule 10-24: An augmentation point element MUST have no type. + Rule 10-26: An augmentation point element MUST have no type. - + - - - + + + - + An augmentation point has no substitution group + mode="M120"> @@ -4789,24 +4828,24 @@ - Rule 10-25: An augmentation point element MUST have no substitution group. + Rule 10-27: An augmentation point element MUST have no substitution group. - + - - - + + + - + Augmentation point element may only be referenced by its type + mode="M121"> @@ -4819,24 +4858,24 @@ - Rule 10-26: An augmentation point element MUST only be referenced by its corresponding type. + Rule 10-28: An augmentation point element MUST only be referenced by its corresponding type. - + - - - + + + - + Augmentation point reference is optional + mode="M122"> @@ -4849,24 +4888,24 @@ - Rule 10-27: An augmentation point element particle MUST have attribute minOccurs equal to 0. + Rule 10-29: An augmentation point element particle MUST have attribute minOccurs equal to 0. - + - - - + + + - + Augmentation point reference is unbounded + mode="M123"> @@ -4879,24 +4918,24 @@ - Rule 10-28: An augmentation point element particle MUST have attribute maxOccurs set to unbounded. + Rule 10-30: An augmentation point element particle MUST have attribute maxOccurs set to unbounded. - + - - - + + + - + Augmentation point reference must be last particle + mode="M124"> @@ -4909,24 +4948,24 @@ - Rule 10-29: An augmentation point element particle MUST be the last element occurrence in its content model. + Rule 10-31: An augmentation point element particle MUST be the last element occurrence in its content model. - + - - - + + + - + Schema component with name ending in "AugmentationType" is an augmentation type + mode="M125"> @@ -4939,24 +4978,24 @@ - Rule 10-32: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. + Rule 10-34: An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type. - + - - - + + + - + Type derived from augmentation type is an augmentation type + mode="M126"> @@ -4969,22 +5008,22 @@ - Rule 10-33: A type definition derived from an augmentation type MUST be an augmentation type definition + Rule 10-35: A type definition derived from an augmentation type MUST be an augmentation type definition - + - - - + + + - + Augmentation element type is an augmentation type - + @@ -4997,22 +5036,22 @@ - Rule 10-34: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. + Rule 10-36: An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type. - + - - - + + + - + Metadata types are derived from metadata types - + @@ -5028,22 +5067,22 @@ - Rule 10-38: A type MUST have a metadata type name if an only if it is derived from a metadata type. + Rule 10-40: A type MUST have a metadata type name if an only if it is derived from a metadata type. - + - - - + + + - + Metadata element declaration type is a metadata type - + @@ -5056,24 +5095,24 @@ - Rule 10-39: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. + Rule 10-41: An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type. - + - - - + + + - + Name of element that ends in "Representation" is abstract + mode="M130"> @@ -5084,21 +5123,137 @@ - Rule 10-41: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". + Rule 10-43: An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true". - + - - - + + + + + + + Schema component names have only specific characters + + + + + + + + + + + + + + Rule 10-46: The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period. + + + + + + + + + + + + Attribute name begins with lower case letter + + + + + + + + + + + + + + Rule 10-49: Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter + ('a'-'z'). + + + + + + + + + + + + Name of schema component other than attribute and proxy type begins with upper case letter + + + + + + + + + + + + Rule 10-50: This rule does not apply to an attribute. + + + + + + + + + + + + + + + + Rule 10-50: This rule does not apply to a proxy types. + + + + + + + + + + + + + + + + + + Rule 10-50: Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z'). + + + + + + + + - + Deprecated annotates schema component - + @@ -5111,25 +5266,25 @@ - Rule 10-67: The attribute appinfo:deprecated MUST be owned by an element with a namespace name Rule 10-69: The attribute appinfo:deprecated MUST be owned by an element with a namespace name xs. - + - - - + + + - + External import indicator annotates import + mode="M135"> @@ -5141,24 +5296,24 @@ - Rule 10-68: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. + Rule 10-70: The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import. - + - - - + + + - + External adapter type indicator annotates complex type + mode="M136"> @@ -5171,24 +5326,24 @@ - Rule 10-69: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. + Rule 10-71: The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType. - + - - - + + + - + appinfo:appliesToTypes annotates metadata element + mode="M137"> @@ -5201,24 +5356,24 @@ - Rule 10-70: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. + Rule 10-72: The attribute appinfo:appliesToTypes MUST be owned by a metadata element. - + - - - + + + - + appinfo:appliesToElements annotates metadata element + mode="M138"> @@ -5231,22 +5386,22 @@ - Rule 10-72: The attribute appinfo:appliesToElements MUST be owned by a metadata element. + Rule 10-74: The attribute appinfo:appliesToElements MUST be owned by a metadata element. - + - - - + + + - + appinfo:LocalTerm annotates schema - + @@ -5258,22 +5413,22 @@ - Rule 10-74: The element appinfo:LocalTerm MUST be application information on an element xs:schema. + Rule 10-76: The element appinfo:LocalTerm MUST be application information on an element xs:schema. - + - - - + + + - + appinfo:LocalTerm has literal or definition - + @@ -5285,15 +5440,15 @@ - Rule 10-75: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. + Rule 10-77: The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition. - + - - - + + + @@ -5302,7 +5457,7 @@ + mode="M141"> @@ -5315,13 +5470,13 @@ Rule 11-1: The name of a proxy type does not end in "Type". - + + mode="M141"> @@ -5337,67 +5492,18 @@ - - - - - - - - - Name of type other than proxy type is in upper camel case - - - - - - - - - - - - Rule 11-2: The name of a proxy type is not upper camel case. - - - - - - - - - - - - - - - - - - Rule 11-2: A type definition schema component that does not define a proxy type MUST be in upper camel case. - - - - + - - - + + + - + Base type definition defined by conformant schema - + @@ -5409,22 +5515,22 @@ - Rule 11-3: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-2: The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. - + - - - + + + - + Name of simple type ends in "SimpleType" - + @@ -5436,50 +5542,22 @@ - Rule 11-4: A simple type definition schema component MUST have a name that ends in "SimpleType". - - - - - - - - - - - - Name of simple type is upper camel case - - - - - - - - - - - - - - Rule 11-5: The name of a simple type definition schema component MUST be upper camel case. + Rule 11-3: A simple type definition schema component MUST have a name that ends in "SimpleType". - + - - - + + + - + List item type defined by conformant schemas - + - Rule 11-7: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-5: The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined. - + - - - + + + - + Union member types defined by conformant schemas - + @@ -5522,84 +5600,78 @@ - Rule 11-8: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. + Rule 11-6: Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined. - + - - - + + + - + Name of a code simple type has standard suffix + mode="M146"> - - - - - - - - - Rule 11-9: A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType". - - - - + + + + + + + Rule 11-7: A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType". + + + - - - + + + - - Code simple type has enumerations + + Attribute of code simple type has code representation term - + mode="M147"> + context="xs:attribute[exists(@name) and exists(@type) and ends-with(@type, 'CodeSimpleType')]"/> - - - - - - - - - Rule 11-10: A code simple type MUST be derived from a code simple type or have an enumeration facet. - - - - + + + + + + + Rule 11-9: An attribute with a type that is a code simple type SHOULD have a name with representation term "Code" + + + - - - + + + - + Complex type with simple content has structures:SimpleObjectAttributeGroup + mode="M148"> @@ -5612,50 +5684,22 @@ - Rule 11-11: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. - - - - - - - - - - - - Element name is upper camel case - - - - - - - - - - - - - - Rule 11-12: The name of an element declaration MUST be upper camel case. + Rule 11-10: A complex type definition with simple content schema component with a derivation method of extension that has a base type definition that is a simple type MUST incorporate the attribute group {http://release.niem.gov/niem/structures/4.0/}SimpleObjectAttributeGroup. - + - - - + + + - + Element type does not have a simple type name - + @@ -5668,22 +5712,22 @@ - Rule 11-13: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. + Rule 11-11: The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'. - + - - - + + + - + Element type is from conformant namespace - + @@ -5696,84 +5740,75 @@ - Rule 11-14: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. + Rule 11-12: The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant. - + - - - + + + - + Name of element that ends in "Abstract" is abstract - - - - - - - - - - - - - Rule 11-15: An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true". - - - - + + + + + + + + + + + Rule 11-13: An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true". + + + - - - + + + - + Name of element declaration with simple content has representation term + mode="M152"> - - - - - - - - - Rule 11-16: The name of an element declaration that is of simple content MUST use a representation term. - - - - + + + + + + + Rule 11-14: The name of an element declaration that is of simple content SHOULD use a representation term. + + + - - - + + + - + Element substitution group defined by conformant schema + mode="M153"> - Rule 11-18: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. + Rule 11-16: An element substitution group MUST have either the target namespace or a namespace that is imported as conformant. - + - - - + + + - + Attribute type defined by conformant schema - + - Rule 11-19: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. + Rule 11-17: The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant. - + - - - + + + - + Attribute name uses representation term - + - - - - - - - - - Rule 11-20: An attribute name MUST end with a representation term. - - - - + + + + + + + Rule 11-18: An attribute name SHOULD end with a representation term. + + + - - - + + + - + Element reference defined by conformant schema + mode="M156"> - Rule 11-22: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. + Rule 11-20: An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document. - + - - - + + + - + Referenced attribute defined by conformant schemas - + @@ -5907,22 +5939,22 @@ - Rule 11-23: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. + Rule 11-21: An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant. - + - - - + + + - + Schema uses only known attribute groups - + @@ -5935,24 +5967,24 @@ - Rule 11-24: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. + Rule 11-22: An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace. - + - - - + + + - - Standard opening phrase for element + + Standard opening phrase for augmentation point element + priority="1000" + mode="M159"> @@ -5963,38 +5995,52 @@ - Rule 11-31: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + Rule 11-29: The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". - + + + + + + + Standard opening phrase for augmentation element + + priority="1000" + mode="M160"> - + + test="every $phrase in ('supplements ', 'additional information about ') satisfies not(starts-with(lower-case(normalize-space(.)), $phrase))"> - Rule 11-31: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". + Rule 11-30: The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". - + + + + + + + Standard opening phrase for metadata element + - + + context="xs:element[ends-with(@name, 'Metadata') and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]"/> @@ -6006,15 +6052,22 @@ Rule 11-31: The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". - + + + + + + + Standard opening phrase for association element + - + + context="xs:element[ends-with(@name, 'Association') and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]"/> @@ -6023,18 +6076,25 @@ - Rule 11-31: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". + Rule 11-32: The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". - + + + + + + + Standard opening phrase for abstract element + - + context="xs:element[xs:boolean(@abstract) = true() and not(ends-with(@name, 'AugmentationPoint'))]/xs:annotation/xs:documentation[1]"/> @@ -6043,18 +6103,25 @@ - Rule 11-31: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + Rule 11-33: The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". + + + + + + + Standard opening phrase for date element - + + context="xs:element[ends-with(@name, 'Date') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6063,18 +6130,25 @@ - Rule 11-31: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". + Rule 11-34: The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". - + + + + + + + Standard opening phrase for quantity element + - + + context="xs:element[ends-with(@name, 'Quantity') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6083,18 +6157,25 @@ - Rule 11-31: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". + Rule 11-35: The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". - + + + + + + + Standard opening phrase for picture element + - + + context="xs:element[ends-with(@name, 'Picture') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6103,18 +6184,25 @@ - Rule 11-31: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". + Rule 11-36: The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". - + + + + + + + Standard opening phrase for indicator element + - + + context="xs:element[ends-with(@name, 'Indicator') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6123,18 +6211,25 @@ - Rule 11-31: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". + Rule 11-37: The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". - + + + + + + + Standard opening phrase for identification element + - + + context="xs:element[ends-with(@name, 'Identification') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6143,18 +6238,25 @@ - Rule 11-31: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". + Rule 11-38: The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". - + + + + + + + Standard opening phrase for name element + - + + context="xs:element[ends-with(@name, 'Name') and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6163,18 +6265,25 @@ - Rule 11-31: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". + Rule 11-39: The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". - + + + + + + + + Standard opening phrase for element - + mode="M170"> + context="xs:element[@name and not(ends-with(@name, 'Indicator')) and not(ends-with(@name, 'Augmentation')) and not(ends-with(@name, 'Metadata')) and not(xs:boolean(@abstract) eq true())] /xs:annotation/xs:documentation[1]"/> @@ -6183,23 +6292,23 @@ - Rule 11-31: The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)". + Rule 11-40: The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)". - + - - - + + + - - Standard opening phrase for complex type + + Standard opening phrase for association type + priority="1000" + mode="M171"> @@ -6210,16 +6319,23 @@ - Rule 11-32: The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...". + Rule 11-41: The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...". - + + + + + + + + Standard opening phrase for augmentation type + priority="1000" + mode="M172"> @@ -6230,16 +6346,23 @@ - Rule 11-32: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + Rule 11-42: The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". - + + + + + + + Standard opening phrase for metadata type + + priority="1000" + mode="M173"> @@ -6250,16 +6373,23 @@ - Rule 11-32: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + Rule 11-43: The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". - + + + + + + + Standard opening phrase for complex type + + mode="M174"> @@ -6270,23 +6400,23 @@ - Rule 11-32: The data definition for a type SHOULD begin with the standard opening phrase "a data type...". + Rule 11-44: The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...". - + - - - + + + - + Standard opening phrase for simple type + mode="M175"> @@ -6297,23 +6427,23 @@ - Rule 11-33: The data definition for a type SHOULD begin with a standard opening phrase "a data type...". + Rule 11-45: The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...". - + - - - + + + - + Structures imported as conformant + mode="M176"> @@ -6326,24 +6456,24 @@ - Rule 11-38: An import of the structures namespace MUST NOT be labeled as an external import. + Rule 11-50: An import of the structures namespace MUST NOT be labeled as an external import. - + - - - + + + - + XML namespace imported as conformant + mode="M177"> @@ -6356,22 +6486,22 @@ - Rule 11-39: An import of the XML namespace MUST NOT be labeled as an external import. + Rule 11-51: An import of the XML namespace MUST NOT be labeled as an external import. - + - - - + + + - + Consistently marked namespace imports - + @@ -6387,14 +6517,14 @@ - Rule 11-41: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. + Rule 11-53: All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator. - + - - - + + + diff --git a/ndr-rules-conformance-target-set.sch b/ndr-rules-conformance-target-set.sch index efea217..ffe4392 100644 --- a/ndr-rules-conformance-target-set.sch +++ b/ndr-rules-conformance-target-set.sch @@ -1,4 +1,8 @@ -Rules for XML Schema document sets + + Rules XML Schema document sets + + + @@ -6,11 +10,10 @@ - -Base type of complex type with complex content must have complex content +Base type of complex type with complex content must have complex content - Rule 9-31: The base type of complex type that has complex content MUST have complex content. + Rule 9-32: The base type of complex type that has complex content MUST have complex content. @@ -20,39 +23,39 @@ -appinfo:appliesToTypes references types +appinfo:appliesToTypes references types - Rule 10-71: Every item in @appinfo:appliesToTypes MUST resolve to a type. + Rule 10-73: Every item in @appinfo:appliesToTypes MUST resolve to a type. -appinfo:appliesToElements references elements +appinfo:appliesToElements references elements - Rule 10-73: Every item in @appinfo:appliesToElements MUST resolve to an element. + Rule 10-75: Every item in @appinfo:appliesToElements MUST resolve to an element. -Name of element declaration with simple content has representation term +Name of element declaration with simple content has representation term - Rule 11-17: the name of an element declaration that is of simple content MUST use a representation term. + Rule 11-15: the name of an element declaration that is of simple content SHOULD use a representation term. -Reference schema imports reference schema +Reference schema imports reference schema - Rule 11-36: A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document. + Rule 11-48: A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document. -Extension schema document imports reference or extension schema +Extension schema document imports reference or extension schema - Rule 11-37: A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document. + Rule 11-49: A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document. -Each namespace may have only a single root schema in a schema set +Each namespace may have only a single root schema in a schema set - Rule 11-40: A namespace may appear as a root schema in a schema set only once. + Rule 11-52: A namespace may appear as a root schema in a schema set only once. \ No newline at end of file diff --git a/ndr-rules-conformance-target-set.sch.xsl b/ndr-rules-conformance-target-set.sch.xsl index 3db0854..c21d590 100644 --- a/ndr-rules-conformance-target-set.sch.xsl +++ b/ndr-rules-conformance-target-set.sch.xsl @@ -11,7 +11,6 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:appinfo="http://release.niem.gov/niem/appinfo/4.0/" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" - xmlns:term="http://release.niem.gov/niem/appinfo/4.0/" version="2.0"> @@ -167,7 +166,7 @@   @@ -183,16 +182,15 @@ - - rule_9-31 + rule_9-32 Base type of complex type with complex content must have complex content - + @@ -201,75 +199,75 @@ External adapter type not a base type - + - rule_10-71 + rule_10-73 appinfo:appliesToTypes references types - + - rule_10-73 + rule_10-75 appinfo:appliesToElements references elements - + - rule_11-17 + rule_11-15 Name of element declaration with simple content has representation term - + - rule_11-36 + rule_11-48 Reference schema imports reference schema - + - rule_11-37 + rule_11-49 Extension schema document imports reference or extension schema - + - rule_11-40 + rule_11-52 Each namespace may have only a single root schema in a schema set - + - Rules for XML Schema document sets + Rules XML Schema document sets - + Base type of complex type with complex content must have complex content + mode="M9"> @@ -282,15 +280,15 @@ - Rule 9-31: The base type of complex type that has complex content MUST have complex content. + Rule 9-32: The base type of complex type that has complex content MUST have complex content. - + - - - + + + @@ -299,7 +297,7 @@ + mode="M10"> @@ -316,20 +314,20 @@ - + - - - + + + - + appinfo:appliesToTypes references types + mode="M11"> @@ -342,24 +340,24 @@ - Rule 10-71: Every item in @appinfo:appliesToTypes MUST resolve to a type. + Rule 10-73: Every item in @appinfo:appliesToTypes MUST resolve to a type. - + - - - + + + - + appinfo:appliesToElements references elements + mode="M12"> @@ -372,54 +370,51 @@ - Rule 10-73: Every item in @appinfo:appliesToElements MUST resolve to an element. + Rule 10-75: Every item in @appinfo:appliesToElements MUST resolve to an element. - + - - - + + + - + Name of element declaration with simple content has representation term + mode="M13"> - - - - - - - - - Rule 11-17: the name of an element declaration that is of simple content MUST use a representation term. - - - - + + + + + + + Rule 11-15: the name of an element declaration that is of simple content SHOULD use a representation term. + + + - - - + + + - + Reference schema imports reference schema + mode="M14"> @@ -432,24 +427,24 @@ - Rule 11-36: A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document. + Rule 11-48: A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document. - + - - - + + + - + Extension schema document imports reference or extension schema + mode="M15"> @@ -462,24 +457,24 @@ - Rule 11-37: A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document. + Rule 11-49: A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document. - + - - - + + + - + Each namespace may have only a single root schema in a schema set + mode="M16"> @@ -492,14 +487,14 @@ - Rule 11-40: A namespace may appear as a root schema in a schema set only once. + Rule 11-52: A namespace may appear as a root schema in a schema set only once. - + - - - + + + diff --git a/ndr-doc.html b/niem-ndr-4.0beta2.html similarity index 50% rename from ndr-doc.html rename to niem-ndr-4.0beta2.html index 0f5cc69..9a5936c 100644 --- a/ndr-doc.html +++ b/niem-ndr-4.0beta2.html @@ -1,19 +1,14 @@ -National Information Exchange Model Naming and Design Rules, 4.0beta1
National Information Exchange Model Naming and Design Rules
Version 4.0beta1
March 31, 2017
NIEM Technical Architecture Committee (NTAC)
Contents
Table of Figures
Table of Tables
Authors

Webb Roberts, Georgia Tech Research Institute (<webb.roberts@gtri.gatech.edu>), Lead Author

Abstract

This document specifies the data model, XML Schema components, and XML data for use with the National Information Exchange Model (NIEM) version 4.0.

Status

This document is an early draft of the specification for XML Schema documents, components, and instances for use with NIEM 4. It presents a technical architecture that has evolved through the collaborative work of the NIEM Business Architecture Committee (NBAC), 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 niem-comments@lists.gatech.edu.

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 information interoperability 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 declarations 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. Developers 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 conformant to specific conformance targets. These targets are defined in order that they may be leveraged for comprehensive definitions of NIEM conformance. Such definitions may include more than the level of conformance defined by this NDR, and may include specific patterns of use, additional quality criteria, and requirements to reuse NIEM release schemas.

1.1. Scope

This document was developed to specify NIEM 3.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.
  • Aggregate artifacts that define information exchanges and models, including information exchange packages (IEPs) and their specifications, information exchange package descriptions (IEPDs) or other forms of information exchange specifications (IESs), as well as enterprise information exchange models (EIEMs), and other forms of model package descriptions (MPDs).
  • Normative guidance for the location of schema documents or for schema assembly.

This document is intended as a technical specification. It is not intended to be a tutorial or a user guide.

1.2. Audience

This document targets practitioners and developers who employ NIEM for information exchange and interoperability. Such information exchanges may be between organizations or within an organization. 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 importantly, enforce a degree of standardization across a broad set of users.

2. Document conventions and normative content

This document uses formatting and syntactic conventions to clarify meaning and avoid ambiguity.

2.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 [RFC 2119]. All reference documents are recorded in Appendix A, References, below.

2.2. Clark notation and qualified names

This document uses both Clark notation and QName notation to represent qualified names.

QName notation is defined by [XML Namespaces] Section 4, Qualified Names. A QName for the XML Schema string datatype is xs:string. Namespace prefixes used within this specification are listed in Section 2.3, Use of namespaces and namespace prefixes, below.

This document sometimes uses Clark notation to represent qualified names in normative text. Clark notation is described by [ClarkNS], and provides the information in a QName without the need to first define a namespace prefix, and then to reference that namespace prefix. A Clark notation representation for the qualified name for the XML Schema string datatype is {http://www.w3.org/2001/XMLSchema}string.

Each Clark notation value usually consists of a namespace URI surrounded by curly braces, concatenated with a local name. The exception to this is when Clark notation is used to represent the qualified name for an attribute with no namespace, which is ambiguous when represented using QName notation. For example, the element targetNamespace, which has no [namespace name] property, is represented in Clark notation as {}targetNamespace.

2.3. Use of namespaces and namespace prefixes

The following namespace prefixes are used consistently within this specification. These prefixes are not normative; this document issues no requirement that these prefixes be used in any conformant artifact. Although there is no requirement for a schema or XML document to use a particular namespace prefix, the meaning of the following namespace prefixes have fixed meaning in this document.

  • xs: The namespace for the XML Schema definition language as defined by [XML Schema Structures] and [XML Schema Datatypes], http://www.w3.org/2001/XMLSchema.
  • xsi: The XML Schema instance namespace, defined by [XML Schema Structures] Section 2.6, Schema-Related Markup in Documents Being Validated, for use in XML documents, http://www.w3.org/2001/XMLSchema-instance.
  • sch: The Schematron namespace, as defined by [Schematron], http://purl.oclc.org/dsdl/schematron.
  • nf: The namespace defined by this specification for XPath functions, http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#NDRFunctions.
  • ct: The namespace defined by [CTAS] for the conformanceTargets attribute, http://release.niem.gov/niem/conformanceTargets/3.0/.
  • appinfo: The namespace for the appinfo namespace, http://release.niem.gov/niem/appinfo/4.0/.
  • structures: The namespace for the structures namespace, http://release.niem.gov/niem/structures/4.0/.
2.4. Normative and informative content

This document includes a variety of content. Some content of this document is normative, while other content is informative. In general, the informative material appears as supporting text, description, and rationales for the normative material.

[Definition: normative]

The term normative is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:

NORMATIVE — statements provided for the prescriptive parts of the specification, providing that which is necessary in order to be able to claim conformance to the specification.

[Definition: informative]

The term informative is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:

INFORMATIVE (NON-NORMATIVE) — statements provided for informational purposes, intended to assist the understanding or use of the specification and shall not contain provisions that are required for conformance.

Conventions used within this document include:

[Definition: <term>]

A formal definition of a term associated with NIEM.

Definitions are normative. Uses of these terms are given special formatting, using raised dots to identify the term, for example this use of the term conformance target.

[Principle <number>]

A guiding principle for NIEM.

The principles represent requirements, concepts, and goals that have helped shape NIEM. Principles are informative, not normative, but act as the basis on which the rules are defined.

Accompanying each principle is a short discussion that justifies the application of the principle to NIEM design.

Principles are numbered in the order in which they appear in the document.

2.4.1. Rules

A rule states a specific requirement on an artifact or on the interpretation of an artifact. The classes of artifacts are identified by conformance targets that are enumerated by this document in Section 4.1, Conformance targets defined, below. The rules are normative. Human-readable text in rules uses [RFC 2119] terminology as described in Section 3.1, RFC 2119 terminology, below, for normative requirements and recommendations.

[Rule <section>-<number>] (<applicability>) (<classification>)

An enforceable rule for NIEM.

Each rule has a classification, which is either Constraint or Interpretation. If the classification is Constraint, then the rule is a constraint rule. If the classification is Interpretation, then the rule is an interpretation rule.

[Definition: constraint rule]

A constraint rule is a rule that sets a requirement on an artifact with respect to its conformance to a conformance target.

[Definition: interpretation rule]

An interpretation rule is a rule that sets the methodology, pattern, or procedure for understanding some aspect of an instance of a conformance target.

Each rule identifies its applicability. This identifies the conformance targets to which the rule applies. Each entry in the list is a code from Table 4-1, Codes representing conformance targets, below. 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 4, Conformance targets, below. For example, a rule with applicability (REF, EXT) would be applicable to a reference schema document, as well as to an extension schema document.

Rules are stated with the help of XML Infoset terminology (e.g., elements and attributes), as described by Section 3.3, XML Information Set terminology, below, and XML Schema terminology (e.g., schema components), as described by Section 3.4, XML Schema terminology, below. The choice of terminology is driven by which terms best express a concept. Certain concepts are more clearly expressed using XML Infoset terms items, others using XML Schema terms; still others are best expressed using a combination of terminology drawn from each standard.

Rules are numbered according to the section in which they appear and the order in which they appear within that section. For example, the first rule in Section 7 is Rule 7-1.

2.4.2. Use of normative Schematron

This document defines many normative rules using Schematron rule-based validation syntax, as defined by [Schematron]. For example, see Rule 9-28, Complex type content is explicitly simple or complex (REF, EXT), below. Effort has been made to make the rules precise and unambiguous. Very detailed text descriptions of rules can introduce ambiguity, and they are not directly executable by users. Providing NDR rules that are expressed as Schematron rules ensures that the rules are precise, and that they are directly executable through commercially-available and free tools.

Many rules herein do not have executable Schematron supporting them. Some are not fit for automatic validation, and others may be difficult or cumbersome to express in Schematron. In neither case are such rules any less normative. A rule that has no Schematron is just as normative as a rule that does have Schematron. The level of requirements and recommendations within a rule is expressed using terminology from [RFC 2119] as described in Section 3.1, RFC 2119 terminology, below.

The Schematron rules are written using XPath2 as defined by [XPath 2]. These executable rules are normative.

An execution of a Schematron pattern that issues a failed assertion (represented via sch:assert) represents a validation error, and signifies that the assessed artifact violates a requirement of a conformance rule. An example of a constraint rule that uses schematron is Rule 9-10, Simple type definition is top-level (REF, EXT), below.

An execution of a Schematron pattern that issues a report (represented via sch:report) indicates cause for concern. This may be:

In either case, a diagnostic report generated by testing an XML document against the Schematron rules may identify specific locations (e.g., line numbers) within the document that need further attention.

2.4.3. Normative XPath functions

The Schematron within this document is supported by functions, to make the rules more comprehensible, and to abstract away process-specific operations. Each function has a normative XPath interface and a normative text definition. Any implementation provided for these functions should be considered informative, not normative, but may be useful for certain implementations of the rules.

The following XPath functions are defined normatively when used within Schematron by this specification:

  • nf:get-document-element($context as element()) as element()

    Yields the document element of the XML document in which $context occurs.

    This function provides the ability for a validator to consolidate multiple XML Schema documents and XML instance documents into a single XML document, which may simplify validation, and allow for preprocessing of xs:include elements.

  • nf:get-target-namespace($element as element()) as xs:anyURI?

    Yields the target namespace of the XML Schema document in which $element appears. If it is a schema document with no target namespace defined, then it yields the zero-length xs:anyURI value (xs:anyURI('')). If the XML document in which $element appears is not a schema document, then the function yields the empty sequence (()).

  • nf:resolve-namespace($context as element(), $namespace-uri as xs:anyURI) as element(xs:schema)?

    Yields the document element of the first available schema document that has the target namespace $namespace-uri. If there is no such schema document available, it yields the empty sequence (()).

  • nf:resolve-type($context as element(), $qname as xs:QName) as element()?

    Yields the first occurrence of an element xs:simpleType or xs:complexType that defines a type with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no such occurrence, it yields the empty sequence (()).

  • nf:resolve-element($context as element(), $qname as xs:QName) as element(xs:element)?

    Yields the first occurrence of an element xs:element that declares an element with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no occurrence available, it yields the empty sequence. (())

  • nf:has-effective-conformance-target-identifier($context as element(), $match as xs:anyURI) as xs:boolean

    Yields true if and only if an effective conformance target identifier of the XML document containing $context is $match.

2.4.4. Normative Schematron namespace declarations

The following Schematron namespace declarations are normative for the Schematron rules and supporting Schematron code within this specification:

Figure 2-1: Normative Schematron namespace declarations
<sch:ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/>
+National Information Exchange Model Naming and Design Rules, 4.0beta2
National Information Exchange Model Naming and Design Rules
Version 4.0beta2
June 27, 2017
NIEM Technical Architecture Committee (NTAC)
Abstract
This document specifies the data model, XML Schema components, and XML data for use with the National Information Exchange Model (NIEM) version 4.0.
Authors
Webb Roberts, Georgia Tech Research Institute (<webb.roberts@gtri.gatech.edu>), Lead Author
Status
This document is a draft of the specification for XML Schema documents, components, and instances for use with NIEM 4. It presents a technical architecture that has evolved through the collaborative work of the NIEM Business Architecture Committee (NBAC), the NIEM Technical Architecture Committee (NTAC), and their predecessors.
This specification is a product of the NIEM Program Management Office (PMO).
Updates, revisions, and errata for this specification are posted to https://github.com/NIEM/NIEM-NDR. Please submit comments on this specification as issues at https://github.com/NIEM/NIEM-NDR/issues.
Contents
Table of Figures
Table of Tables
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 information interoperability 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 declarations 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. Developers 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 conformant to specific conformance targets. These targets are defined in order that they may be leveraged for comprehensive definitions of NIEM conformance. Such definitions may include more than the level of conformance defined by this NDR, and may include specific patterns of use, additional quality criteria, and requirements to reuse NIEM release schemas.
1.1. Scope
This document was developed to specify NIEM 4.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.
  • Aggregate artifacts that define information exchanges and models, including information exchange packages (IEPs) and their specifications, information exchange package descriptions (IEPDs) or other forms of information exchange specifications (IESs), as well as enterprise information exchange models (EIEMs), and other forms of model package descriptions (MPDs).
  • Normative guidance for the location of schema documents or for schema assembly.
This document is intended as a technical specification. It is not intended to be a tutorial or a user guide.
1.2. Audience
This document targets practitioners and developers who employ NIEM for information exchange and interoperability. Such information exchanges may be between organizations or within an organization. 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 importantly, enforce a degree of standardization across a broad set of users.
2. Document conventions and normative content
This document uses formatting and syntactic conventions to clarify meaning and avoid ambiguity.
2.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 [RFC 2119]. All reference documents are recorded in Appendix A, References, below.
2.2. Clark notation and qualified names
This document uses both Clark notation and QName notation to represent qualified names.
QName notation is defined by [XML Namespaces] Section 4, Qualified Names. A QName for the XML Schema string datatype is xs:string. Namespace prefixes used within this specification are listed in Section 2.3, Use of namespaces and namespace prefixes, below.
This document sometimes uses Clark notation to represent qualified names in normative text. Clark notation is described by [ClarkNS], and provides the information in a QName without the need to first define a namespace prefix, and then to reference that namespace prefix. A Clark notation representation for the qualified name for the XML Schema string datatype is {http://www.w3.org/2001/XMLSchema}string.
Each Clark notation value usually consists of a namespace URI surrounded by curly braces, concatenated with a local name. The exception to this is when Clark notation is used to represent the qualified name for an attribute with no namespace, which is ambiguous when represented using QName notation. For example, the element targetNamespace, which has no [namespace name] property, is represented in Clark notation as {}targetNamespace.
2.3. Use of namespaces and namespace prefixes
The following namespace prefixes are used consistently within this specification. These prefixes are not normative; this document issues no requirement that these prefixes be used in any conformant artifact. Although there is no requirement for a schema or XML document to use a particular namespace prefix, the meaning of the following namespace prefixes have fixed meaning in this document.
  • xs: The namespace for the XML Schema definition language as defined by [XML Schema Structures] and [XML Schema Datatypes], http://www.w3.org/2001/XMLSchema.
  • xsi: The XML Schema instance namespace, defined by [XML Schema Structures] Section 2.6, Schema-Related Markup in Documents Being Validated, for use in XML documents, http://www.w3.org/2001/XMLSchema-instance.
  • sch: The Schematron namespace, as defined by [Schematron], http://purl.oclc.org/dsdl/schematron.
  • nf: The namespace defined by this specification for XPath functions, http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#NDRFunctions.
  • ct: The namespace defined by [CTAS] for the conformanceTargets attribute, http://release.niem.gov/niem/conformanceTargets/3.0/.
  • appinfo: The namespace for the appinfo namespace, http://release.niem.gov/niem/appinfo/4.0/.
  • structures: The namespace for the structures namespace, http://release.niem.gov/niem/structures/4.0/.
2.4. Normative and informative content
This document includes a variety of content. Some content of this document is normative, while other content is informative. In general, the informative material appears as supporting text, description, and rationales for the normative material.
[Definition: normative]
The term normative is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:
NORMATIVE — statements provided for the prescriptive parts of the specification, providing that which is necessary in order to be able to claim conformance to the specification.
[Definition: informative]
The term informative is as defined by [ConfReq] Section 7.2, Conformance by key words, which states:
INFORMATIVE (NON-NORMATIVE) — statements provided for informational purposes, intended to assist the understanding or use of the specification and shall not contain provisions that are required for conformance.
Conventions used within this document include:
[Definition: <term>]
A formal definition of a term associated with NIEM.
Definitions are normative. Uses of these terms are given special formatting, using raised dots to identify the term, for example this use of the term conformance target.
[Principle <number>]
A guiding principle for NIEM.
The principles represent requirements, concepts, and goals that have helped shape NIEM. Principles are informative, not normative, but act as the basis on which the rules are defined.
Accompanying each principle is a short discussion that justifies the application of the principle to NIEM design.
Principles are numbered in the order in which they appear in the document.
2.4.1. Rules
A rule states a specific requirement on an artifact or on the interpretation of an artifact. The classes of artifacts are identified by conformance targets that are enumerated by this document in Section 4.1, Conformance targets defined, below. The rules are normative. Human-readable text in rules uses [RFC 2119] terminology as described in Section 3.1, RFC 2119 terminology, below, for normative requirements and recommendations.
[Rule <section>-<number>] (<applicability>) (<classification>)
An enforceable rule for NIEM.
Each rule has a classification, which is either Constraint or Interpretation. If the classification is Constraint, then the rule is a constraint rule. If the classification is Interpretation, then the rule is an interpretation rule.
[Definition: constraint rule]
A constraint rule is a rule that sets a requirement on an artifact with respect to its conformance to a conformance target.
[Definition: interpretation rule]
An interpretation rule is a rule that sets the methodology, pattern, or procedure for understanding some aspect of an instance of a conformance target.
Each rule identifies its applicability. This identifies the conformance targets to which the rule applies. Each entry in the list is a code from Table 4-1, Codes representing conformance targets, below. 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 4, Conformance targets, below. For example, a rule with applicability (REF, EXT) would be applicable to a reference schema document, as well as to an extension schema document.
Rules are stated with the help of XML Infoset terminology (e.g., elements and attributes), as described by Section 3.3, XML Information Set terminology, below, and XML Schema terminology (e.g., schema components), as described by Section 3.4, XML Schema terminology, below. The choice of terminology is driven by which terms best express a concept. Certain concepts are more clearly expressed using XML Infoset terms items, others using XML Schema terms; still others are best expressed using a combination of terminology drawn from each standard.
Rules are numbered according to the section in which they appear and the order in which they appear within that section. For example, the first rule in Section 7 is Rule 7-1.
2.4.2. Use of normative Schematron
This document defines many normative rules using Schematron rule-based validation syntax, as defined by [Schematron]. For example, see Rule 9-29, Complex type content is explicitly simple or complex (REF, EXT), below. Effort has been made to make the rules precise and unambiguous. Very detailed text descriptions of rules can introduce ambiguity, and they are not directly executable by users. Providing NDR rules that are expressed as Schematron rules ensures that the rules are precise, and that they are directly executable through commercially-available and free tools.
Many rules herein do not have executable Schematron supporting them. Some are not fit for automatic validation, and others may be difficult or cumbersome to express in Schematron. In neither case are such rules any less normative. A rule that has no Schematron is just as normative as a rule that does have Schematron. The level of requirements and recommendations within a rule is expressed using terminology from [RFC 2119] as described in Section 3.1, RFC 2119 terminology, below.
The Schematron rules are written using XPath2 as defined by [XPath 2]. These executable rules are normative.
An execution of a Schematron pattern that issues a failed assertion (represented via sch:assert) represents a validation error, and signifies that the assessed artifact violates a requirement of a conformance rule. An example of a constraint rule that uses Schematron is Rule 9-10, Simple type definition is top-level (REF, EXT), below.
An execution of a Schematron pattern that issues a report (represented via sch:report) indicates cause for concern. This may be:
In either case, a diagnostic report generated by testing an XML document against the Schematron rules may identify specific locations (e.g., line numbers) within the document that need further attention.
2.4.3. Normative XPath functions
The Schematron within this document is supported by functions, to make the rules more comprehensible, and to abstract away process-specific operations. Each function has a normative XPath interface and a normative text definition. Any implementation provided for these functions should be considered informative, not normative, but may be useful for certain implementations of the rules.
The following XPath functions are defined normatively when used within Schematron by this specification:
  • nf:get-document-element($context as element()) as element()
    Yields the document element of the XML document in which $context occurs.
    This function provides the ability for a validator to consolidate multiple XML Schema documents and XML instance documents into a single XML document, which may simplify validation, and allow for preprocessing of xs:include elements.
  • nf:get-target-namespace($element as element()) as xs:anyURI?
    Yields the target namespace of the XML Schema document in which $element appears. If it is a schema document with no target namespace defined, then it yields the zero-length xs:anyURI value (xs:anyURI('')). If the XML document in which $element appears is not a schema document, then the function yields the empty sequence (()).
  • nf:resolve-namespace($context as element(), $namespace-uri as xs:anyURI) as element(xs:schema)?
    Yields the document element of the first available schema document that has the target namespace $namespace-uri. If there is no such schema document available, it yields the empty sequence (()).
  • nf:resolve-type($context as element(), $qname as xs:QName) as element()?
    Yields the first occurrence of an element xs:simpleType or xs:complexType that defines a type with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no such occurrence, it yields the empty sequence (()).
  • nf:resolve-element($context as element(), $qname as xs:QName) as element(xs:element)?
    Yields the first occurrence of an element xs:element that declares an element with a {target namespace} and {name} matching $qname, that is a [child] of the element yielded by nf:resolve-namespace(), above. If there is no occurrence available, it yields the empty sequence. (())
  • nf:has-effective-conformance-target-identifier($context as element(), $match as xs:anyURI) as xs:boolean
    Yields true if and only if an effective conformance target identifier of the XML document containing $context is $match.
2.4.4. Normative Schematron namespace declarations
The following Schematron namespace declarations are normative for the Schematron rules and supporting Schematron code within this specification:
Figure 2-1: Normative Schematron namespace declarations
<sch:ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/>
 <sch:ns prefix="xsl" uri="http://www.w3.org/1999/XSL/Transform"/>
 <sch:ns prefix="nf" uri="http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#NDRFunctions"/>
 <sch:ns prefix="ct" uri="http://release.niem.gov/niem/conformanceTargets/3.0/"/>
 <sch:ns prefix="xsi" uri="http://www.w3.org/2001/XMLSchema-instance"/>
 <sch:ns prefix="appinfo" uri="http://release.niem.gov/niem/appinfo/4.0/"/>
-<sch:ns prefix="structures" uri="http://release.niem.gov/niem/structures/4.0/"/>
-<sch:ns prefix="term" uri="http://release.niem.gov/niem/appinfo/4.0/"/>
Note that the binding of the prefix xml to the XML namespace (http://www.w3.org/XML/1998/namespace) is implicit.
2.5. Additional formatting
In addition to the special formatting above, this document uses additional formatting conventions.
[square brackets]: Terms in plain [square brackets] are properties of XML information set information items, as defined by [XML Infoset]. The information items and many of the information items’ properties are defined in that document. [XML Schema Structures] defines additional information item properties that are contributed by validation of an XML document against an XML Schema.
{curly brackets}: Terms in plain {curly brackets} are properties of schema components, as defined by [XML Schema Structures].
Courier: All words appearing in Courier font are values, objects, keywords, or literal XML text.
Italics: A phrase appearing in italics is one of:
  • a title of a section of document or a rule,
  • a locally-defined term, often one that is not normatively defined, or
  • is emphasized for importance or prominence.
Bold: A phrase appearing in bold is one of:
  • a term being defined within a definition,
  • a term that was bold in the original source text for a quote
  • a heading, such as for a section, a figure, a principle, definition, or rule, or
  • a cross-reference within the document, to a reference to an outside document, or to a normative heading.
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 2-2: Example of an XML fragment
<xs:complexType name="PersonType">
+<sch:ns prefix="structures" uri="http://release.niem.gov/niem/structures/4.0/"/>
Note that the binding of the prefix xml to the XML namespace (http://www.w3.org/XML/1998/namespace) is implicit.
2.5. Additional formatting
In addition to the special formatting above, this document uses additional formatting conventions.
[square brackets]: Terms in plain [square brackets] are properties of XML information set information items, as defined by [XML Infoset]. The information items and many of the information items’ properties are defined in that document. [XML Schema Structures] defines additional information item properties that are contributed by validation of an XML document against an XML Schema.
{curly brackets}: Terms in plain {curly brackets} are properties of schema components, as defined by [XML Schema Structures].
Courier: All words appearing in Courier font are values, objects, keywords, or literal XML text.
Italics: A phrase appearing in italics is one of:
  • a title of a section of document or a rule,
  • a locally-defined term, often one that is not normatively defined, or
  • is emphasized for importance or prominence.
Bold: A phrase appearing in bold is one of:
  • a term being defined within a definition,
  • a term that was bold in the original source text for a quote
  • a heading, such as for a section, a figure, a principle, definition, or rule, or
  • a cross-reference within the document, to a reference to an outside document, or to a normative heading.
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 2-2: Example of an XML fragment
<xs:complexType name="PersonType">
   ...
-</xs:complexType>
3. Terminology

This document uses standard terminology from other standards to explain the principles and rules that describe NIEM. In addition, it defines terms related to these other standards. This section enumerates this externally-dependent terminology.

3.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 [RFC 2119].

3.2. XML terminology
[Definition: XML document]

The term XML document is as defined by [XML] Section 2, Documents, which states:

A data object is an XML document if it is well-formed, as defined in this specification. In addition, the XML document is valid if it meets certain further constraints.

3.3. XML Information Set terminology

When discussing XML documents, this document uses terminology and language as defined by [XML Infoset].

[XML Infoset] uses the term information item to describe pieces of XML documents. Documents, elements, and attributes are types of information items. The use of the term element information item, for example, refers to the term as defined by [XML Infoset]. Shorthand terms may also be used to refer to information items, such as element, as defined below. The information items are identified and defined by [XML Infoset] Section 2, Information Items.

[Definition: element]

An element is an element information item, as defined by [XML Infoset] Section 2.2, Element Information Items

[Definition: attribute]

An attribute is an attribute information item, as defined by [XML Infoset] Section 2.3, Attribute Information Items

[XML Infoset] also describes properties of information items. Each class of information item carries a set of properties. Each property has a name, and the property is identified by putting the name into square brackets. For example, the element that contains an attribute is described as the [owner element] of an attribute information item, as defined in [XML Infoset] Section 2.3, Attribute Information Items.

Shorthand terms for properties of information items include:

  • parent (of an element): the value of the [parent] property of an element information item
  • child (of an element): a member of the list of information items that is the value of the [children] property of an element information item
  • owner (of an attribute): the value of the [owner element] property of an attribute information item
  • document element: the value of the [document element] property of a document information item; preferred over the term root element.
3.4. XML Schema terminology

This document uses many terms from [XML Schema Structures] and [XML Schema Datatypes] in a normative way.

[Definition: schema component]

The term schema component is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:

Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.

Note that this defines an abstract concept. This is not a direct reference to elements that are defined by the XML Schema definition language; this is an abstract concept that might be realized within a tool as an in-memory model of data objects.

[Definition: XML Schema]

The term XML Schema is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:

An XML Schema is a set of schema components.

Note, again, that this is an abstract concept: the set of abstract schema components that are put together to define a schema against which an XML document might be validated.

[Definition: XML Schema definition language]

The term XML Schema definition language is as defined by [XML Schema Structures] subsection Abstract, which states:

XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs).

This describes the XML syntax (and related semantics) defined by the XML Schema specifications. It is through the XML Schema definition language that a complex type definition schema component is created using the xs:complexType element.

[Definition: schema document]

The term schema document is as defined by [XML Schema Structures] Section 3.1.2, XML Representations of Components, which states:

A document in this form (i.e. a <schema> element information item) is a schema document.

This definition describes an XML document that follows the syntax of the XML Schema definition language.

[Definition: valid]

The term valid is as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, which states:

[Definition:] the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.

The referenced clause 1 is a part of a description of schema-validity:

Schema-validity assessment has two aspects:

  1. Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;
  2. Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

In addition, this specification locally defines terms relevant to XML Schema concepts:

[Definition: instance document]

An instance document (of an XML Schema) is an XML document that is valid against the XML Schema.

The term instance document is used with [XML Schema Structures], but is not defined therein.

[Definition: XML Schema document set]

An XML Schema document set is a set of schema documents that together define an XML Schema suitable for assessing the validity of an XML document.

Schema assembly is a tricky topic that is not resolved by this document. Other specifications may express specifics about the process of turning a set of schema documents into an XML Schema. Methods used may include use of tool-specific schema caches and mappings, use of XML catalogs and entity resolvers, use of schemaLocation attributes on xs:import elements, and xsi:schemaLocation attributes in XML documents, among others. The topic of schema assembly is discussed in Section 6.2.10, Schema locations provided in schema documents are hints, below. This specification abstracts away details of schema assembly through the use of XPath functions described by Section 2.4.3, Normative XPath functions, above.

3.4.1. Schema components

In this document, the name of a referenced schema component may appear without the suffix schema component to enhance readability of the text. For example, the term complex type definition may be used instead of complex type definition schema component.

[Definition: base type definition]

The term base type definition is as defined by [XML Schema Structures] Section 2.2.1.1, Type Definition Hierarchy, which states:

A type definition used as the basis for an extension or restriction is known as the base type definition of that definition.

[Definition: simple type definition]

The term simple type definition is as defined by [XML Schema Structures] Section 2.2.1.2, Simple Type Definition.

[Definition: complex type definition]

The term complex type definition is as defined by [XML Schema Structures] Section 2.2.1.3, Complex Type Definition.

[Definition: element declaration]

The term element declaration is as defined by [XML Schema Structures] Section 2.2.2.1, Element Declaration.

3.4.2. Schema information set contributions

As described in Section 3.3, XML Information Set terminology, above, the XML Information Set specification defined properties of the content of XML documents. The XML Schema specification also provides properties of the content of XML documents. These properties are called Schema information set contribution, as described by [XML Schema Structures] Section 2.3, Constraints and Validation Rules, which defines them as:

Augmentations to post-schema-validation infosets expressed by schema components, which follow as a consequence of validation and/or assessment.

This document uses these property terms within definitions and other text. Terms used include:

3.5. XML Namespaces terminology

This document uses XML Namespaces as defined by [XML Namespaces] and [XML Namespaces Errata].

3.6. Conformance Targets Attribute Specification terminology

[CTAS] defines several terms used normatively within this specification.

[Definition: conformance target]

The term conformance target is as defined by [CTAS], which states:

A conformance target is a class of artifact, such as an interface, protocol, document, platform, process or service, that is the subject of conformance clauses and normative statements. There may be several conformance targets defined within a specification, and these targets may be diverse so as to reflect different aspects of a specification. For example, a protocol message and a protocol engine may be different conformance targets.

[Definition: conformance target identifier]

The term conformance target identifier is as defined by [CTAS], which states:

A conformance target identifier is an internationalized resource identifier that uniquely identifies a conformance target.

[Definition: effective conformance target identifier]

The term effective conformance target identifier is as defined by [CTAS] Section 4, Semantics and Use, which states:

An effective conformance target identifier of a conformant document is an internationalized resource identifier reference that occurs in the document’s effective conformance targets attribute.

4. Conformance targets
4.1. Conformance targets defined

This section defines and describes conformance targets of this specification. Each conformance target has a formal definition, along with a notional description of the characteristics and intent of each. These include:

4.1.1. Reference schema document
[Definition: reference schema document]

A reference schema document is a schema document that is intended to provide the authoritative definitions of broadly reusable schema components. It is a conformance target of this specification. A reference schema document MUST conform to all rules of this specification that apply to this conformance target. An XML document with a conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument MUST be a conformant reference schema document.

A reference schema document is a schema document that is intended to be the authoritative definition schema for a namespace. Examples include NIEM Core and NIEM domains.

Some characteristics of a reference schema document:

  • It is explicitly designated as a reference schema via the conformance targets attribute, per Rule 4-5, Schema claims reference schema conformance target (REF), below.
  • 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 information exchanges and extension schema documents.
  • 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 will be defined as a reference schema.

The rules for reference schema documents are more stringent than are the rules for other classes of NIEM-conformant schemas. Reference schema documents are intended to support the broadest reuse. They are very uniform in their structure. As they are the primary definitions for schema components, they do not need to restrict other data definitions, and they are not allowed to use XML Schema’s restriction mechanism (e.g., Rule 9-29, Complex content uses extension (REF), below). Reference schema documents are intended to be as regular and simple as possible.

4.1.2. Extension schema document
[Definition: extension schema document]

An extension schema document is a schema document that is intended to provide definitions of schema components that are intended for reuse within a more narrow scope than those defined by a reference schema document. It is a conformance target of this specification. An extension schema document MUST conform to all rules of this specification that apply to this conformance target. An XML document with a conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument MUST be an extension schema document.

Characteristics of an extension schema document include:

  • It is explicitly designated as an extension schema document via the conformance targets attribute.
  • 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 schema documents.
  • It is intended to express the additional vocabulary required for an information exchange, above and beyond the vocabulary available from reference schemas, and to also support additional XML Schema validation requirements for an exchange.
  • It satisfies all rules specified in this document for extension schema documents.

An extension schema in an information exchange specification serves several functions. First, it defines new content within a new namespace, which may be an exchange-specific namespace or a namespace shared by several exchanges. This content is NIEM-conformant but has fewer restrictions on it than do reference schema documents. Second, the extension schema document bases its content on content from reference schema documents, where appropriate. Methods of deriving content include using (by reference) existing schema components, as well as creating extensions and restrictions of existing components.

For example, an information exchange specification may define a type for an exchange-specific phone number and base that type on a type defined by the NIEM Core reference schema document. This exchange-specific phone number type may restrict the NIEM Core type to limit those possibilities that are permitted of the base type. Exchange 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 reference schema documents.

Note that exchange specifications may define schemas that meet the criteria of reference schemas for those components that its developers wish to nominate for later inclusion in NIEM Core or in domains.

4.1.3. Schema document set

A conformant schema document set is a set of schema documents that are capable of validating XML documents.

[Definition: conformant schema document set]

A conformant schema document set is a collection of schema documents that together are capable of validating a conformant instance XML document. It is a conformance target of this specification. A conformant schema document set MUST conform to all rules of this specification that apply to this conformance target.

A conformant schema document set has strong dependencies on reference schema documents and extension schema documents. Without the guarantees provided by those conformance targets, the rules for a conformant schema document set would not be helpful. Those schemas in a schema set that are marked as reference or extension schemas are required to conform to the appropriate conformance targets.

Rule 4-1. Schema marked as reference schema document must conform
[Rule 4-1] (SET) (Constraint)

Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument MUST be a reference schema document.

Rule 4-2. Schema marked as extension schema document must conform
[Rule 4-2] (SET) (Constraint)

Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument MUST be an extension schema document.

4.1.4. Instance 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: conformant instance XML document]

A conformant instance XML document is an XML document that is instance document valid to a conformant schema document set. It is a conformance target of this specification. A conformant instance XML document MUST conform to all rules of this specification that apply to this conformance target.

Characteristics of a conformant instance XML document include:

Schema-validity may be assessed against a single set of schemas or against multiple sets of schemas.

Assessment against schemas may be directed by a Model Package Description (MPD), by other instructions, or by other tools.

Note that this specification does not require the document element of a conformant instance XML document to be a conformant element information item. Other specifications, such as the MPD specification, may add additional constraints to these in order to specify MPD-specific or exchange-specific conformance constraints.

[Definition: conformant element information item]

A conformant element information item is an element information item that satisfies all of the following criteria:

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 that the {process contents} with a value of skip. As described by [XML Schema Structures] Section 3.10.1, The Wildcard Schema Component, the content of an element introduced by a wildcard with {process contents} set to skip does not have any schema validity constraint; it is only required to be well-formed XML. Within a NIEM-conformant XML document, each element that is from a NIEM namespace conforms to its schema specification.

4.2. Applicability of rules to conformance targets

Each rule within this document is applicable to one or more of the conformance targets identified by Section 4.1, Conformance targets defined, above. Each rule identifies its applicability as described in Section 2.4.1, Rules, above. The applicability field of each rule will contain one or more code values from Table 4-1, Codes representing conformance targets, below. A rule is applicable to the identified conformance targets.

Table 4-1: Codes representing conformance targets
CodeConformance target
REFreference schema document
EXTextension schema document
SETconformant schema document set
INSconformant instance XML document
4.3. Conformance target identifiers

A conformant schema document claims to be conformant thorough the use of a set of conformance target identifiers.

Rule 4-3. Schema is CTAS-conformant
[Rule 4-3] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="*[. is nf:get-document-element(.)]">
-    <sch:report test="true()">The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification.</sch:report>
-  </sch:rule>
-</sch:pattern>

The term conformant document is defined by [CTAS] Section 3.2, Conformance to this Specification. Note that this rule uses sch:report to provide a location that must be checked for conformance to an external standard, and does not itself provide any enforcement or checking of the actual rule.

Rule 4-4. Document element has attribute ct:conformanceTargets
[Rule 4-4] (REF, EXT) (Constraint)
<sch:pattern>
+</xs:complexType>
3. Terminology

This document uses standard terminology from other standards to explain the principles and rules that describe NIEM. In addition, it defines terms related to these other standards. This section enumerates this externally-dependent terminology.

3.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 [RFC 2119].

3.2. XML terminology
[Definition: XML document]

The term XML document is as defined by [XML] Section 2, Documents, which states:

A data object is an XML document if it is well-formed, as defined in this specification. In addition, the XML document is valid if it meets certain further constraints.

3.3. XML Information Set terminology

When discussing XML documents, this document uses terminology and language as defined by [XML Infoset].

[XML Infoset] uses the term information item to describe pieces of XML documents. Documents, elements, and attributes are types of information items. The use of the term element information item, for example, refers to the term as defined by [XML Infoset]. Shorthand terms may also be used to refer to information items, such as element, as defined below. The information items are identified and defined by [XML Infoset] Section 2, Information Items.

[Definition: element]

An element is an element information item, as defined by [XML Infoset] Section 2.2, Element Information Items

[Definition: attribute]

An attribute is an attribute information item, as defined by [XML Infoset] Section 2.3, Attribute Information Items

[XML Infoset] also describes properties of information items. Each class of information item carries a set of properties. Each property has a name, and the property is identified by putting the name into square brackets. For example, the element that contains an attribute is described as the [owner element] of an attribute information item, as defined in [XML Infoset] Section 2.3, Attribute Information Items.

Shorthand terms for properties of information items include:

  • parent (of an element): the value of the [parent] property of an element information item
  • child (of an element): a member of the list of information items that is the value of the [children] property of an element information item
  • owner (of an attribute): the value of the [owner element] property of an attribute information item
  • document element: the value of the [document element] property of a document information item; preferred over the term root element.
3.4. XML Schema terminology

This document uses many terms from [XML Schema Structures] and [XML Schema Datatypes] in a normative way.

[Definition: schema component]

The term schema component is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:

Schema component is the generic term for the building blocks that comprise the abstract data model of the schema.

Note that this defines an abstract concept. This is not a direct reference to elements that are defined by the XML Schema definition language; this is an abstract concept that might be realized within a tool as an in-memory model of data objects.

[Definition: XML Schema]

The term XML Schema is as defined by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, which states:

An XML Schema is a set of schema components.

Note, again, that this is an abstract concept: the set of abstract schema components that are put together to define a schema against which an XML document might be validated.

[Definition: XML Schema definition language]

The term XML Schema definition language is as defined by [XML Schema Structures] subsection Abstract, which states:

XML Schema: Structures specifies the XML Schema definition language, which offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type definitions (DTDs).

This describes the XML syntax (and related semantics) defined by the XML Schema specifications. It is through the XML Schema definition language that a complex type definition schema component is created using the xs:complexType element.

[Definition: schema document]

The term schema document is as defined by [XML Schema Structures] Section 3.1.2, XML Representations of Components, which states:

A document in this form (i.e. a <schema> element information item) is a schema document.

This definition describes an XML document that follows the syntax of the XML Schema definition language.

[Definition: valid]

The term valid is as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, which states:

[Definition:] the word valid and its derivatives are used to refer to clause 1 above, the determination of local schema-validity.

The referenced clause 1 is a part of a description of schema-validity:

Schema-validity assessment has two aspects:

  1. Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;
  2. Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

In addition, this specification locally defines terms relevant to XML Schema concepts:

[Definition: instance document]

An instance document (of an XML Schema) is an XML document that is valid against the XML Schema.

The term instance document is used with [XML Schema Structures], but is not defined therein.

[Definition: XML Schema document set]

An XML Schema document set is a set of schema documents that together define an XML Schema suitable for assessing the validity of an XML document.

Schema assembly is a tricky topic that is not resolved by this document. Other specifications may express specifics about the process of turning a set of schema documents into an XML Schema. Methods used may include use of tool-specific schema caches and mappings, use of XML catalogs and entity resolvers, use of schemaLocation attributes on xs:import elements, and xsi:schemaLocation attributes in XML documents, among others. The topic of schema assembly is discussed in Section 6.2.10, Schema locations provided in schema documents are hints, below. This specification abstracts away details of schema assembly through the use of XPath functions described by Section 2.4.3, Normative XPath functions, above.

3.4.1. Schema components

In this document, the name of a referenced schema component may appear without the suffix schema component to enhance readability of the text. For example, the term complex type definition may be used instead of complex type definition schema component.

[Definition: base type definition]

The term base type definition is as defined by [XML Schema Structures] Section 2.2.1.1, Type Definition Hierarchy, which states:

A type definition used as the basis for an extension or restriction is known as the base type definition of that definition.

[Definition: simple type definition]

The term simple type definition is as defined by [XML Schema Structures] Section 2.2.1.2, Simple Type Definition.

[Definition: complex type definition]

The term complex type definition is as defined by [XML Schema Structures] Section 2.2.1.3, Complex Type Definition.

[Definition: element declaration]

The term element declaration is as defined by [XML Schema Structures] Section 2.2.2.1, Element Declaration.

3.4.2. Schema information set contributions

As described in Section 3.3, XML Information Set terminology, above, the XML Information Set specification defined properties of the content of XML documents. The XML Schema specification also provides properties of the content of XML documents. These properties are called Schema information set contribution, as described by [XML Schema Structures] Section 2.3, Constraints and Validation Rules, which defines them as:

Augmentations to post-schema-validation infosets expressed by schema components, which follow as a consequence of validation and/or assessment.

This document uses these property terms within definitions and other text. Terms used include:

3.5. XML Namespaces terminology

This document uses XML Namespaces as defined by [XML Namespaces] and [XML Namespaces Errata].

3.6. Conformance Targets Attribute Specification terminology

[CTAS] defines several terms used normatively within this specification.

[Definition: conformance target]

The term conformance target is as defined by [CTAS], which states:

A conformance target is a class of artifact, such as an interface, protocol, document, platform, process or service, that is the subject of conformance clauses and normative statements. There may be several conformance targets defined within a specification, and these targets may be diverse so as to reflect different aspects of a specification. For example, a protocol message and a protocol engine may be different conformance targets.

[Definition: conformance target identifier]

The term conformance target identifier is as defined by [CTAS], which states:

A conformance target identifier is an internationalized resource identifier that uniquely identifies a conformance target.

[Definition: effective conformance target identifier]

The term effective conformance target identifier is as defined by [CTAS] Section 4, Semantics and Use, which states:

An effective conformance target identifier of a conformant document is an internationalized resource identifier reference that occurs in the document’s effective conformance targets attribute.

4. Conformance targets
4.1. Conformance targets defined

This section defines and describes conformance targets of this specification. Each conformance target has a formal definition, along with a notional description of the characteristics and intent of each. These include:

4.1.1. Reference schema document
[Definition: reference schema document]

A reference schema document is a schema document that is intended to provide the authoritative definitions of broadly reusable schema components. It is a conformance target of this specification. A reference schema document MUST conform to all rules of this specification that apply to this conformance target. An XML document with a conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument MUST be a conformant reference schema document.

A reference schema document is a schema document that is intended to be the authoritative definition schema for a namespace. Examples include NIEM Core and NIEM domains.

Some characteristics of a reference schema document:

  • It is explicitly designated as a reference schema via the conformance targets attribute, per Rule 4-5, Schema claims reference schema conformance target (REF), below.
  • 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 information exchanges and extension schema documents.
  • 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 will be defined as a reference schema.

The rules for reference schema documents are more stringent than are the rules for other classes of NIEM-conformant schemas. Reference schema documents are intended to support the broadest reuse. They are very uniform in their structure. As they are the primary definitions for schema components, they do not need to restrict other data definitions, and they are not allowed to use XML Schema’s restriction mechanism (e.g., Rule 9-30, Complex content uses extension (REF), below). Reference schema documents are intended to be as regular and simple as possible.

4.1.2. Extension schema document
[Definition: extension schema document]

An extension schema document is a schema document that is intended to provide definitions of schema components that are intended for reuse within a more narrow scope than those defined by a reference schema document. It is a conformance target of this specification. An extension schema document MUST conform to all rules of this specification that apply to this conformance target. An XML document with a conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument MUST be an extension schema document.

Characteristics of an extension schema document include:

  • It is explicitly designated as an extension schema document via the conformance targets attribute.
  • 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 schema documents.
  • It is intended to express the additional vocabulary required for an information exchange, above and beyond the vocabulary available from reference schemas, and to also support additional XML Schema validation requirements for an exchange.
  • It satisfies all rules specified in this document for extension schema documents.

An extension schema in an information exchange specification serves several functions. First, it defines new content within a new namespace, which may be an exchange-specific namespace or a namespace shared by several exchanges. This content is NIEM-conformant but has fewer restrictions on it than do reference schema documents. Second, the extension schema document bases its content on content from reference schema documents, where appropriate. Methods of deriving content include using (by reference) existing schema components, as well as creating extensions and restrictions of existing components.

For example, an information exchange specification may define a type for an exchange-specific phone number and base that type on a type defined by the NIEM Core reference schema document. This exchange-specific phone number type may restrict the NIEM Core type to limit those possibilities that are permitted of the base type. Exchange 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 reference schema documents.

Note that exchange specifications may define schemas that meet the criteria of reference schemas for those components that its developers wish to nominate for later inclusion in NIEM Core or in domains.

4.1.3. Schema document set

A conformant schema document set is a set of schema documents that are capable of validating XML documents.

[Definition: conformant schema document set]

A conformant schema document set is a collection of schema documents that together are capable of validating a conformant instance XML document. It is a conformance target of this specification. A conformant schema document set MUST conform to all rules of this specification that apply to this conformance target.

A conformant schema document set has strong dependencies on reference schema documents and extension schema documents. Without the guarantees provided by those conformance targets, the rules for a conformant schema document set would not be helpful. Those schemas in a schema set that are marked as reference or extension schemas are required to conform to the appropriate conformance targets.

Rule 4-1. Schema marked as reference schema document must conform
[Rule 4-1] (SET) (Constraint)

Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument MUST be a reference schema document.

Rule 4-2. Schema marked as extension schema document must conform
[Rule 4-2] (SET) (Constraint)

Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument MUST be an extension schema document.

4.1.4. Instance 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: conformant instance XML document]

A conformant instance XML document is an XML document that is instance document valid to a conformant schema document set. It is a conformance target of this specification. A conformant instance XML document MUST conform to all rules of this specification that apply to this conformance target.

Characteristics of a conformant instance XML document include:

Schema-validity may be assessed against a single set of schemas or against multiple sets of schemas.

Assessment against schemas may be directed by a Model Package Description (MPD), by other instructions, or by other tools.

Note that this specification does not require the document element of a conformant instance XML document to be a conformant element information item. Other specifications, such as the MPD specification, may add additional constraints to these in order to specify MPD-specific or exchange-specific conformance constraints.

[Definition: conformant element information item]

A conformant element information item is an element information item that satisfies all of the following criteria:

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 that the {process contents} with a value of skip. As described by [XML Schema Structures] Section 3.10.1, The Wildcard Schema Component, the content of an element introduced by a wildcard with {process contents} set to skip does not have any schema validity constraint; it is only required to be well-formed XML. Within a NIEM-conformant XML document, each element that is from a NIEM namespace conforms to its schema specification.

4.2. Applicability of rules to conformance targets

Each rule within this document is applicable to one or more of the conformance targets identified by Section 4.1, Conformance targets defined, above. Each rule identifies its applicability as described in Section 2.4.1, Rules, above. The applicability field of each rule will contain one or more code values from Table 4-1, Codes representing conformance targets, below. A rule is applicable to the identified conformance targets.

Table 4-1: Codes representing conformance targets
CodeConformance target
REFreference schema document
EXTextension schema document
SETconformant schema document set
INSconformant instance XML document
4.3. Conformance target identifiers

A conformant schema document claims to be conformant thorough the use of a set of conformance target identifiers.

Rule 4-3. Schema is CTAS-conformant
[Rule 4-3] (REF, EXT) (Constraint)

The schema document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification.

The term conformant document is defined by [CTAS] Section 3.2, Conformance to this Specification.

Rule 4-4. Document element has attribute ct:conformanceTargets
[Rule 4-4] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[. is nf:get-document-element(.)
                        or exists(@ct:conformanceTargets)]">
     <sch:assert test="(. is nf:get-document-element(.)) = exists(@ct:conformanceTargets)"
@@ -24,65 +19,26 @@
     <sch:assert test="nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument'))"
       >The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term effective conformance target identifier.

Rule 4-6. Schema claims extension conformance target
[Rule 4-6] (EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term effective conformance target identifier.

Rule 4-6. Schema claims extension conformance target
[Rule 4-6] (EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[. is nf:get-document-element(.)]">
     <sch:assert test="nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument'))"
       >The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term effective conformance target identifier.

5. The NIEM conceptual model

This section describes aspects of the RDF model, and provides a mapping between NIEM concepts and the RDF model.

5.1. Purpose of the NIEM conceptual model

Each release of NIEM provides a concrete data model, in the form of a set of schema documents. These schema documents may be used to build messages and information exchanges. The schema documents spell out what kinds of objects exist and how those objects may be related. A set of XML data that follows the rules of NIEM implies specific meaning. The varieties of schema components used within conformant schema documents 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 through the construction and use of schema components.

In a schema, the meaning of a schema component may be described using the xs:documentation element, or additional information may be included via use of the xs: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. This meaning 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 this section, 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.

5.2. The RDF model

This section identifies features of RDF and RDFS, in order to establish a mapping between RDF semantics and NIEM. A reader should read the referenced source documents to obtain a full understanding of the concepts mentioned in this section.

RDF establishes a graph-based data model, as described by [RDF Concepts] Section 1.1, Graph-based Data Model, which states:

The core structure of the abstract syntax is a set of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph.

[RDF Concepts] also states:

There can be three kinds of nodes in an RDF graph: IRIs, literals, and blank nodes.

[RDF Concepts] Section 1.2, Resources and Statements describes resources:

Any IRI or literal denotes something in the world (the universe of discourse). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with entity as it is used in the RDF Semantics specification. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its literal value.

[RDF Concepts] also describes relationships and blank nodes.

Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object. This statement corresponding to an RDF triple is known as an RDF statement. The predicate itself is an IRI and denotes a property, that is, a resource that can be thought of as a binary relation. (Relations that involve more than two entities can only be indirectly expressed in RDF.)

Unlike IRIs and literals, blank nodes do not identify specific resources. Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.

[RDF Concepts] Section 1.7, Equivalence, Entailment and Inconsistency describes the meaning of an RDF triple:

An RDF triple encodes a statement—a simple logical expression, or claim about the world. An RDF graph is the conjunction (logical AND) of its triples.

[RDF Concepts] Section 3.1, Triples defines an RDF triple:

An RDF triple consists of three components:

  • the subject, which is an IRI or a blank node
  • the predicate, which is an IRI
  • the object, which is an IRI, a literal or a blank node

An RDF triple is conventionally written in the order subject, predicate, object.

5.3. NIEM in terms of RDF

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 defines NIEM data in XML terminology, complex types and elements, rather than using RDF terms, resources and properties. NIEM objects and associations coincide with RDF resources; both objects and associations correspond to RDF resources with additional constraints:

NIEM associations are defined as n-ary properties, as described in [N-ary], Use Case 3: N-ary relation with no distinguished participant. NIEM associations are defined in Section 10.3, Associations, below. Assertions are made via NIEM-conformant XML data, described by Section 12, XML instance document rules, below.

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. These elements and attributes are XML Schema representations, which correspond to RDF properties. NIEM-conformant XML Schemas describe things and their properties. NIEM-conformant data contains elements and attributes. These correspond to RDF resources and their properties, which describe their characteristics and relationships.

5.4. Unique identification of data objects

A NIEM data exchange may be ephemeral and ad hoc. That is, a message may be transmitted without any expectation of persistence. Such a message 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 carried by a message to be identified by a URI.

A NIEM-conformant instance XML document may carry any of these attributes to identify objects within messages:

  • Attribute xml:base (of type xs:anyURI) is defined by [XML Base] Section 3, xml:base Attribute, which states:

    The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity.

    An XML document has an implicit base URI, the identifier of the document itself. This attribute allows the base URI to be made explicit within a NIEM XML document.

  • Attribute structures:uri (of type xs:anyURI) may appear within an XML element to define a URI for that element. This may be an absolute URI (e.g., http://example.org/incident182#person12), or may be a relative URI (e.g., #person12). Relative URIs are resolved against a URI determined by the xml:base attributes in scope, falling back to the base URI of the containing document.
  • Attribute structures:id (of type xs:ID) provides a document-relative identifier for an element. Semantically, structures:id="abe92" is equivalent to structures:uri="#abe92".
  • Attribute structures:ref (of type xs:IDREF) provides a reference to another element within a document, by providing a value of a structures:id attribute within the document. Semantically, structures:ref="abe92" is equivalent to structures:uri="#abe92"

The values of URIs and IDs within NIEM XML documents are not presumed to have any particular significance. XML requires every ID to be unique within its XML document, and for every IDREF to refer to an ID within the same document. The mapping of IDs and IDREFs to URIs does not mean that the identifiers are persistent or significant.

These attributes provide the identifiers of objects. The properties of an object may be spread across several XML elements that have the same identifer. These properties must be merged together to provide all the properties of a single object, as described by [JSON LD] Section 8.2, Node Objects:

The properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.

Mapping of NIEM data to RDF frequently involves the use of blank nodes, not universally-meaningful resource IRIS.

5.5. NIEM data 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.

5.6. Mapping of NIEM concepts to RDF concepts

This section has not yet been updated to accommodate attribute structures:uri, and the updated mappings for structures:id and structures:ref.

This section provides RDF implementations for many aspects of NIEM-conformant schemas and instance documents.

5.6.1. Resource IRIs for XML Schema components and information items

The term qualified name is defined by [XML Namespaces] Section 2.1, Basic Concepts, which states:

A qualified name is a name subject to namespace interpretation.

A Qname is used to represent a qualified name, as described by [XML Schema Datatypes] Section 3.2.18, QName, which states:

The value space of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName.

Certain components defined by NIEM schemas and instances have corresponding resource IRIs. Each IRI is taken from a qualified name, as follows:

  • If namespace name ends with #: concatenate(namespace name, local part)
  • Otherwise: concatenate(namespace name, #, local part)

Note that this is only meaningful when the namespace name is not empty and is an absolute URI.

The corresponding RDF resource IRIs for information items and schema components are:

  • element information item or attribute information item: the resource IRI is built from the qualified name constructed from its [namespace name] and [local name] properties.
  • schema component: the resource IRI is built from the qualified name constructed from its {target namespace} and {name} properties.
5.6.2. Blank nodes for instances and schemas

A blank node may correspond to an occurrence of an element information item, which represents the relationship established by the element.

A blank node may correspond to the content of an element, which represents an instance of a type. This is distinct from the occurrence of the element itself. This includes resolution of structures:ref to structures:id attributes, in which case the content of the referred-to element is considered the content of the element.

A blank node may correspond to a combination of factors. For example, a blank node is used for each application of an element to a base object via an augmentation, as a single augmentation may be applied to multiple base objects.

A blank node may also correspond to the above, but for attributes.

5.6.3. RDF Literals

A simple value may be incorporated into a conformant instance XML document as the value of an attribute information item, or as a child of an element information item. This section describes how a simple value is mapped to an RDF literal. Note that there is no mapping for the simple content of an element that is not a conformant element information item, nor for attributes defined by non-conformant schema documents, so there is no accommodation of mixed content, untyped values, or other cases outside of what conformant schema documents define.

For each occurrence of a simple value, the following may be relevant:

The literal for a simple value $value is:

  • If $value has a base type definition that is derived from type xs:string (and not a XML Schema-defined type derived from xs:string), and a non-empty language specification is applied to $value using xml:lang, as described by [XML] Section 2.12, Language Identification, then the literal is a language-tagged string, as described by [RDF Concepts] Section 3.3, Literals:

    "$lexical-form"@$language-tag

    Where:

    • $lexical-form is a Unicode string for $value.
    • $language-tag is the in-scope value of attribute xml:lang.

  • Otherwise, if $value has a base type definition $base-type that is listed as an RDF-compatible XSD type in [RDF Concepts] Section 5.1, The XML Schema Built-in Datatypes, then the literal is:

    "$lexical-form"^^$datatype-IRI

    Where:

    • $lexical-form is a Unicode string for $value.
    • $datatype-IRI is the QName of $base-type.

  • Otherwise, the literal is a simple literal, which is:

    "$lexical-form"

    Where: $lexical-form is a Unicode string for $value.

5.6.4. Resolved element

This document defines two attributes, structures:id and structures:ref that, together, define a reference mechanism for conformant elements. This enables the use of references to date in place of directly-contained data, which loops in data graphs, as well as for multiple relationships to be defined to a single object. This mechanism uses XML IDs and IDREFs as provided by the XML Schema language. As this document defines the mechanism, a structures:ref attribute may refer to a structures:id; this reference means that the element that has the structures:ref attribute refers to the element that has the structures:id attribute.

This section defines an operation, resolving an element information item to obtain whatever element is referred to by it. This is put in terms of taking an element and finding the resolved element to which it refers. In a case where there is no reference, the resolved element is the same as the original element.

[Definition: resolved element information item]

Within an XML document $document, for any element information item $element there is a resolved element information item, which is:

  • If all of the following are true:

    Then the resolved element information item for $element is $referent.

  • Otherwise, the resolved element information item for $element is $element.
5.6.5. NIEM instance mappings to RDF

This section has the following subsections:

5.6.5.1. XML document mapping

A conformant instance XML document entails a corresponding RDF graph, which is a set of triples, which are entailed by the mapping of the contents of the XML document to RDF.

5.6.5.2. Content of an element

A conformant element information item $element that has property [type definition] that is an object type or an association type, entails the RDF:

$content rdf:type $type .

Where:

  • $content is a blank node corresponding to the content of $element.
  • $type is resource IRI for the value of the [type definition] property of $element.

If $element has a non-empty simple value, then it also entails the RDF:

$content rdf:value $literal .

Where:

5.6.5.3. Element as a property with unknown context

A conformant element information item $element that

entails the RDF:

$element-node rdf:type rdf:Statement .
-$element-node rdf:subject $blank-node .
-$element-node rdf:predicate $predicate .
-$element-node rdf:object $element-content-blank-node .

Where:

  • $element-node is a blank node corresponding to $element, to represent the relationship being established.
  • $blank-node is a blank node, to represent the unknown context in which $element occurs.
  • $predicate is the IRI for element information item $element, to represent the semantics of the relationship.
  • $element-content-blank-node is a blank node corresponding to the content of the resolved element information item for $element.
5.6.5.4. Element as a simple property of an object or association

A conformant element information item $context that is an instance of an object type or association type, and that has a child conformant element information item $element that is an instance of an object type or an association type, entails the RDF:

$element-node rdf:type rdf:Statement .
-$element-node rdf:subject $subject .
-$element-node rdf:predicate $predicate .
-$element-node rdf:object $object .

Where:

  • $element-node is a blank node corresponding to $element.
  • $subject is a blank node corresponding to the content of $context.
  • $predicate is the IRI for $element.
  • $object is a blank node corresponding to the content of the resolved element information item for $child.
5.6.5.5. Attribute as a simple property of an object or association

An attribute information item $attribute where:

entails the RDF:

$attribute-node rdf:type rdf:Statement .
-$attribute-node rdf:subject $subject .
-$attribute-node rdf:predicate $predicate .
-$attribute-node rdf:object $literal .

Where:

  • $attribute-node is a blank node corresponding to $attribute.
  • $subject is a blank node corresponding to the content of $context.
  • $predicate is the resource IRI for $attribute-declaration.
  • $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
5.6.5.6. Elements via an augmentation type

An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association.

For each element applied to a type via an augmentation type:

entails the RDF:

$element-node rdf:type rdf:Statement .
-$element-node rdf:subject $subject .
-$element-node rdf:predicate $predicate .
-$element-node rdf:object $object .

Where:

  • $element-node is a blank node corresponding to $element applied to $base via $augmentation.
  • $subject is a blank node corresponding to the content of $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $object is a blank node corresponding to the content of $resolved-element
5.6.5.7. Attributes via an augmentation type

An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association.

For each attribute applied to a type via an augmentation type:

entails the RDF:

$attribute-node rdf:type rdf:Statement .
-$attribute-node rdf:subject $subject .
-$attribute-node rdf:predicate $predicate .
-$attribute-node rdf:object $literal .

Where:

  • $attribute-node is a blank node corresponding to $attribute applied to $base via $augmentation.
  • $subject is a blank node corresponding to the content of $base.
  • $predicate is the resource IRI for [attribute declaration] of $attribute.
  • $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
5.6.5.8. Elements applied to an object via a metadata type

An element of a metadata type contains a set of elements and attributes that are applied to some base object or association.

For each element applied to a type via a metadata type:

  • Element information item $base that is an instance of an object type or association type,
  • Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
  • Each element information item $metadata that has [type definition] that is a metadata type, and has attribute structures:id with a value of $metadata-idref.
  • Element information item $element that is a child of $metadata, that has [type definition] that is an object type or an association type, and
  • Element information item $resolved-element that is the resolved element information item for $element

entails the RDF:

$element-node rdf:type rdf:Statement .
-$element-node rdf:subject $subject .
-$element-node rdf:predicate $predicate .
-$element-node rdf:object $object .

Where:

  • $element-node is a blank node corresponding to $element applied to $base via $metadata.
  • $subject is a blank node corresponding to the content of $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $object is a blank node corresponding to the content of $resolved-element
5.6.5.9. Attributes applied to an object via a metadata type

An element of a metadata type contains a set of elements and attributes that are applied to some base object or association.

For each element applied to a type via a metadata type:

  • Element information item $base that is an instance of an object type or association type,
  • Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
  • Each element information item $metadata that has [type definition] that is a metadata type, and has attribute structures:id with a value of $metadata-idref.
  • Attribute information item $attribute that is owned by $metadata, that has [attribute declaration] that is defined by a reference schema document or an extension schema document

entails the RDF:

$attribute-node rdf:type rdf:Statement .
-$attribute-node rdf:subject $subject .
-$attribute-node rdf:predicate $predicate .
-$attribute-node rdf:object $literal .

Where:

  • $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata.
  • $subject is a blank node corresponding to the content of $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
5.6.5.10. Elements applied to a relationship via a metadata type

An element of a metadata type contains a set of elements and attributes that are applied to a relationship.

For each element applied to a type via a metadata type:

  • Element information item $base that is an instance of an object type or association type,
  • Each value $metadata-idref that is a value in attribute structures:relationshipMetadata owned by $base.
  • Each element information item $metadata that has [type definition] that is a metadata type, and has attribute structures:id with a value of $metadata-idref.
  • Element information item $element that is a child of $metadata, that has [type definition] that is an object type or an association type, and
  • Element information item $resolved-element that is the resolved element information item for $element

entails the RDF:

$element-node rdf:type rdf:Statement .
-$element-node rdf:subject $subject .
-$element-node rdf:predicate $predicate .
-$element-node rdf:object $object .

Where:

  • $element-node is a blank node corresponding to $element applied to $base via $metadata.
  • $subject is a blank node corresponding to $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $object is a blank node corresponding to the content of $resolved-element
5.6.5.11. Attributes applied to a relationship via a metadata type

An element of a metadata type contains a set of elements and attributes that are applied to a relationship.

For each element applied to a type via a metadata type:

  • Element information item $base that is an instance of an object type or association type,
  • Each value $metadata-idref that is a value in attribute structures:metadata owned by $base.
  • Each element information item $metadata that has [type definition] that is a metadata type, and has attribute structures:id with a value of $metadata-idref.
  • Attribute information item $attribute that is owned by $metadata, that has [attribute declaration] that is defined by a reference schema document or an extension schema document

entails the RDF:

$attribute-node rdf:type rdf:Statement .
-$attribute-node rdf:subject $subject .
-$attribute-node rdf:predicate $predicate .
-$attribute-node rdf:object $literal .

Where:

  • $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata.
  • $subject is a blank node corresponding to $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above.
5.6.6. NIEM complex type definitions to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

An object type or association type $type entails the following RDF:

$resource rdf:type rdf:Class .

Where $resource is the resource IRI for $type.

An object type or association type $type that has property {base type definition} $base entails the RDF:

$type-resource rdfs:subClassOf $base-resource

Where:

  • $type-resource is the resource IRI for $type.
  • $base-resource is the resource IRI for $base.
5.6.7. NIEM element declaration mappings to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

A top-level element declaration schema component $element-declaration that has property {type definition} that is

  • the ur-type, or
  • is, or is derived from, structures:ObjectType, or
  • is, or is derived from, structures:AssociationType

entails the RDF:

$element-resource rdf:type rdf:Property .

Where $element-resource is the resource IRI for $element-declaration.

If $element-declaration has property {substitution group affiliation} with a value of element declaration $base, then it entails the RDF:

$element-resource rdfs:subPropertyOf $base-resource

Where:

  • $element-resource is the resource IRI for $element-declaration.
  • $base-resource is the resource IRI for $base.

If $element-declaration has property {type definition} with a value $type that is an object type or association type, then it entails the RDF:

$element-resource rdfs:range $type-resource

Where:

  • $element-resource is the resource IRI for $element-declaration.
  • $type-resource is the resource IRI for $type.
5.6.8. NIEM attribute declarations to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

A top-level attribute declaration schema component $attribute-declaration that has property {type definition} that is a simple type definition defined within a reference schema document or an extension schema document, then it entails the RDF:

$attribute-resource rdf:type rdf:Property .

Where $attribute-resource is the resource IRI for $attribute-declaration.

6. 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 organized as follows:

6.1. Specification guidelines

The principles in this section address what material should be included in this NDR and how it should be represented.

6.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.

6.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 and their instance documents. It should avoid specifying complex data models or data dictionaries.

[Principle 2]

This specification SHOULD focus on specifying characteristics of schema documents, their instance documents, and their interpretation.

6.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 that are specific, precise, and concise.

6.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.

6.2.1. Purpose of XML Schemas
[Principle 4]

The specification SHOULD focus on rules for XML Schemas in order to support:

  1. the expression of interface specifications for exchange of information between data producers and consumers,
  2. validation of XML documents against interface specifications,
  3. comprehension and understanding of XML documents, including the use of post-schema-validation infoset as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, and
  4. development of implementations supported by tools that use XML Schemas.
6.2.2. 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. An example 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 primarily validation: testing that data instances match desired constraints and guidelines. It should not be used to change the content of data instances.

[Principle 5]

The content of a NIEM-conformant data instance SHOULD NOT be modified by processing against XML Schema documents.

6.2.3. Use XML validating parsers for content validation

NIEM is designed for XML Schema validation. One 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 6]

NIEM-conformant schemas and NIEM-conformant XML documents SHOULD use features supported by XML Schema validating parsers for validation of XML content.

6.2.4. Validate for conformance to schema

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 validation against schemas 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 7]

Systems that use NIEM-conformant data SHOULD mark as invalid data that does not conform to the rules defined by applicable XML Schema documents.

6.2.5. Allow multiple schemas for XML constraints

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. Although NIEM is principally expressed as a set of reference schemas for a NIEM release, additional validation may be conducted through other mechanisms, which may include XML Schemas that express additional constraints, and business rules and structure-specifying languages other than the XML Schema definition language.

[Principle 8]

Constraints on XML instances MAY be validated by multiple validation passes, using multiple schemas and specifications for different aspects of each namespace.

6.2.6. 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 9]

Each NIEM-conformant namespace SHOULD be defined by exactly one reference schema.

6.2.7. 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 10]

NIEM-conformant schemas SHOULD NOT specify data that uses mixed content.

6.2.8. Specify types for all constructs

Every schema component defined by a NIEM-conformant schema that can have a name has a name. 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 11]

NIEM-conformant schemas SHOULD NOT use or define local or anonymous components, as they adversely affect reuse.

6.2.9. Avoid wildcards in 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 xs:any, which allows insertion of arbitrary elements) allows unstandardized data to be passed via otherwise standardized exchanges.

Avoidance of wildcards in the standard schemas encourages the separation of standardized and unstandardized 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 12]

NIEM-conformant components SHOULD NOT incorporate wildcards unless absolutely necessary, as they hinder standardization by encouraging use of unstandardized data rather than standardized data.

6.2.10. Schema locations provided in schema documents are hints

[XML Schema Structures] provides several mechanisms for acquiring components of an XML Schema for the purpose of assessing validity of an instance. [XML Schema Structures] Section 4.3.2, How schema definitions are located on the Web includes:

  • Use schema definitions already known to the processor.
  • Use a location URI or namespace name to identify a schema document from a network location or local schema repository.
  • Attempt to resolve a location URI or namespace name to locate a schema document.

In addition, there are several ways for a processor to determine schema locations:

  • Use schema locations identified by user direction.
  • Use locations provided via xsi:schemaLocation or xsi:noNamespaceSchemaLocation attributes in an XML document under assessment.
  • Use schema locations provided by xs:import elements.

[XML Schema Structures] characterizes several of these methods as hints of where to acquire a schema document for assessment. [XML Schema Structures] Section 2.6.3, xsi:schemaLocation, xsi:noNamespaceSchemaLocation states:

The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which may be used for assessment.

[XML Schema Structures] Section 4.2.3, References to schema components across namespaces states:

The actual value of the schemaLocation, if present, gives a hint as to where a serialization of a schema document with declarations and definitions for that namespace (or none) may be found.

The specification explicitly maintains that schema location provided in schemas or instances may be overridden by applications or by user direction.

[Principle 13]

Schema locations specified within NIEM-conformant reference schemas SHOULD be interpreted as hints and as default values by processing applications.

In accordance with Section 1.1, Scope, above, this document does not provide normative guidance for location of schema documents or for schema assembly.

6.2.11. 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 14]

NIEM standards and schemas SHOULD leverage and enable use of other open standards.

6.3. Modeling design guidelines

The principles in this section address the design philosophy used in designing the NIEM conceptual model.

6.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 a NIEM-conformant schema, 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 15]

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 6-1: Example of the use of a namespace
<xs: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 16]

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.

6.3.2. Design NIEM for extensibility

NIEM is designed to be extended. Numerous methods are considered acceptable in creating extended and specialized components.

[Principle 17]

NIEM-conformant schemas and standards SHOULD be designed to encourage and ease extension and augmentation by users and developers outside the NIEM governance process.

6.4. Implementation guidelines

The principles in this section address issues pertaining to the implementation of applications that use NIEM.

6.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. Structured XML content does not belong in places targeting humans. Human-targeted information should be of a form suitable for presentation.

[Principle 18]

XML data SHOULD be designed for automatic processing. XML data SHOULD NOT be designed for literal presentation to people. NIEM specifications and schemas SHOULD NOT use literal presentation of XML data to people as a design criterion.

6.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 19]

NIEM SHOULD NOT depend on specific software packages, software frameworks, or software systems for interpretation of XML instances.

[Principle 20]

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.

6.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.

6.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 schema component’s data 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 21]

The data definition of a component SHOULD be drafted before the component’s name is composed.

6.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 22]

Components in NIEM SHOULD be given names that are consistent with names of other NIEM components. Such names SHOULD be based on simple rules.

6.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 23]

Component definitions in NIEM-conformant schemas SHOULD reflect real-world concepts.

It is important for the modeler to understand what she is modeling; a person, an observation of a person, and a drivers license for a person are all at different levels, although they each may contain similar information.

6.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 24]

Component definitions in NIEM-conformant schemas SHOULD have semantic consistency.

6.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 25]

Complex type definitions in NIEM-conformant schemas SHOULD use type inheritance only for specialization.

Note that the use of augmentations allows developers to avoid type specialization in many cases; see Section 10.4, Augmentations, below.

6.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.

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 26]

Multiple components with identical or undifferentiated semantics SHOULD NOT be defined. Component definitions SHOULD have clear, explicit distinctions.

6.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 27]

NIEM-conformant schemas SHOULD have the simplest possible structure, content, and architecture consistent with real business requirements.

6.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 28]

Components defined by NIEM-conformant schemas SHOULD be defined appropriate for their scope.

6.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 29]

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.

7. Conformance to standards
7.1. Conformance to XML
Rule 7-1. Document is an XML document
[Rule 7-1] (REF, EXT, INS) (Constraint)
<sch:pattern>
-  <sch:rule context="*[. is nf:get-document-element(.)]">
-    <sch:report test="true()">The document MUST be an XML document.</sch:report>
-  </sch:rule>
-</sch:pattern>

The term XML document is defined by this document.

7.2. Conformance to XML Namespaces
Rule 7-2. Document uses XML namespaces properly
[Rule 7-2] (REF, EXT, INS) (Constraint)
<sch:pattern>
-  <sch:rule context="*[. is nf:get-document-element(.)]">
-    <sch:report test="true()">The document MUST be namespace-well-formed and namespace-valid.</sch:report>
-  </sch:rule>
-</sch:pattern>

The terms namespace-well-formed and namespace-valid are normatively defined by [XML Namespaces] and [XML Namespaces Errata].

7.3. Conformance to XML Schema
Rule 7-3. Document is a schema document
[Rule 7-3] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="*[. is nf:get-document-element(.)]">
-    <sch:report test="true()">The document MUST be a schema document.</sch:report>
-  </sch:rule>
-</sch:pattern>

This document defines the term schema document.

Rule 7-4. Document element is xs:schema
[Rule 7-4] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term effective conformance target identifier.

5. The NIEM conceptual model

This section describes aspects of the RDF model, and provides a mapping between NIEM concepts and the RDF model.

5.1. Purpose of the NIEM conceptual model

Each release of NIEM provides a concrete data model, in the form of a set of schema documents. These schema documents may be used to build messages and information exchanges. The schema documents spell out what kinds of objects exist and how those objects may be related. A set of XML data that follows the rules of NIEM implies specific meaning. The varieties of schema components used within conformant schema documents 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 through the construction and use of schema components.

In a schema, the meaning of a schema component may be described using the xs:documentation element, or additional information may be included via use of the xs: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. This meaning is leveraged by NIEM.
  • NIEM’s use of the RDF model provides a basis for inferring 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 this section, 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.

5.2. The RDF model

This section identifies features of RDF and RDFS, in order to establish a mapping between RDF semantics and NIEM. A reader should read the referenced source documents to obtain a full understanding of the concepts mentioned in this section.

RDF establishes a graph-based data model, as described by [RDF Concepts] Section 1.1, Graph-based Data Model, which states:

The core structure of the abstract syntax is a set of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph.

[RDF Concepts] also states:

There can be three kinds of nodes in an RDF graph: IRIs, literals, and blank nodes.

[RDF Concepts] Section 1.2, Resources and Statements describes resources:

Any IRI or literal denotes something in the world (the universe of discourse). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with entity as it is used in the RDF Semantics specification. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its literal value.

[RDF Concepts] also describes relationships and blank nodes.

Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object. This statement corresponding to an RDF triple is known as an RDF statement. The predicate itself is an IRI and denotes a property, that is, a resource that can be thought of as a binary relation. (Relations that involve more than two entities can only be indirectly expressed in RDF.)

Unlike IRIs and literals, blank nodes do not identify specific resources. Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.

[RDF Concepts] Section 1.7, Equivalence, Entailment and Inconsistency describes the meaning of an RDF triple:

An RDF triple encodes a statement—a simple logical expression, or claim about the world. An RDF graph is the conjunction (logical AND) of its triples.

[RDF Concepts] Section 3.1, Triples defines an RDF triple:

An RDF triple consists of three components:

  • the subject, which is an IRI or a blank node
  • the predicate, which is an IRI
  • the object, which is an IRI, a literal or a blank node

An RDF triple is conventionally written in the order subject, predicate, object.

5.3. NIEM in terms of RDF

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 XML terminology, complex types and elements, rather than using RDF terms, resources and properties. NIEM objects and associations coincide with RDF resources; both objects and associations correspond to RDF resources with additional constraints:

NIEM associations are defined as n-ary properties, as described in [N-ary], Use Case 3: N-ary relation with no distinguished participant. NIEM associations are defined in Section 10.3, Associations, below. Assertions are made via NIEM-conformant XML data, described by Section 12, XML instance document rules, below.

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. These elements and attributes are XML Schema representations, which correspond to RDF properties. NIEM-conformant XML Schemas describe things and their properties. NIEM-conformant data contains elements and attributes. These correspond to RDF resources and their properties, which describe their characteristics and relationships.

5.4. Unique identification of data objects

A NIEM data exchange may be ephemeral and ad hoc. That is, a message may be transmitted without any expectation of persistence. Such a message 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 carried by a message to be identified by a URI.

A NIEM-conformant instance XML document may carry any of these attributes to identify objects within messages:

  • Attribute xml:base (of type xs:anyURI) is defined by [XML Base] Section 3, xml:base Attribute, which states:

    The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity.

    An XML document has an implicit base URI, the identifier of the document itself. This attribute allows the base URI to be made explicit within a NIEM XML document.

  • Attribute structures:uri (of type xs:anyURI) may appear within an XML element to define a URI for that element. This may be an absolute URI (e.g., http://example.org/incident182#person12), or may be a relative URI (e.g., #person12). Relative URIs are resolved against a URI determined by the xml:base attributes in scope, falling back to the base URI of the containing document.
  • Attribute structures:id (of type xs:ID) provides a document-relative identifier for an element. Semantically, structures:id="abe92" is equivalent to structures:uri="#abe92".
  • Attribute structures:ref (of type xs:IDREF) provides a reference to another element within a document, by providing a value of a structures:id attribute within the document. Semantically, structures:ref="abe92" is equivalent to structures:uri="#abe92"

The values of URIs and IDs within NIEM XML documents are not presumed to have any particular significance. XML requires every ID to be unique within its XML document, and for every IDREF to refer to an ID within the same document. The mapping of IDs and IDREFs to URIs does not mean that the identifiers are persistent or significant.

These attributes provide the identifiers of objects. The properties of an object may be spread across several XML elements that have the same identifier. These properties must be merged together to provide all the properties of a single object, as described by [JSON LD] Section 8.2, Node Objects:

The properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.

Mapping of NIEM data to RDF frequently involves the use of blank nodes, instead of universally-meaningful resource IRIs.

The identifier of an object is constructed using the above attributes; if the above attributes do not appear on an object, then an object may be treated as a blank node, and assigned a blank node identifier.

5.5. NIEM data 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.

5.6. Mapping of NIEM concepts to RDF concepts

This section provides RDF implementations for many aspects of NIEM-conformant schemas and instance documents.

5.6.1. Resource IRIs for XML Schema components and information items

The term qualified name is defined by [XML Namespaces] Section 2.1, Basic Concepts, which states:

A qualified name is a name subject to namespace interpretation.

A QName is used to represent a qualified name, as described by [XML Schema Datatypes] Section 3.2.18, QName, which states:

The value space of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName.

Certain components defined by NIEM schemas and instances have corresponding resource IRIs. Each IRI is taken from a qualified name, as follows:

  • If namespace name ends with #: concatenate(namespace name, local part)
  • Otherwise: concatenate(namespace name, #, local part)

Note that this is only meaningful when the namespace name is not empty and is an absolute URI.

The corresponding RDF resource IRIs for information items and schema components are:

  • element information item or attribute information item: the resource IRI is built from the qualified name constructed from its [namespace name] and [local name] properties.
  • schema component: the resource IRI is built from the qualified name constructed from its {target namespace} and {name} properties.
5.6.2. RDF Literals

A simple value may be incorporated into a conformant instance XML document as the value of an attribute information item, or as a child of an element information item. This section describes how a simple value is mapped to an RDF literal. Note that there is no mapping for the simple content of an element that is not a conformant element information item, nor for attributes defined by non-conformant schema documents, so there is no accommodation of mixed content, untyped values, or other cases outside of what conformant schema documents define.

For each occurrence of a simple value, the following may be relevant:

The literal for a simple value $value is:

  • If $value has a base type definition that is derived from type xs:string (and not an XML Schema-defined type derived from xs:string), and a non-empty language specification is applied to $value using xml:lang, as described by [XML] Section 2.12, Language Identification, then the literal is a language-tagged string, as described by [RDF Concepts] Section 3.3, Literals:

    "$lexical-form"@$language-tag

    Where:

    • $lexical-form is a Unicode string for $value.
    • $language-tag is the in-scope value of attribute xml:lang.

  • Otherwise, if $value has a base type definition $base-type that is listed as an RDF-compatible XSD type in [RDF Concepts] Section 5.1, The XML Schema Built-in Datatypes, then the literal is:

    "$lexical-form"^^$datatype-IRI

    Where:

    • $lexical-form is a Unicode string for $value.
    • $datatype-IRI is the QName of $base-type.

  • Otherwise, the literal is a simple literal, which is:

    "$lexical-form"

    Where: $lexical-form is a Unicode string for $value.

5.6.3. NIEM instance mappings to RDF

This section has the following subsections:

5.6.3.1. XML document mapping

A conformant instance XML document entails a corresponding RDF graph, which is a set of triples, which are entailed by the mapping of the contents of the XML document to RDF.

5.6.3.2. Element instance

A conformant element information item $element that has property [type definition] that is an object type or an association type, entails the RDF:

$object rdf:type $type .

Where:

  • $object is a node identifier for the object held by $element.
  • $type is resource IRI for the value of the [type definition] property of $element.

If $element has a non-empty simple value, then it also entails the RDF:

$object rdf:value $literal .

Where:

5.6.3.3. Element as a property with unknown context

A conformant element information item $element that

entails the RDF:

$context $predicate $object .

Where:

  • $context is a blank node, to represent the unknown context in which $element occurs.
  • $predicate is the IRI for element information item $element, to represent the semantics of the relationship.
  • $object is a node identifier for the object held by $element.
5.6.3.4. Element as a simple property of an object or association

A conformant element information item $context that is an instance of an object type or association type, and that has a child conformant element information item $element that is an instance of an object type or an association type, entails the RDF:

$subject $predicate $object .

Where:

  • $subject is a node identifier for the object held by $context.
  • $predicate is the IRI for $element.
  • $object is a node identifier for the object held by $element.
5.6.3.5. Attribute as a simple property of an object or association

An attribute information item $attribute where:

entails the RDF:

$subject $predicate $literal .

Where:

  • $subject is a node identifier for the object held by $context.
  • $predicate is the resource IRI for $attribute.
  • $literal is the literal value for $attribute, as described in Section 5.6.2, RDF Literals, above.
5.6.3.6. Elements via an augmentation type

An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association.

For each element applied to a type via an augmentation type:

  • Element information item $base that is an instance of an object type or association type,
  • Element information item $augmentation that is a child of $base that has [type definition] that is an augmentation type,
  • Element information item $resolved-augmentation is any augmentation element with an object that has the the same node identifier as the object held by $augmentation, and
  • Element information item $element that is a child of $resolved-augmentation, that has [type definition] that is an object type or an association type.

entails the RDF:

$subject $predicate $object .

Where:

  • $subject is the node identifier for the object held by $base.
  • $predicate is the resource IRI for [element declaration] of $element.
  • $object is the node identifier for the object held by $element
5.6.3.7. Attributes via an augmentation type

An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association.

For each attribute applied to a type via an augmentation type:

  • Element information item $base that is an instance of an object type or association type,
  • Element information item $augmentation that is a child of $base that has [type definition] that is an augmentation type,
  • Element information item $resolved-augmentation that is any augmentation element with an object that has the same node identifier as the object held by $augmentation,
  • Attribute information item $attribute that is owned by $resolved-augmentation, that has an [attribute declaration] that is defined by a reference schema document or an extension schema document

entails the RDF:

$subject $predicate $literal .

Where:

  • $subject is a node identifier for the object held by $base.
  • $predicate is the resource IRI for $attribute.
  • $literal is the literal value for $attribute, as described in Section 5.6.2, RDF Literals, above.
5.6.4. NIEM complex type definitions to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

An object type or association type $type entails the following RDF:

$resource rdf:type rdf:Class .

Where $resource is the resource IRI for $type.

An object type or association type $type that has property {base type definition} $base also entails the RDF:

$resource rdfs:subClassOf $base-resource

Where $base-resource is the resource IRI for $base.

5.6.5. NIEM element declaration mappings to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

A top-level element declaration schema component $element-declaration that has property {type definition} that is

  • the ur-type, or
  • is, or is derived from, structures:ObjectType, or
  • is, or is derived from, structures:AssociationType

entails the RDF:

$element-resource rdf:type rdf:Property .

Where $element-resource is the resource IRI for $element-declaration.

If $element-declaration has property {substitution group affiliation} with a value of element declaration $base, then it entails the RDF:

$element-resource rdfs:subPropertyOf $base-resource

Where:

  • $element-resource is the resource IRI for $element-declaration.
  • $base-resource is the resource IRI for $base.

If $element-declaration has property {type definition} with a value $type that is an object type or association type, then it entails the RDF:

$element-resource rdfs:range $type-resource

Where:

  • $element-resource is the resource IRI for $element-declaration.
  • $type-resource is the resource IRI for $type.
5.6.6. NIEM attribute declarations to RDF

The following RDF mappings apply to the content of a reference schema document or extension schema document.

A top-level attribute declaration schema component $attribute-declaration that has property {type definition} that is a simple type definition defined within a reference schema document or an extension schema document, then it entails the RDF:

$attribute-resource rdf:type rdf:Property .

Where $attribute-resource is the resource IRI for $attribute-declaration.

6. 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 organized as follows:

6.1. Specification guidelines

The principles in this section address what material should be included in this NDR and how it should be represented.

6.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.

6.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 and their instance documents. It should avoid specifying complex data models or data dictionaries.

[Principle 2]

This specification SHOULD focus on specifying characteristics of schema documents, their instance documents, and their interpretation.

6.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 that are specific, precise, and concise.

6.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.

6.2.1. Purpose of XML Schemas
[Principle 4]

The specification SHOULD focus on rules for XML Schemas in order to support:

  1. the expression of interface specifications for exchange of information between data producers and consumers,
  2. validation of XML documents against interface specifications,
  3. comprehension and understanding of XML documents, including the use of post-schema-validation infoset as defined by [XML Schema Structures] Section 2.1, Overview of XML Schema, and
  4. development of implementations supported by tools that use XML Schemas.
6.2.2. Prohibit XML parsing from constructing values

XML Schema has features that can make the data provided by an XML Schema validating parser differ from that provided by a non-validating XML parser. For example, if an XML Schema attribute declaration has a default value, and if an XML document omits the attribute where it might appear, an XML Schema validating parser will construct the attribute with the default value in the infoset that it provides to its caller. Without schema validation, there would be no attribute value, but after processing, the attribute value exists in the parsed data provided to the caller. Section 8.4, Ensure XML parsing does not construct values, below, provides more detail.

Within NIEM, the purpose of processing instances against schemas is primarily validation: testing that data instances match desired constraints and guidelines. It should not be used to alter the content of data passing through the parser.

[Principle 5]

The data of a NIEM-conformant XML document provided by an XML parser SHOULD NOT be modified by the process of validating the data against an XML Schema.

6.2.3. Use XML validating parsers for content validation

NIEM is designed for XML Schema validation. One 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 6]

NIEM-conformant schemas and NIEM-conformant XML documents SHOULD use features supported by XML Schema validating parsers for validation of XML content.

6.2.4. Validate for conformance to schema

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 validation against schemas 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 7]

Systems that use NIEM-conformant data SHOULD mark as invalid data that does not conform to the rules defined by applicable XML Schema documents.

6.2.5. Allow multiple schemas for XML constraints

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. Although NIEM is principally expressed as a set of reference schemas for a NIEM release, additional validation may be conducted through other mechanisms, which may include XML Schemas that express additional constraints, and business rules and structure-specifying languages other than the XML Schema definition language.

[Principle 8]

Constraints on XML instances MAY be validated by multiple validation passes, using multiple schemas and specifications for different aspects of each namespace.

6.2.6. 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 9]

Each NIEM-conformant namespace SHOULD be defined by exactly one reference schema.

6.2.7. 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 10]

NIEM-conformant schemas SHOULD NOT specify data that uses mixed content.

6.2.8. Specify types for all constructs

Every schema component defined by a NIEM-conformant schema that can have a name has a name. 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 11]

NIEM-conformant schemas SHOULD NOT use or define local or anonymous components, as they adversely affect reuse.

6.2.9. Avoid wildcards in 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 xs:any, which allows insertion of arbitrary elements) allows unstandardized data to be passed via otherwise standardized exchanges.

Avoidance of wildcards in the standard schemas encourages the separation of standardized and unstandardized 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 12]

NIEM-conformant components SHOULD NOT incorporate wildcards unless absolutely necessary, as they hinder standardization by encouraging use of unstandardized data rather than standardized data.

6.2.10. Schema locations provided in schema documents are hints

[XML Schema Structures] provides several mechanisms for acquiring components of an XML Schema for the purpose of assessing validity of an instance. [XML Schema Structures] Section 4.3.2, How schema definitions are located on the Web includes:

  • Use schema definitions already known to the processor.
  • Use a location URI or namespace name to identify a schema document from a network location or local schema repository.
  • Attempt to resolve a location URI or namespace name to locate a schema document.

In addition, there are several ways for a processor to determine schema locations:

  • Use schema locations identified by user direction.
  • Use locations provided via xsi:schemaLocation or xsi:noNamespaceSchemaLocation attributes in an XML document under assessment.
  • Use schema locations provided by xs:import elements.

[XML Schema Structures] characterizes several of these methods as hints of where to acquire a schema document for assessment. [XML Schema Structures] Section 2.6.3, xsi:schemaLocation, xsi:noNamespaceSchemaLocation states:

The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which may be used for assessment.

[XML Schema Structures] Section 4.2.3, References to schema components across namespaces states:

The actual value of the schemaLocation, if present, gives a hint as to where a serialization of a schema document with declarations and definitions for that namespace (or none) may be found.

The specification explicitly maintains that schema location provided in schemas or instances may be overridden by applications or by user direction.

[Principle 13]

Schema locations specified within NIEM-conformant reference schemas SHOULD be interpreted as hints and as default values by processing applications.

In accordance with Section 1.1, Scope, above, this document does not provide normative guidance for location of schema documents or for schema assembly.

6.2.11. 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 14]

NIEM standards and schemas SHOULD leverage and enable use of other open standards.

6.3. Modeling design guidelines

The principles in this section address the design philosophy used in designing the NIEM conceptual model.

6.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 a NIEM-conformant schema, 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 15]

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 6-1: Example of the use of a namespace
<xs: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 16]

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.

6.3.2. Design NIEM for extensibility

NIEM is designed to be extended. Numerous methods are considered acceptable in creating extended and specialized components.

[Principle 17]

NIEM-conformant schemas and standards SHOULD be designed to encourage and ease extension and augmentation by users and developers outside the NIEM governance process.

6.4. Implementation guidelines

The principles in this section address issues pertaining to the implementation of applications that use NIEM.

6.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. Structured XML content does not belong in places targeting humans. Human-targeted information should be of a form suitable for presentation.

[Principle 18]

XML data SHOULD be designed for automatic processing. XML data SHOULD NOT be designed for literal presentation to people. NIEM specifications and schemas SHOULD NOT use literal presentation of XML data to people as a design criterion.

6.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 19]

NIEM SHOULD NOT depend on specific software packages, software frameworks, or software systems for interpretation of XML instances.

[Principle 20]

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.

6.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.

6.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 schema component’s data 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 21]

The data definition of a component SHOULD be drafted before the component’s name is composed.

6.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 22]

Components in NIEM SHOULD be given names that are consistent with names of other NIEM components. Such names SHOULD be based on simple rules.

6.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 23]

Component definitions in NIEM-conformant schemas SHOULD reflect real-world concepts.

It is important for the modeler to understand what she is modeling; a person, an observation of a person, and a drivers license for a person are all at different levels, although they each may contain similar information.

6.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 24]

Component definitions in NIEM-conformant schemas SHOULD have semantic consistency.

6.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 25]

Complex type definitions in NIEM-conformant schemas SHOULD use type inheritance only for specialization.

Note that the use of augmentations allows developers to avoid type specialization in many cases; see Section 10.4, Augmentations, below.

6.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.

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 26]

Multiple components with identical or undifferentiated semantics SHOULD NOT be defined. Component definitions SHOULD have clear, explicit distinctions.

6.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 27]

NIEM-conformant schemas SHOULD have the simplest possible structure, content, and architecture consistent with real business requirements.

6.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 28]

Components defined by NIEM-conformant schemas SHOULD be defined appropriate for their scope.

6.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 29]

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.

7. Conformance to standards
7.1. Conformance to XML
Rule 7-1. Document is an XML document
[Rule 7-1] (REF, EXT, INS) (Constraint)

The document MUST be an XML document.

The term XML document is defined by this document.

7.2. Conformance to XML Namespaces
Rule 7-2. Document uses XML namespaces properly
[Rule 7-2] (REF, EXT, INS) (Constraint)

The document MUST be namespace-well-formed and namespace-valid.

The terms namespace-well-formed and namespace-valid are normatively defined by [XML Namespaces] and [XML Namespaces Errata].

7.3. Conformance to XML Schema
Rule 7-3. Document is a schema document
[Rule 7-3] (REF, EXT) (Constraint)

The document MUST be a schema document.

This document defines the term schema document.

Rule 7-4. Document element is xs:schema
[Rule 7-4] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[. is nf:get-document-element(.)]">
     <sch:assert test="self::xs:schema"
       >The [document element] of the XML document MUST have the name xs:schema.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term XML document.

7.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-4] as a baseline for its data component definitions.

To advance the goal of creating semantically rich NIEM-conformant schemas, it is necessary that data definitions be descriptive, meaningful, and precise. [ISO 11179-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-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-4], NIEM applies additional rules to data definitions. These rules are detailed in Section 11.6.1, Human-readable documentation, below.

These definitions leverage the term definition as defined by [ISO 11179-4]:

representation of a concept by a descriptive statement which serves to differentiate it from related concepts

[Definition: data definition]

The data definition of a schema component is the content of the first occurrence of the element xs:documentation that is an immediate child of an occurrence of an element xs:annotation that is an immediate child of the element that defines the component.

[Definition: documented component]

In a NIEM-conformant schema, a documented component is schema component that has an associated data definition. Each documented component has a textual definition, so that the component may be well-understood.

An example of a data definition is provided in Figure 7-1, Example of data definition of element nc:Activity, below.

Figure 7-1: Example of data definition of element nc:Activity
<xs:element name="Activity" type="nc:ActivityType" nillable="true">
+</sch:pattern>

This document defines the term XML document.

7.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-4] as a baseline for its data component definitions.

To advance the goal of creating semantically rich NIEM-conformant schemas, it is necessary that data definitions be descriptive, meaningful, and precise. [ISO 11179-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-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-4], NIEM applies additional rules to data definitions. These rules are detailed in Section 11.6.1, Human-readable documentation, below.

These definitions leverage the term definition as defined by [ISO 11179-4]:

representation of a concept by a descriptive statement which serves to differentiate it from related concepts

[Definition: data definition]

The data definition of a schema component is the content of the first occurrence of the element xs:documentation that is an immediate child of an occurrence of an element xs:annotation that is an immediate child of the element that defines the component.

[Definition: documented component]

In a NIEM-conformant schema, a documented component is schema component that has an associated data definition. Each documented component has a textual definition, so that the component may be well-understood.

An example of a data definition is provided in Figure 7-1, Example of data definition of element nc:Activity, below.

Figure 7-1: Example of data definition of element nc:Activity
<xs:element name="Activity" type="nc:ActivityType" nillable="true">
   <xs:annotation>
     <xs:documentation>A single or set of related actions, events, or process steps.</xs:documentation>
   </xs:annotation>
-</xs:element>

See Rule 11-29, Data definition follows 11179-4 requirements (REF, EXT), below, and Rule 11-30, Data definition follows 11179-4 recommendations (REF, EXT), below, for application of [ISO 11179-4] to constrain NIEM data definitions.

7.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-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 7-5. Component name follows ISO 11179 Part 5 Annex A
[Rule 7-5] (REF, EXT) (Constraint)

A NIEM component name MUST be formed by applying the informative guidelines and examples detailed in Annex A of [ISO 11179-5], with exceptions as specified in this document.

The guidelines and examples of [ISO 11179-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-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 the relevant sections. In spite of these exceptions, most NIEM component names can be disassembled into their [ISO 11179-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 10.8, Naming rules, below, details the specific rules for each kind of term and how to construct NIEM component names from it.

7.6. IC-ISM and IC-NTK

The Office of the Director of National Intelligence manages and maintains a set of specifications that support the requirements of the Intelligence Community (IC) to share and manage data across the IC enterprise. These specifications are available at http://purl.org/ic/standards/public. The design of NIEM supports the use of NIEM-conformant data across the IC.

The following features have been provided to support the use of NIEM-conformant data definitions across the IC, by supporting the use of IC-ISM and IC-NTK within NIEM-defined data:

These features ensure that payloads that correctly use IC-ISM AND IC-NTK are supported by NIEM-conformant schema definitions.

8. Strategy for a NIEM profile of XML Schema
8.1. Wildcards

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 12], above, 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.

The following restrictions help to ban wildcards and arbitrary data:

  • Use of the type xs:anyType is prohibited.
  • Use of the type xs:anySimpleType is prohibited in most cases.
  • Use of the element xs:any is prohibited in reference schemas.
  • Use of the element xs:anyAttribute is prohibited in reference schemas.
8.2. Components are globally reusable

Each component defined by a NIEM-conformant schema may be reused from outside the schema document. Every type definition, element declaration, or attribute declaration schema component that is defined by a NIEM-conformant schema is given an explicit name. These schema components are not defined as local or anonymous. These components are defined at the top level, as children of element xs:schema.

This is supported by the rules:

Additional restrictions ensure that NIEM components are also defined such that new components may be derived from them and substituted for them. Reference schemas are defined to maximize reuse, while extension schemas are defined to enable a developer to customize schema definitions to match her exchange needs. In reference schemas, the following restrictions help enforce reusability through extension and substitution:

8.3. Avoid recursive model groups

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. The rules in this document restrict the use of nested model groups, in order 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.

8.4. Ensure schema processing does not alter processed data

XML Schema provides the capability for element and attribute declarations to provide default values when XML instances using those components do not provide values. This is done through the use of the attributes default and fixed, both of which provide default values to attributes and element content.

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 described by Section 6.2.2, Disallow content modification with XML processors, above.

The transparency of validation to data content is ensured through a prohibition on the use of default and fixed attributes in NIEM-conformant schema documents.

8.5. Use namespaces rigorously

Every component defined by or used in a NIEM schema has a target namespace.

XML Schema requires that namespaces used in external references be imported using the xs:import element. The xs:import element appears as an immediate child of the xs:schema element. A schema must import any namespace which is not the local namespace, and which 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.

Certain tools have been seen introducing transitive behavior on imports, which is not portable across XML Schema validating parsers. If namespace 1 imports namespace 2 which imports namespace 3, a reference from namespace 1 to namespace 3 is not legal; namespace 1 must explicitly import namespace 3. A tool that imports transitively may allow schema 1 to reference 3 without a direct import of namespace 3. This is prohibited by rules which require imports of namespaces of referenced components.

8.6. Documentation is for people; appinfo is for machines

The XML Schema specification defines two types of annotations: user information and application information. It defines that user information is for human consumption, while application information is for automatic processing.

[XML Schema Structures] Section 3.13, Annotations states:

Annotations provide for human- and machine-targeted annotations of schema components.

[XML Schema Structures] Section 3.13.1, The Annotation Schema Component states:

{user information} is intended for human consumption, {application information} for automatic processing.

The two types: human-targeted and machine-targeted, are kept separate by the use of two separate container elements defined by XML Schema: xs:documentation and xs:appinfo.

xs:documentation elements express user information. This information is targeted for reading by humans. The XML Schema specification does not say what form human-targeted information should take. Since it is intended for human consumption, xs:documentation elements in conformant schemas do not contain structured XML data. As such, any XML content appearing within a documentation element should be human-targeted examples, and should be escaped (e.g., using &lt; and &gt;, or using CDATA blocks). Documentation within conformant schemas should be plain text; whitespace formatting may not be preserved across processing.

xs:appinfo elements express application information. This is generally information supporting automatic processing of schemas. Application information is addressed in Section 10.9, Machine-readable annotations, below.

XML comments are not XML Schema constructs and are not specifically associated with any schema-based component; they are not considered semantically meaningful by NIEM and may not be retained through processing of NIEM schemas.

9. Rules for a NIEM profile of XML Schema

NIEM-conformant schemas use a profile of XML Schema. The W3C XML Schema Language provides many features that allow a developer to represent a data model many different ways. 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.

This section establishes a profile of XML Schema for 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 schema documents (i.e., non-NIEM-conformant schema documents) do not need to obey the rules set forth in this section. So long as schema components from external schema documents are adapted for use with NIEM according to the modeling rules in Section 10.2.3, External adapter types and external components, below, they may be used as they appear in the external standard, even if the schema components themselves violate the rules for NIEM-conformant schemas.

The following sections are broken down in the order provided by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, followed by a section on a schema document as a whole and a section on schema namespaces and assembly:

9.1. Type definition components
9.1.1. Type definition hierarchy
9.1.1.1. Types prohibited as base types
Rule 9-1. No base type in the XML namespace

Although the XML namespace is to be imported as if it is conformant, types from that namespace may not be the base type definition of any type.

[Rule 9-1] (REF, EXT) (Constraint)
<sch:pattern>
+</xs:element>

See Rule 11-27, Data definition follows 11179-4 requirements (REF, EXT), below, and Rule 11-28, Data definition follows 11179-4 recommendations (REF, EXT), below, for application of [ISO 11179-4] to constrain NIEM data definitions.

7.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-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 7-5. Component name follows ISO 11179 Part 5 Annex A
[Rule 7-5] (REF, EXT) (Constraint)

A NIEM component name SHOULD be formed by applying the informative guidelines and examples detailed in Annex A of [ISO 11179-5], with exceptions as specified in this document.

The guidelines and examples of [ISO 11179-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-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 the relevant sections. In spite of these exceptions, most NIEM component names can be disassembled into their [ISO 11179-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 10.8, Naming rules, below, details the specific rules for each kind of term and how to construct NIEM component names from it.

7.6. IC-ISM and IC-NTK

The Office of the Director of National Intelligence manages and maintains a set of specifications that support the requirements of the Intelligence Community (IC) to share and manage data across the IC enterprise. These specifications are available at http://purl.org/ic/standards/public. The design of NIEM supports the use of NIEM-conformant data across the IC.

The following features have been provided to support the use of NIEM-conformant data definitions across the IC, by supporting the use of IC-ISM and IC-NTK within NIEM-defined data:

These features ensure that payloads that correctly use IC-ISM AND IC-NTK are supported by NIEM-conformant schema definitions.

8. Strategy for a NIEM profile of XML Schema
8.1. Wildcards

There are many constructs within XML Schema that act as wildcards. That is, they introduce buckets that may carry arbitrary or otherwise not-validated content. Such constructs violate [Principle 12], above, 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.

The following restrictions help to ban wildcards and arbitrary data:

  • Use of the type xs:anyType is prohibited.
  • Use of the type xs:anySimpleType is prohibited in most cases.
  • Use of the element xs:any is prohibited in reference schemas.
  • Use of the element xs:anyAttribute is prohibited in reference schemas.
8.2. Components are globally reusable

Each component defined by a NIEM-conformant schema may be reused from outside the schema document. Every type definition, element declaration, or attribute declaration schema component that is defined by a NIEM-conformant schema is given an explicit name. These schema components are not defined as local or anonymous. These components are defined at the top level, as children of element xs:schema.

This is supported by the rules:

Additional restrictions ensure that NIEM components are also defined such that new components may be derived from them and substituted for them. Reference schemas are defined to maximize reuse, while extension schemas are defined to enable a developer to customize schema definitions to match her exchange needs. In reference schemas, the following restrictions help enforce reusability through extension and substitution:

8.3. Avoid recursive model groups

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. The rules in this document restrict the use of nested model groups, in order 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.

8.4. Ensure XML parsing does not construct values

An XML document expresses an infoset (see [XML Infoset]); the infoset is the data carried by the XML document, and is expressed as a set of information items (e.g., element information items, attribute information items, etc.). [XML Schema Structures] Section 2.1, Overview of XML Schema describes the process followed by an XML Schema validating parser. Beyond the actions of a plain XML parser, which provides the data from an XML document to its caller in a structured way, an XML Schema validating parser does the following:

  1. Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;
  2. Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

In short, not only does an XML Schema validating parser yield data from an XML document to its caller, it determines whether the XML document is valid against an XML Schema, and also provides an augmented infoset to the caller, constructed to reflect information implied by the schema, which may not appear in the original XML document.

XML Schema provides for element and attribute declarations to provide default values. When an XML document does not contain a value for a component that has a default, the XML Schema validating parser will construct a value for the component. This is done through the use of the attributes default and fixed, both of which provide default values to attributes and element content. An XML Schema validating parser that validates an XML document against a schema that uses default or fixed may yield an infoset that is augmented, constructing values in the provided XML infoset where none existed in the original XML document.

NIEM schemas should not be constructed to yield constructed values in the infoset. The process of XML Schema validation against NIEM schemas should provide for marking data as valid or invalid, but should not modify original infoset data with constructed values. The XML infoset yielded by a non-validating XML parser should be the same as that yielded by an XML Schema validating parser. Turning on schema validation should not alter the data received by the caller of the parser.

The prohibition of constructed values is supported by Section 6.2.2, Prohibit XML parsing from constructing values, above. It is also supported through a prohibition on all uses of default, and most uses of fixed on attributes and elements defined by NIEM-conformant schema documents.

8.5. Use namespaces rigorously

Every component defined by or used in a NIEM schema has a target namespace.

XML Schema requires that namespaces used in external references be imported using the xs:import element. The xs:import element appears as an immediate child of the xs:schema element. A schema must import any namespace which is not the local namespace, and which 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.

Certain tools have been seen introducing transitive behavior on imports, which is not portable across XML Schema validating parsers. If namespace 1 imports namespace 2 which imports namespace 3, a reference from namespace 1 to namespace 3 is not legal; namespace 1 must explicitly import namespace 3. A tool that imports transitively may allow schema 1 to reference 3 without a direct import of namespace 3. This is prohibited by rules which require imports of namespaces of referenced components.

8.6. Documentation is for people; appinfo is for machines

The XML Schema specification defines two types of annotations: user information and application information. It defines that user information is for human consumption, while application information is for automatic processing.

[XML Schema Structures] Section 3.13, Annotations states:

Annotations provide for human- and machine-targeted annotations of schema components.

[XML Schema Structures] Section 3.13.1, The Annotation Schema Component states:

{user information} is intended for human consumption, {application information} for automatic processing.

The two types: human-targeted and machine-targeted, are kept separate by the use of two separate container elements defined by XML Schema: xs:documentation and xs:appinfo.

xs:documentation elements express user information. This information is targeted for reading by humans. The XML Schema specification does not say what form human-targeted information should take. Since it is intended for human consumption, xs:documentation elements in conformant schemas do not contain structured XML data. As such, any XML content appearing within a documentation element should be human-targeted examples, and should be escaped (e.g., using &lt; and &gt;, or using CDATA blocks). Documentation within conformant schemas should be plain text; whitespace formatting may not be preserved across processing.

xs:appinfo elements express application information. This is generally information supporting automatic processing of schemas. Application information is addressed in Section 10.9, Machine-readable annotations, below.

XML comments are not XML Schema constructs and are not specifically associated with any schema-based component; they are not considered semantically meaningful by NIEM and may not be retained through processing of NIEM schemas.

9. Rules for a NIEM profile of XML Schema

NIEM-conformant schemas use a profile of XML Schema. The W3C XML Schema Language provides many features that allow a developer to represent a data model many different ways. 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.

This section establishes a profile of XML Schema for 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 schema documents (i.e., non-NIEM-conformant schema documents) do not need to obey the rules set forth in this section. So long as schema components from external schema documents are adapted for use with NIEM according to the modeling rules in Section 10.2.3, External adapter types and external components, below, they may be used as they appear in the external standard, even if the schema components themselves violate the rules for NIEM-conformant schemas.

The following sections are broken down in the order provided by [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, followed by a section on a schema document as a whole and a section on schema namespaces and assembly:

9.1. Type definition components
9.1.1. Type definition hierarchy
9.1.1.1. Types prohibited as base types
Rule 9-1. No base type in the XML namespace

Although the XML namespace is to be imported as if it is conformant, types from that namespace may not be the base type definition of any type.

[Rule 9-1] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@base)]">
     <sch:assert test="namespace-uri-from-QName(resolve-QName(@base, .)) != xs:anyURI('http://www.w3.org/XML/1998/namespace')"
                 >A schema component must not have a base type definition with a {target namespace} that is the XML namespace.</sch:assert>
   </sch:rule>
-</sch:pattern>

The term base type definition has a normative definition.

Rule 9-2. No base type of xs:ID
[Rule 9-2] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The term base type definition has a normative definition.

Rule 9-2. No base type of xs:ID
[Rule 9-2] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@base)]">
     <sch:assert test="resolve-QName(@base, .) != xs:QName('xs:ID')"
       >A schema component MUST NOT have an attribute {}base with a value of xs:ID.</sch:assert>
@@ -138,113 +94,120 @@
                         string-length(normalize-space(string($definition))) &gt; 0"
       >A simple type MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term data definition.

9.1.2.1. Simple types prohibited as list item types

There is no explicit prohibition on the use of xs:NOTATION as list item type, because it is prohibited by [XML Schema Datatypes].

There is no prohibition on xs:anyType as a list item type, because xs:anyType is not a simple type.

Rule 9-13. No list item type of xs:ID
[Rule 9-13] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term data definition.

Rule 9-13. No use of fixed on simple type facets

An attribute fixed on a constraining facet (e.g., xs:maxInclusive) of a simple type $base prevents a simple type derived from $base from further restricting that facet. For example, if simpleType nc:LatitudeDegreeSimpleType uses an xs:maxInclusive facet that limits the maximum value to 90, a simple type derived from that type could not further restrict the type to limit the maximum value to 45.

The use of fixed on simple type facets violates [Principle 17], above, since it prevents an extension schema from constraining a base type. As a result, the fixed on simple type facets in reference schemas is prohibited.

[Rule 9-13] (REF) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:*[self::xs:length or self::xs:minLength or self::xs:maxLength or self::xs:whiteSpace
+      or self::xs:maxInclusive or self::xs:maxExclusive or self::xs:minExclusive or self::xs:minInclusive 
+      or self::xs:totalDigits or self::xs:fractionDigits]">
+    <sch:assert test="empty(@fixed)"
+      >A simple type constraining facet MUST NOT have an attribute {}fixed.</sch:assert>
+  </sch:rule>
+</sch:pattern>
9.1.2.1. Simple types prohibited as list item types

There is no explicit prohibition on the use of xs:NOTATION as list item type, because it is prohibited by [XML Schema Datatypes].

There is no prohibition on xs:anyType as a list item type, because xs:anyType is not a simple type.

Rule 9-14. No list item type of xs:ID
[Rule 9-14] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@itemType)]">
     <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:ID')"
       >A schema component MUST NOT have an attribute {}itemType with a value of xs:ID.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-14. No list item type of xs:IDREF
[Rule 9-14] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-15. No list item type of xs:IDREF
[Rule 9-15] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@itemType)]">
     <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:IDREF')"
       >A schema component MUST NOT have an attribute {}itemType with a value of xs:IDREF.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-15. No list item type of xs:anySimpleType
[Rule 9-15] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-16. No list item type of xs:anySimpleType
[Rule 9-16] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@itemType)]">
     <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:anySimpleType')"
       >A schema component MUST NOT have an attribute {}itemType with a value of xs:anySimpleType.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-16. No list item type of xs:ENTITY
[Rule 9-16] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-17. No list item type of xs:ENTITY
[Rule 9-17] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@itemType)]">
     <sch:assert test="resolve-QName(@itemType, .) != xs:QName('xs:ENTITY')"
       >A schema component MUST NOT have an attribute {}itemType with a value of xs:ENTITY.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.1.2.2. Simple types prohibited as union member types

There is no explicit prohibition on the use of xs:NOTATION as a union member type, because it is prohibited by [XML Schema Datatypes].

There is no prohibition on xs:anyType as a union member type, because xs:anyType is not a simple type.

Rule 9-17. No union member types of xs:ID
[Rule 9-17] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.1.2.2. Simple types prohibited as union member types

There is no explicit prohibition on the use of xs:NOTATION as a union member type, because it is prohibited by [XML Schema Datatypes].

There is no prohibition on xs:anyType as a union member type, because xs:anyType is not a simple type.

Rule 9-18. No union member types of xs:ID
[Rule 9-18] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:ID')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ID.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-18. No union member types of xs:IDREF
[Rule 9-18] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-19. No union member types of xs:IDREF
[Rule 9-19] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:IDREF')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREF.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-19. No union member types of xs:IDREFS
[Rule 9-19] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-20. No union member types of xs:IDREFS
[Rule 9-20] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:IDREFS')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:IDREFS.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-20. No union member types of xs:anySimpleType
[Rule 9-20] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-21. No union member types of xs:anySimpleType
[Rule 9-21] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:anySimpleType')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:anySimpleType.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-21. No union member types of xs:ENTITY
[Rule 9-21] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-22. No union member types of xs:ENTITY
[Rule 9-22] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:ENTITY')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITY.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-22. No union member types of xs:ENTITIES
[Rule 9-22] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-23. No union member types of xs:ENTITIES
[Rule 9-23] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@memberTypes)]">
     <sch:assert test="every $type-qname
                       in tokenize(normalize-space(@memberTypes), ' ')
                       satisfies resolve-QName($type-qname, .) != xs:QName('xs:ENTITIES')"
       >A schema component MUST NOT have an attribute {}memberTypes that includes a value of xs:ENTITIES.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-23. Enumeration has data definition
[Rule 9-23] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-24. Enumeration has data definition
[Rule 9-24] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:enumeration">
     <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >An enumeration facet MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term data definition.

9.1.3. Complex type definition
Rule 9-24. Complex type definitions is top-level
[Rule 9-24] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term data definition.

9.1.3. Complex type definition
Rule 9-25. Complex type definitions is top-level
[Rule 9-25] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:assert test="exists(parent::xs:schema)"
       >A complex type definition MUST be top-level.</sch:assert>
   </sch:rule>
-</sch:pattern>

Note that this implies that every xs:complexType element has a name attribute.

Rule 9-25. Complex type has data definition
[Rule 9-25] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Note that this implies that every xs:complexType element has a name attribute.

Rule 9-26. Complex type has data definition
[Rule 9-26] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >A complex type MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term data definition.

9.1.3.1. No mixed content
Rule 9-26. No mixed content on complex type
[Rule 9-26] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term data definition.

9.1.3.1. No mixed content
Rule 9-27. No mixed content on complex type
[Rule 9-27] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[exists(@mixed)]">
     <sch:assert test="xs:boolean(@mixed) = false()"
       >A complex type definition MUST NOT have mixed content.</sch:assert>
   </sch:rule>
-</sch:pattern>

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 schema documents 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 10], above.

Rule 9-27. No mixed content on complex content
[Rule 9-27] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

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 schema documents 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 10], above.

Rule 9-28. No mixed content on complex content
[Rule 9-28] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexContent[exists(@mixed)]">
     <sch:assert test="xs:boolean(@mixed) = false()"
       >A complex type definition with complex content MUST NOT have mixed content.</sch:assert>
   </sch:rule>
-</sch:pattern>

See Rule 9-26, No mixed content on complex type (REF, EXT), above, for the rationale for this rule.

Rule 9-28. Complex type content is explicitly simple or complex
[Rule 9-28] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

See Rule 9-27, No mixed content on complex type (REF, EXT), above, for the rationale for this rule.

Rule 9-29. Complex type content is explicitly simple or complex
[Rule 9-29] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:assert test="exists(xs:simpleContent) or exists(xs:complexContent)"
       >An element xs:complexType MUST have a child element xs:simpleContent or xs:complexContent.</sch:assert>
   </sch:rule>
-</sch:pattern>

XML Schema provides shorthand to defining complex content of a complex type, which is to define the complex type with immediate children that specify elements, or other groups, and attributes. In the desire to normalize schema representation of types and to be explicit, NIEM forbids the use of that shorthand.

9.1.3.2. Complex content
Rule 9-29. Complex content uses extension
[Rule 9-29] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>

XML Schema provides shorthand to defining complex content of a complex type, which is to define the complex type with immediate children that specify elements, or other groups, and attributes. In the desire to normalize schema representation of types and to be explicit, NIEM forbids the use of that shorthand.

9.1.3.2. Complex content
Rule 9-30. Complex content uses extension
[Rule 9-30] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexContent">
     <sch:assert test="exists(xs:extension)"
       >An element xs:complexContent MUST have a child xs:extension.</sch:assert>
   </sch:rule>
-</sch:pattern>

NIEM does not support the use of complex type restriction in reference schemas. The use of restriction in a reference schema would reduce the ability for that schema to be reused. Restriction may be used in extension schemas.

9.1.3.2.1. Base type of complex type with complex content has complex content

These two rules addresses a peculiarity of the XML Schema definition language, which allows a complex type to be constructed using xs:complexContent, and yet is derived from a complex type that uses xs:simpleContent. These rules ensures that each type has the content style indicated by the schema. An example is included in the following figure. Note that type niem-xs:integer is a complex type with simple content.

Figure 9-1: Example of complex type with simple content that claims to have complex content
<xs:complexType name="TreeCountType">
+</sch:pattern>

NIEM does not support the use of complex type restriction in reference schemas. The use of restriction in a reference schema would reduce the ability for that schema to be reused. Restriction may be used in extension schemas.

9.1.3.2.1. Base type of complex type with complex content has complex content

These two rules addresses a peculiarity of the XML Schema definition language, which allows a complex type to be constructed using xs:complexContent, and yet is derived from a complex type that uses xs:simpleContent. These rules ensures that each type has the content style indicated by the schema. An example is included in the following figure. Note that type niem-xs:integer is a complex type with simple content.

Figure 9-1: Example of complex type with simple content that claims to have complex content
<xs:complexType name="TreeCountType">
   <xs:annotation>
     <xs:documentation>A data type for a number of trees</xs:documentation>
   </xs:annotation>
   <xs:complexContent>
     <xs:extension base="niem-xs:integer"/>
   </xs:complexContent>
-</xs:complexType>

The first rule handles cases that can be determined within a single schema document, while the SET version handles cases that require cross-schema resolution.

Rule 9-30. Base type of complex type with complex content must have complex content
[Rule 9-30] (REF, EXT) (Constraint)
<sch:pattern>
+</xs:complexType>

The first rule handles cases that can be determined within a single schema document, while the SET version handles cases that require cross-schema resolution.

Rule 9-31. Base type of complex type with complex content must have complex content
[Rule 9-31] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType/xs:complexContent/xs:*[
                        (self::xs:extension or self::xs:restriction)
                        and (some $base-qname in resolve-QName(@base, .) satisfies
@@ -253,7 +216,7 @@
                         empty($base-type/self::xs:complexType/xs:simpleContent)"
       >The base type of complex type that has complex content MUST be a complex type with complex content.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-31. Base type of complex type with complex content must have complex content
[Rule 9-31] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-32. Base type of complex type with complex content must have complex content
[Rule 9-32] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[
         nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument'))
         or nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument'))
@@ -264,58 +227,58 @@
                          empty($base-type/self::xs:complexType/xs:simpleContent)"
       >The base type of complex type that has complex content MUST have complex content.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.1.3.3. Simple content
Rule 9-32. Simple content uses extension
[Rule 9-32] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
9.1.3.3. Simple content
Rule 9-33. Simple content uses extension
[Rule 9-33] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:simpleContent">
     <sch:assert test="exists(xs:extension)"
       >A complex type definition with simple content schema component MUST have a derivation method of extension.</sch:assert>
   </sch:rule>
-</sch:pattern>

This rule ensures that the definition of a complex type with simple content will use XML Schema extension. This allows for the above cases while disallowing more complicated syntactic options available in XML Schema. The above rule allows for use of xs:restriction within xs:simpleContent in extension schemas.

Rule 9-33. No complex type disallowed substitutions
[Rule 9-33] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>

This rule ensures that the definition of a complex type with simple content will use XML Schema extension. This allows for the above cases while disallowing more complicated syntactic options available in XML Schema. The above rule allows for use of xs:restriction within xs:simpleContent in extension schemas.

Rule 9-34. No complex type disallowed substitutions
[Rule 9-34] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:assert test="empty(@block)"
       >An element xs:complexType MUST NOT have an attribute {}block.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-34. No complex type disallowed derivation
[Rule 9-34] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-35. No complex type disallowed derivation
[Rule 9-35] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:assert test="empty(@final)"
       >An element xs:complexType MUST NOT have an attribute {}final.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.2. Declaration components
9.2.1. Element declaration

Every element declaration in a NIEM-conformant schema document is a top-level element; rules prohibit the declaration of local elements.

Within a NIEM-conformant schema document, an element may be declared as abstract. Elements may be defined without a type, but any element declaration that has no type must be declared abstract, as specified by Rule 9-37, Untyped element is abstract (REF, EXT), below.

Within an element declaration, the attributes fixed, nillable, and substitutionGroup may be used as per the XML Schema specification. The attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local element declarations, as specified by Rule 9-35, Element declaration is top-level (REF, EXT), below.

Rule 9-35. Element declaration is top-level
[Rule 9-35] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.2. Declaration components
9.2.1. Element declaration

Every element declaration in a NIEM-conformant schema document is a top-level element; rules prohibit the declaration of local elements.

Within a NIEM-conformant schema document, an element may be declared as abstract. Elements may be defined without a type, but any element declaration that has no type must be declared abstract, as specified by Rule 9-38, Untyped element is abstract (REF, EXT), below.

Within an element declaration, the attributes fixed, nillable, and substitutionGroup may be used as per the XML Schema specification. The attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local element declarations, as specified by Rule 9-36, Element declaration is top-level (REF, EXT), below.

Rule 9-36. Element declaration is top-level
[Rule 9-36] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name)]">
     <sch:assert test="exists(parent::xs:schema)"
       >An element declaration MUST be top-level.</sch:assert>
   </sch:rule>
-</sch:pattern>

All schema components defined by NIEM-conformant schemas must be named, accessible from outside the defining schema, and reusable across schemas. Local element declarations 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.

Rule 9-36. Element declaration has data definition
[Rule 9-36] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

All schema components defined by NIEM-conformant schemas must be named, accessible from outside the defining schema, and reusable across schemas. Local element declarations 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.

Rule 9-37. Element declaration has data definition
[Rule 9-37] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name)]">
     <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >An element declaration MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term data definition.

Rule 9-37. Untyped element is abstract
[Rule 9-37] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term data definition.

Rule 9-38. Untyped element is abstract
[Rule 9-38] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema/xs:element[empty(@type)]">
     <sch:assert test="exists(@abstract)
                       and xs:boolean(@abstract) = true()"
       >A top-level element declaration that does not set the {type definition} property via the attribute "type" MUST have the {abstract} property with a value of "true".</sch:assert>
   </sch:rule>
-</sch:pattern>

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.

Rule 9-38. Element of type xs:anySimpleType is abstract

The type xs:anySimpleType does not have any concrete semantics; The use of xs:anySimpleType is limited to the case where an abstract element is of type xs:anySimpleType, to act as a base for concrete implementations of the element.

[Rule 9-38] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

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.

Rule 9-39. Element of type xs:anySimpleType is abstract

The type xs:anySimpleType does not have any concrete semantics; The use of xs:anySimpleType is limited to the case where an abstract element is of type xs:anySimpleType, to act as a base for concrete implementations of the element.

[Rule 9-39] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@type)
                                 and resolve-QName(@type, .) = xs:QName('xs:anySimpleType')]">
     <sch:assert test="exists(@abstract)
                       and xs:boolean(@abstract) = true()"
                 >An element declaration that has a type xs:anySimpleType MUST have the {abstract} property with a value of "true".</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-39. Element type not in the XML Schema namespace
[Rule 9-39] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-40. Element type not in the XML Schema namespace
[Rule 9-40] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@type)]">
     <sch:assert test="for $type-qname in resolve-QName(@type, .) return
                         $type-qname = xs:QName('xs:anySimpleType')
                         or namespace-uri-from-QName($type-qname) != xs:anyURI('http://www.w3.org/2001/XMLSchema')"
       >An element type that is not xs:anySimpleType MUST NOT have a namespace name <namespace-uri-for-prefix>xs</namespace-uri-for-prefix>.</sch:assert>
   </sch:rule>
-</sch:pattern>

The prohibition of element types having the XML Schema namespace subsumes a prohibition of the type xs:anyType.

Rule 9-40. Element type not in the XML namespace

The XML namespace may be imported into a conformant schema document as if it were conformant. This specification does not enable a reference to any types that may be defined by any implementation of a schema for that namespace.

[Rule 9-40] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The prohibition of element types having the XML Schema namespace subsumes a prohibition of the type xs:anyType.

Rule 9-41. Element type not in the XML namespace

The XML namespace may be imported into a conformant schema document as if it were conformant. This specification does not enable a reference to any types that may be defined by any implementation of a schema for that namespace.

[Rule 9-41] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@type)]">
     <sch:assert test="namespace-uri-from-QName(resolve-QName(@type, .)) != 'http://www.w3.org/XML/1998/namespace'"
       >An element type MUST NOT have a namespace name that is in the XML namespace.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-41. Element type is not simple type
[Rule 9-41] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-42. Element type is not simple type
[Rule 9-42] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[@type]">
     <sch:assert test="every $type-qname in resolve-QName(@type, .),
                             $type-ns in namespace-uri-from-QName($type-qname),
@@ -328,251 +291,249 @@
                             and not(ends-with($type-local-name, 'SimpleType'))))"
       >An element type that is not xs:anySimpleType MUST NOT be a simple type.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-42. No element disallowed substitutions
[Rule 9-42] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-43. No element disallowed substitutions
[Rule 9-43] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element">
     <sch:assert test="empty(@block)"
       >An element xs:element MUST NOT have an attribute {}block.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-43. No element disallowed derivation
[Rule 9-43] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-44. No element disallowed derivation
[Rule 9-44] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element">
     <sch:assert test="empty(@final)"
       >An element xs:element MUST NOT have an attribute {}final.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.2.1.1. No element value constraints
Rule 9-44. No element default value
[Rule 9-44] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.2.1.1. No element value constraints
Rule 9-45. No element default value
[Rule 9-45] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element">
     <sch:assert test="empty(@default)"
       >An element xs:element MUST NOT have an attribute {}default.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-45. No element fixed value
[Rule 9-45] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-46. No element fixed value
[Rule 9-46] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element">
     <sch:assert test="empty(@fixed)"
       >An element xs:element MUST NOT have an attribute {}fixed.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-46. Element declaration is nillable

All elements declared by reference schemas allow a nil value. This enables the ID/IDREF mechanism linking structures:ref and structures:id, as described by Section 12.2, Reference elements, below.

A developer may constrain the use of nil in an instance by setting nillable to false in subset schemas, or by use of non-XML Schema mechanisms, such as Schematron.

[Rule 9-46] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-47. Element declaration is nillable

All elements declared by reference schemas allow a nil value. This enables the ID/IDREF mechanism linking structures:ref and structures:id, as described by Section 12.2, Identifiers and references, below.

A developer may constrain the use of nil in an instance by setting nillable to false in subset schemas, or by use of non-XML Schema mechanisms, such as Schematron.

[Rule 9-47] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[@name and (empty(@abstract)
                                            or xs:boolean(@abstract) = false())]">
     <sch:assert test="exists(@nillable)
                       and xs:boolean(@nillable) = true()"
       >An element declaration MUST have the {nillable} property with a value of true.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term element declaration.

9.2.2. Element substitution group

This section is intentionally blank. It is present in order to ensure that section numbers correspond to [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, as described by Section 9, Rules for a NIEM profile of XML Schema, above.

9.2.3. Attribute declaration

Within an attribute declaration, the attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local attribute declarations.

Rule 9-47. Attribute declaration is top-level
[Rule 9-47] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term element declaration.

9.2.2. Element substitution group

This section is intentionally blank. It is present in order to ensure that section numbers correspond to [XML Schema Structures] Section 2.2, XML Schema Abstract Data Model, as described by Section 9, Rules for a NIEM profile of XML Schema, above.

9.2.3. Attribute declaration

Within an attribute declaration, the attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local attribute declarations.

Rule 9-48. Attribute declaration is top-level
[Rule 9-48] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@name)]">
     <sch:assert test="exists(parent::xs:schema)"
       >An attribute declaration MUST be top-level.</sch:assert>
   </sch:rule>
-</sch:pattern>

All schema components defined by NIEM-conformant schemas are named, accessible from outside the defining schema, and reusable across schemas. Local attribute declarations 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.

Rule 9-48. Attribute declaration has data definition
[Rule 9-48] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

All schema components defined by NIEM-conformant schemas are named, accessible from outside the defining schema, and reusable across schemas. Local attribute declarations 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.

Rule 9-49. Attribute declaration has data definition
[Rule 9-49] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@name)]">
     <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >An attribute declaration MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term data definition.

Rule 9-49. Attribute declaration has type
[Rule 9-49] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term data definition.

Rule 9-50. Attribute declaration has type
[Rule 9-50] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@name)]">
     <sch:assert test="exists(@type)"
       >A top-level attribute declaration MUST have a type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Untyped XML Schema attributes allow arbitrary content, with no semantics. Attributes must have a type so that specific syntax and semantics will be provided.

9.2.3.1. Prohibited attribute types

There is no explicit prohibition on the use of xs:NOTATION as an attribute type, because it is prohibited by [XML Schema Datatypes].

These types are only explicitly prohibited from attributes, not elements, because the case is covered by a general prohibition against elements having simple types.

Rule 9-50. No attribute type of xs:ID
[Rule 9-50] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Untyped XML Schema attributes allow arbitrary content, with no semantics. Attributes must have a type so that specific syntax and semantics will be provided.

9.2.3.1. Prohibited attribute types

There is no explicit prohibition on the use of xs:NOTATION as an attribute type, because it is prohibited by [XML Schema Datatypes].

These types are only explicitly prohibited from attributes, not elements, because the case is covered by a general prohibition against elements having simple types.

Rule 9-51. No attribute type of xs:ID
[Rule 9-51] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ID')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:ID.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-51. No attribute type of xs:IDREF
[Rule 9-51] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-52. No attribute type of xs:IDREF
[Rule 9-52] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:IDREF')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:IDREF.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-52. No attribute type of xs:IDREFS
[Rule 9-52] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-53. No attribute type of xs:IDREFS
[Rule 9-53] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:IDREFS')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:IDREFS.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-53. No attribute type of xs:ENTITY
[Rule 9-53] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-54. No attribute type of xs:ENTITY
[Rule 9-54] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ENTITY')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:ENTITY.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-54. No attribute type of xs:ENTITIES
[Rule 9-54] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-55. No attribute type of xs:ENTITIES
[Rule 9-55] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:ENTITIES')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:ENTITIES.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-55. No attribute type of xs:anySimpleType
[Rule 9-55] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-56. No attribute type of xs:anySimpleType
[Rule 9-56] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:assert test="resolve-QName(@type, .) != xs:QName('xs:anySimpleType')"
       >A schema component MUST NOT have an attribute {}type with a value of xs:anySimpleType.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.2.3.2. No attribute value constraints
Rule 9-56. No attribute default values
[Rule 9-56] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.2.3.2. No attribute value constraints
Rule 9-57. No attribute default values
[Rule 9-57] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute">
     <sch:assert test="empty(@default)"
       >An element xs:attribute MUST NOT have an attribute {}default.</sch:assert>
   </sch:rule>
-</sch:pattern>

This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above.

Rule 9-57. No attribute fixed values
[Rule 9-57] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure XML parsing does not construct values, above.

Rule 9-58. No attribute fixed values

The fixed attribute is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component:

default specifies that the attribute is to appear unconditionally in the post-schema-validation infoset, with the supplied value used whenever the attribute is not actually present; fixed indicates that the attribute value if present must equal the supplied constraint value, and if absent receives the supplied value as for default.

[Rule 9-58] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:attribute[exists(@ref) and @use eq 'required']">
+    <sch:report test="false()">This rule does not constrain attribute uses that are required</sch:report>
+  </sch:rule>
   <sch:rule context="xs:attribute">
     <sch:assert test="empty(@fixed)"
-      >An element xs:attribute MUST NOT have an attribute {}fixed.</sch:assert>
+      >An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed.</sch:assert>
   </sch:rule>
-</sch:pattern>

This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above. The use of the fixed attribute may result in alteration of the post-schema-validation infoset, like the use of default does. This behavior is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component.

9.2.4. Notation declaration
Rule 9-58. No use of element xs:notation
[Rule 9-58] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure XML parsing does not construct values, above. The use of the fixed attribute may result in alteration of the post-schema-validation infoset, like the use of default does. This behavior is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component.

9.2.4. Notation declaration
Rule 9-59. No use of element xs:notation
[Rule 9-59] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:notation">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:notation.</sch:assert>
   </sch:rule>
-</sch:pattern>

See Rule 9-7, No base type of xs:NOTATION (REF, EXT), above, for comments about the use of notations.

9.3. Model group components
9.3.1. Model group

Complex content definitions in XML Schema use model group schema components. These schema components, xs:all, xs:choice and xs:sequence, also called compositors, provide for ordering and selection of particles within a model group.

XML Schema defines a particle as an occurrence of xs:element, xs:sequence, xs:choice, xs:any (wildcard) and xs:group (model group) within a content model. For example, an xs:sequence within an XML Schema complex type is a particle. An xs:element occurring within an xs:sequence is also a particle.

Rule 9-59. Model group does not affect meaning
[Rule 9-59] (EXT) (Interpretation)

The use of model groups xs:all, xs:sequence, and xs:choice MUST NOT define the semantics of an instance. The meaning of an element occurrence within an element occurrence MUST be identical, regardless of the model group used to define a schema component.

Rule 9-60. No xs:all
[Rule 9-60] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

See Rule 9-7, No base type of xs:NOTATION (REF, EXT), above, for comments about the use of notations.

9.3. Model group components
9.3.1. Model group

Complex content definitions in XML Schema use model group schema components. These schema components, xs:all, xs:choice and xs:sequence, also called compositors, provide for ordering and selection of particles within a model group.

XML Schema defines a particle as an occurrence of xs:element, xs:sequence, xs:choice, xs:any (wildcard) and xs:group (model group) within a content model. For example, an xs:sequence within an XML Schema complex type is a particle. An xs:element occurring within an xs:sequence is also a particle.

Rule 9-60. Model group does not affect meaning
[Rule 9-60] (EXT) (Interpretation)

The use of model groups xs:all, xs:sequence, and xs:choice MUST NOT define the semantics of an instance. The meaning of an element occurrence within an element occurrence MUST be identical, regardless of the model group used to define a schema component.

Rule 9-61. No xs:all
[Rule 9-61] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:all">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:all</sch:assert>
   </sch:rule>
-</sch:pattern>

The element xs:all provides a set of particles (e.g., elements) that may be included in an instance, in no particular order. This compositor does not support a variety of cardinalities, has shown to be confusing in practice, and has functionality that overlaps with NIEM’s use of substitution groups. Use of substitution groups is the preferred method in NIEM schemas for obtaining flexible content models.

9.3.1.1. Sequence
Rule 9-61. xs:sequence must be child of xs:extension
[Rule 9-61] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>

The element xs:all provides a set of particles (e.g., elements) that may be included in an instance, in no particular order. This compositor does not support a variety of cardinalities, has shown to be confusing in practice, and has functionality that overlaps with NIEM’s use of substitution groups. Use of substitution groups is the preferred method in NIEM schemas for obtaining flexible content models.

9.3.1.1. Sequence
Rule 9-62. xs:sequence must be child of xs:extension
[Rule 9-62] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:sequence">
     <sch:assert test="exists(parent::xs:extension)"
       >An element xs:sequence MUST be a child of element xs:extension.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-62. xs:sequence must be child of xs:extension or xs:restriction
[Rule 9-62] (EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-63. xs:sequence must be child of xs:extension or xs:restriction
[Rule 9-63] (EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:sequence">
     <sch:assert test="exists(parent::xs:extension) or exists(parent::xs:restriction)"
       >An element xs:sequence MUST be a child of element xs:extension or xs:restriction.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.3.1.2. Choice
Rule 9-63. No xs:choice
[Rule 9-63] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
9.3.1.2. Choice
Rule 9-64. No xs:choice
[Rule 9-64] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:choice">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:choice</sch:assert>
   </sch:rule>
-</sch:pattern>

The element xs: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 xs:choice may be used in extension schemas, as it presents a simple way for a schema writer to represent a set of optional content.

Rule 9-64. xs:choice must be child of xs:sequence
[Rule 9-64] (EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The element xs: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 xs:choice may be used in extension schemas, as it presents a simple way for a schema writer to represent a set of optional content.

Rule 9-65. xs:choice must be child of xs:sequence
[Rule 9-65] (EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:choice">
     <sch:assert test="exists(parent::xs:sequence)"
       >An element xs:choice MUST be a child of element xs:sequence.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.3.2. Particle

In NIEM schemas, an element use is an element declaration acting as a particle within a content model. Each such element declaration must reference a top-level named element declaration.

Element declarations acting as a particle (particles formed by xs:element) may have any cardinality. NIEM does not provide additional constraints on the values of the XML Schema properties {min occurs} and {max occurs} on element uses. These properties are described by [XML Schema Structures] Section 3.9.1, The Particle Schema Component.

9.3.2.1. Sequence cardinality

XML Schema allows each particle to specify cardinality (how many times the particle may appear in an instance). NIEM restricts the cardinality of xs:sequence particles to exactly one, to ensure that content model definitions are defined in as straightforward a manner as possible.

A schema developer who requires the instance syntax that would be obtained from the use of specific cardinality on sequences should define cardinality on individual element uses.

Rule 9-65. Sequence has minimum cardinality 1
[Rule 9-65] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.3.2. Particle

In NIEM schemas, an element use is an element declaration acting as a particle within a content model. Each such element declaration must reference a top-level named element declaration.

Element declarations acting as a particle (particles formed by xs:element) may have any cardinality. NIEM does not provide additional constraints on the values of the XML Schema properties {min occurs} and {max occurs} on element uses. These properties are described by [XML Schema Structures] Section 3.9.1, The Particle Schema Component.

9.3.2.1. Sequence cardinality

XML Schema allows each particle to specify cardinality (how many times the particle may appear in an instance). NIEM restricts the cardinality of xs:sequence particles to exactly one, to ensure that content model definitions are defined in as straightforward a manner as possible.

A schema developer who requires the instance syntax that would be obtained from the use of specific cardinality on sequences should define cardinality on individual element uses.

Rule 9-66. Sequence has minimum cardinality 1
[Rule 9-66] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:sequence">
     <sch:assert test="empty(@minOccurs) or xs:integer(@minOccurs) = 1"
       >An element xs:sequence MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-66. Sequence has maximum cardinality 1
[Rule 9-66] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-67. Sequence has maximum cardinality 1
[Rule 9-67] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:sequence">
     <sch:assert test="empty(@maxOccurs) or (@maxOccurs instance of xs:integer
                                             and 1 = xs:integer(@maxOccurs))"
       >An element xs:sequence MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.3.2.2. Choice cardinality
Rule 9-67. Choice has minimum cardinality 1
[Rule 9-67] (EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.3.2.2. Choice cardinality
Rule 9-68. Choice has minimum cardinality 1
[Rule 9-68] (EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:choice">
     <sch:assert test="empty(@minOccurs) or 1 = xs:integer(@minOccurs)"
       >An element xs:choice MUST either not have the attribute {}minOccurs, or that attribute MUST have a value of 1.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-68. Choice has maximum cardinality 1
[Rule 9-68] (EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-69. Choice has maximum cardinality 1
[Rule 9-69] (EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:choice">
     <sch:assert test="empty(@maxOccurs) or (@maxOccurs instance of xs:integer
                                             and 1 = xs:integer(@maxOccurs))"
       >An element xs:choice MUST either not have the attribute {}maxOccurs, or that attribute MUST have a value of 1.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.3.3. Attribute use

An attribute use has an {attribute declaration} property that is a top-level, named attribute declaration. NIEM-conformant schemas do not define local named attributes within type definitions. Within an attribute use, the attribute use may be used as per the XML Schema specification.

9.3.4. Wildcard
Rule 9-69. No use of xs:any
[Rule 9-69] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
9.3.3. Attribute use

An attribute use has an {attribute declaration} property that is a top-level, named attribute declaration. NIEM-conformant schemas do not define local named attributes within type definitions. Within an attribute use, the attribute use may be used as per the XML Schema specification.

9.3.4. Wildcard
Rule 9-70. No use of xs:any
[Rule 9-70] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:any">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:any.</sch:assert>
   </sch:rule>
-</sch:pattern>

The xs:any particle (see Model Group Restrictions for an informative definition of particle) provides a wildcard that may carry arbitrary content. The particle xs:any may appear within an extension schema document.

Rule 9-70. No use of xs:anyAttribute
[Rule 9-70] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>

The xs:any particle (see Model Group Restrictions for an informative definition of particle) provides a wildcard that may carry arbitrary content. The particle xs:any may appear within an extension schema document.

Rule 9-71. No use of xs:anyAttribute
[Rule 9-71] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:anyAttribute">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:anyAttribute.</sch:assert>
   </sch:rule>
-</sch:pattern>

The xs:anyAttribute element provides a wildcard, where arbitrary attributes may appear.

9.4. Identity-constraint definition components

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 consistent through schema reuse.

Note that there is no prohibition on the use of xs:selector and xs:field, since according to the rules of the XML Schema definition language, they can only appear within xs:key, xs:keyref, and xs:unique, which are themselves prohibited.

Rule 9-71. No use of xs:unique
[Rule 9-71] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The xs:anyAttribute element provides a wildcard, where arbitrary attributes may appear.

9.4. Identity-constraint definition components

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 consistent through schema reuse.

Note that there is no prohibition on the use of xs:selector and xs:field, since according to the rules of the XML Schema definition language, they can only appear within xs:key, xs:keyref, and xs:unique, which are themselves prohibited.

Rule 9-72. No use of xs:unique
[Rule 9-72] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:unique">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:unique.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-72. No use of xs:key
[Rule 9-72] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-73. No use of xs:key
[Rule 9-73] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:key">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:key.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-73. No use of xs:keyref
[Rule 9-73] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-74. No use of xs:keyref
[Rule 9-74] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:keyref">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:keyref.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.5. Group definition components
9.5.1. Model group definition
Rule 9-74. No use of xs:group
[Rule 9-74] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.5. Group definition components
9.5.1. Model group definition
Rule 9-75. No use of xs:group
[Rule 9-75] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:group">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:group.</sch:assert>
   </sch:rule>
-</sch:pattern>

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 multiple types, and which consists of a sequence of or choice between element particles. NIEM has not developed a semantic model for these components, and they are not integrated into NIEM’s design.

9.5.2. Attribute group definition
Rule 9-75. No definition of attribute groups

Per Rule 11-24, Schema uses only known attribute groups (REF, EXT), below, the only attribute groups used in NIEM-conformant schemas are structures:SimpleObjectAttributeGroup and attribute groups defined by the IC-ISM and IC-NTK schemas. Therefore, NIEM-conformant schemas do not define additional attribute groups.

[Rule 9-75] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

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 multiple types, and which consists of a sequence of or choice between element particles. NIEM has not developed a semantic model for these components, and they are not integrated into NIEM’s design.

9.5.2. Attribute group definition
Rule 9-76. No definition of attribute groups

Per Rule 11-22, Schema uses only known attribute groups (REF, EXT), below, the only attribute groups used in NIEM-conformant schemas are structures:SimpleObjectAttributeGroup and attribute groups defined by the IC-ISM and IC-NTK schemas. Therefore, NIEM-conformant schemas do not define additional attribute groups.

[Rule 9-76] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attributeGroup[@name]">
     <sch:assert test="false()"
       >The schema MUST NOT contain an attribute group definition schema component.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.6. Annotation components
Rule 9-76. Comment is not recommended

Note that this rule is written with a context that is not as precise as it could be. Its context is the parent node of the comment node, in order to avoid error messages when executed with common Schematron implementations.

[Rule 9-76] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.6. Annotation components
Rule 9-77. Comment is not recommended

Note that this rule is written with a context that is not as precise as it could be. Its context is the parent node of the comment node, in order to avoid error messages when executed with common Schematron implementations.

[Rule 9-77] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="node()[comment()]">
     <sch:report test="true()"
       >An XML Comment is not an XML Schema annotation component; an XML comment SHOULD NOT appear in the schema.</sch:report>
   </sch:rule>
-</sch:pattern>

Since XML comments are not associated with any specific XML Schema construct, there is no standard way to interpret comments. XML Schema annotations should be preferred for meaningful information about components. NIEM specifically defines how information should be encapsulated in NIEM-conformant schemas via xs:annotation elements.

Rule 9-77. Documentation element has no element children
[Rule 9-77] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Since XML comments are not associated with any specific XML Schema construct, there is no standard way to interpret comments. XML Schema annotations should be preferred for meaningful information about components. NIEM specifically defines how information should be encapsulated in NIEM-conformant schemas via xs:annotation elements.

Rule 9-78. Documentation element has no element children
[Rule 9-78] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:documentation/node()">
     <sch:assert test="self::text() or self::comment()"
       >A child of element xs:documentation MUST be text or an XML comment.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.6.1. Application information annotation

XML Schema provides special annotations for support of automatic processing. The XML Schema specification provides the element xs:appinfo to carry such content and does not specify what style of content they should carry. In NIEM, xs:appinfo elements carry structured XML content.

Rule 9-78. xs:appinfo children are comments, elements, or whitespace
[Rule 9-78] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.6.1. Application information annotation

XML Schema provides special annotations for support of automatic processing. The XML Schema specification provides the element xs:appinfo to carry such content and does not specify what style of content they should carry. In NIEM, xs:appinfo elements carry structured XML content.

Rule 9-79. xs:appinfo children are comments, elements, or whitespace
[Rule 9-79] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:appinfo/node()">
     <sch:assert test="self::comment()
                       or self::element()
                       or self::text()[string-length(normalize-space(.)) = 0]"
       >A child of element xs:appinfo MUST be an element, a comment, or whitespace text.</sch:assert>
   </sch:rule>
-</sch:pattern>

Application information elements are intended for automatic processing; the meaning of an appinfo annotation is provided via elements.

Rule 9-79. Appinfo child elements have namespaces
[Rule 9-79] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Application information elements are intended for automatic processing; the meaning of an appinfo annotation is provided via elements.

Rule 9-80. Appinfo child elements have namespaces
[Rule 9-80] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:appinfo/*">
     <sch:assert test="namespace-uri() != xs:anyURI('')"
       >An element that is a child of xs:appinfo MUST have a namespace name.</sch:assert>
   </sch:rule>
-</sch:pattern>

The XML namespaces specification includes the concept of content not in a namespace. Use of elements without namespaces can lead to conflicting data definitions, and makes it difficult to identify relevant data definitions.

Rule 9-80. Appinfo descendants are not XML Schema elements
[Rule 9-80] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The XML namespaces specification includes the concept of content not in a namespace. Use of elements without namespaces can lead to conflicting data definitions, and makes it difficult to identify relevant data definitions.

Rule 9-81. Appinfo descendants are not XML Schema elements
[Rule 9-81] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:appinfo//xs:*">
     <sch:assert test="false()"
       >An element with a namespace name of xs: MUST NOT have an ancestor element xs:appinfo.</sch:assert>
   </sch:rule>
-</sch:pattern>

NIEM-conformant schemas are designed to be very easily processed. Although uses of XML Schema elements as content of xs:appinfo elements could be contrived, it is not current practice and complicates the processing of XML elements by their namespaces and names. Forbidding the use of XML Schema elements outside valid uses of schema simplifies such processing.

9.7. Schema as a whole

The XML Schema language defines that the document element xs:schema may contain the optional attributes attributeFormDefault and elementFormDefault. The values of these attributes are not material to a conformant schema, as each attribute and element defined by a conformant schema is defined as a top-level component, and so each is qualified by its target namespace.

Rule 9-81. Schema has data definition
[Rule 9-81] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

NIEM-conformant schemas are designed to be very easily processed. Although uses of XML Schema elements as content of xs:appinfo elements could be contrived, it is not current practice and complicates the processing of XML elements by their namespaces and names. Forbidding the use of XML Schema elements outside valid uses of schema simplifies such processing.

9.7. Schema as a whole

The XML Schema language defines that the document element xs:schema may contain the optional attributes attributeFormDefault and elementFormDefault. The values of these attributes are not material to a conformant schema, as each attribute and element defined by a conformant schema is defined as a top-level component, and so each is qualified by its target namespace.

Rule 9-82. Schema has data definition
[Rule 9-82] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema">
     <sch:assert test="some $definition in (xs:annotation/xs:documentation)[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >An element xs:schema MUST have a data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-82. Schema document defines target namespace
[Rule 9-82] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-83. Schema document defines target namespace
[Rule 9-83] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema">
     <sch:assert test="exists(@targetNamespace)"
       >The schema MUST define a target namespace.</sch:assert>
   </sch:rule>
-</sch:pattern>

Schemas without defined namespaces provide definitions that are ambiguous, in that they are not universally identifiable.

Rule 9-83. Target namespace is absolute URI
[Rule 9-83] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:schema[exists(@targetNamespace)]">
-    <sch:report test="true()"
-                ><![CDATA[The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986.]]></sch:report>
-  </sch:rule>
-</sch:pattern>

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. <absolute-URI> is a grammar production defined by [RFC 3986] Section 4.3, Absolute URI.

Rule 9-84. Schema has version

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.

An author of an application schema or exchange may use the version attribute for these purposes within their schemas.

[Rule 9-84] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Schemas without defined namespaces provide definitions that are ambiguous, in that they are not universally identifiable.

Rule 9-84. Target namespace is absolute URI
[Rule 9-84] (REF, EXT) (Constraint)

The value of the attribute targetNamespace MUST match the production <absolute-URI> as defined by RFC 3986.

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. <absolute-URI> is a grammar production defined by [RFC 3986] Section 4.3, Absolute URI.

Rule 9-85. Schema has version

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.

An author of an application schema or exchange may use the version attribute for these purposes within their schemas.

[Rule 9-85] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema">
     <sch:assert test="some $version in @version satisfies
                       string-length(normalize-space(@version)) &gt; 0"
         >An element xs:schema MUST have an attribute {}version that MUST NOT be empty.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-85. No disallowed substitutions
[Rule 9-85] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-86. No disallowed substitutions
[Rule 9-86] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema">
     <sch:assert test="empty(@blockDefault)"
       >An element xs:schema MUST NOT have an attribute {}blockDefault.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-86. No disallowed derivations
[Rule 9-86] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-87. No disallowed derivations
[Rule 9-87] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema">
     <sch:assert test="empty(@finalDefault)"
       >An element xs:schema MUST NOT have an attribute {}finalDefault.</sch:assert>
   </sch:rule>
-</sch:pattern>
9.8. Schema assembly
Rule 9-87. No use of xs:redefine
[Rule 9-87] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
9.8. Schema assembly
Rule 9-88. No use of xs:redefine
[Rule 9-88] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:redefine">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:redefine.</sch:assert>
   </sch:rule>
-</sch:pattern>

The xs:redefine element allows an XML Schema document to restrict and extend components from a namespace, in a separate schema document from the one that initially defined that namespace. Such redefinition introduces duplication of definitions, allowing multiple definitions to exist for components from a single namespace. This violates [Principle 9], above, that a single reference schema defines a NIEM-conformant namespace.

Rule 9-88. No use of xs:include
[Rule 9-88] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The xs:redefine element allows an XML Schema document to restrict and extend components from a namespace, in a separate schema document from the one that initially defined that namespace. Such redefinition introduces duplication of definitions, allowing multiple definitions to exist for components from a single namespace. This violates [Principle 9], above, that a single reference schema defines a NIEM-conformant namespace.

Rule 9-89. No use of xs:include
[Rule 9-89] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:include">
     <sch:assert test="false()"
       >The schema MUST NOT contain the element xs:include.</sch:assert>
   </sch:rule>
-</sch:pattern>

Element xs: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 9], above, as it uses multiple schemas to construct a namespace.

Rule 9-89. xs:import must have namespace
[Rule 9-89] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Element xs: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 9], above, as it uses multiple schemas to construct a namespace.

Rule 9-90. xs:import must have namespace
[Rule 9-90] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import">
     <sch:assert test="exists(@namespace)"
       >An element xs:import MUST have an attribute {}namespace.</sch:assert>
   </sch:rule>
-</sch:pattern>

An import that does not specify a namespace is enabling references 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.

Rule 9-90. XML Schema document set must be complete

An XML Schema document set defines an XML Schema that may be used to validate an XML document. This rule ensures that a schema document set under consideration contains definitions for everything that it references; it has everything necessary to do a complete validation of XML documents, without any unresolved references. Note that some tools may allow validation of documents using partial schemas, when components that are not present are not exercised by the XML document under validation. Such a schema does not meet qualify as a conformant schema document set.

[Rule 9-90] (SET) (Constraint)

The schema document set must constitute a complete XML Schema; it must contain the definition of every schema component referenced by any component defined by the schema set.

9.8.1. Namespaces for referenced components are imported

The XML Schema definition language requires that, when a schema document references a component in some other namespace, it must use xs:import to import the namespace of the referenced component. The use of xs:import is described by [XML Schema Structures] Section 4.2.3, References to schema components across namespaces.

Some tools do not enforce this constraint; one such tool carries imports from a schema document into schema documents that it imports. This has the potential to introduce incompatibility into schema documents and schema document sets that exercise this bug. To maintain compatibility across tool sets, this requirement is an explicit rule for NIEM-conformant schemas.

Rule 9-91. Namespace referenced by attribute type is imported
[Rule 9-91] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

An import that does not specify a namespace is enabling references to components without namespaces. NIEM requires that all components have a defined namespace. It is important that the namespace declared by a schema be universally defined and unambiguous.

Rule 9-91. XML Schema document set must be complete

An XML Schema document set defines an XML Schema that may be used to validate an XML document. This rule ensures that a schema document set under consideration contains definitions for everything that it references; it has everything necessary to do a complete validation of XML documents, without any unresolved references. Note that some tools may allow validation of documents using partial schemas, when components that are not present are not exercised by the XML document under validation. Such a schema does not meet qualify as a conformant schema document set.

[Rule 9-91] (SET) (Constraint)

The schema document set must constitute a complete XML Schema; it must contain the definition of every schema component referenced by any component defined by the schema set.

9.8.1. Namespaces for referenced components are imported

The XML Schema definition language requires that, when a schema document references a component in some other namespace, it must use xs:import to import the namespace of the referenced component. The use of xs:import is described by [XML Schema Structures] Section 4.2.3, References to schema components across namespaces.

Some tools do not enforce this constraint; one such tool carries imports from a schema document into schema documents that it imports. This has the potential to introduce incompatibility into schema documents and schema document sets that exercise this bug. To maintain compatibility across tool sets, this requirement is an explicit rule for NIEM-conformant schemas.

Rule 9-92. Namespace referenced by attribute type is imported
[Rule 9-92] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@type]">
     <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@type, .)) satisfies (
                         $namespace = nf:get-target-namespace(.)
@@ -580,7 +541,7 @@
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
                 >The namespace of a type referenced by @type MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-92. Namespace referenced by attribute base is imported
[Rule 9-92] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-93. Namespace referenced by attribute base is imported
[Rule 9-93] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@base]">
     <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@base, .)) satisfies (
                         $namespace = nf:get-target-namespace(.)
@@ -588,7 +549,7 @@
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
                 >The namespace of a type referenced by @base MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-93. Namespace referenced by attribute itemType is imported
[Rule 9-93] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-94. Namespace referenced by attribute itemType is imported
[Rule 9-94] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@itemType]">
     <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@itemType, .)) satisfies (
                         $namespace = nf:get-target-namespace(.)
@@ -596,7 +557,7 @@
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
                 >The namespace of a type referenced by @itemType MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-94. Namespaces referenced by attribute memberTypes is imported
[Rule 9-94] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-95. Namespaces referenced by attribute memberTypes is imported
[Rule 9-95] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@memberTypes]">
     <sch:assert test="every $type in tokenize(normalize-space(@memberTypes), ' '),
                             $namespace in namespace-uri-from-QName(resolve-QName($type, .)) satisfies (
@@ -605,21 +566,21 @@
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace])"
                 >The namespace of a type referenced by @memberTypes MUST be the target namespace, the XML Schema namespace, or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-95. Namespace referenced by attribute ref is imported
[Rule 9-95] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-96. Namespace referenced by attribute ref is imported
[Rule 9-96] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@ref]">
     <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies
                         $namespace = nf:get-target-namespace(.)
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace]"
                 >The namespace of a component referenced by @ref MUST be the target namespace or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 9-96. Namespace referenced by attribute substitutionGroup is imported
[Rule 9-96] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 9-97. Namespace referenced by attribute substitutionGroup is imported
[Rule 9-97] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[@substitutionGroup]">
     <sch:assert test="every $namespace in namespace-uri-from-QName(resolve-QName(@substitutionGroup, .)) satisfies
                         $namespace = nf:get-target-namespace(.)
                         or nf:get-document-element(.)/xs:import[xs:anyURI(@namespace) = $namespace]"
                 >The namespace of a component referenced by @substitutionGroup MUST be the target namespace or be imported.</sch:assert>
   </sch:rule>
-</sch:pattern>
10. Rules for NIEM modeling, by NIEM concept

This section focuses on building NIEM data models using the XML Schema definition language. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.

NIEM provides a framework for modeling concepts and relationships as XML artifacts. The data model is implemented via XML Schema. However, XML Schema does not provide sufficient structure and constraint to enable translating from a conceptual model to a schema and then to instances of the concepts. NIEM provides additional support for modeling concepts as schemas and provides rules for creating and connecting data that realizes those concepts.

Underlying the NIEM data model are two namespaces: the structures namespace and the appinfo namespace. These two namespaces provide schema components that serve two functions:

  1. They provide support for connecting structural definitions to concepts.
  2. They provide base components from which to derive structural definitions.

These namespaces are distributed with the NIEM data model content but are not themselves considered to be content of the data model. They are, instead, part of the structure on which the data model is built.

This section is organized by concept, rather than component type. This section is integrated with the following sections:

Concepts covered by this section include:

10.1. Categories of NIEM type definitions

The rules in this document use the name of a type as the key indicator of the type’s category. This makes the rules much simpler than doing a deep examination of each type (and its base types) to identify its category. For example, for complex types, the names follow a pattern:

  • Name ends with AssociationType → type is an association type.
  • Name ends with MetadataType → type is a metadata type.
  • Name ends with AugmentationType → type is an augmentation type.
  • Otherwise → type is an object type.
Rule 10-1. Complex type has a category
[Rule 10-1] (REF, EXT) (Constraint)

Within the schema, a complex type definition MUST be one of the following:

  1. An object type.
  2. An association type.
  3. A metadata type.
  4. An augmentation type.

This rule establishes the categories of NIEM complex types. It is a limited set, and each category has distinct semantics, as described by following sections.

10.2. Object

The categories of objects are covered by the following sections:

10.2.1. General object types
[Definition: object type]

In a NIEM-conformant schema, an object type is a complex type definition, an instance of which asserts the existence of an object. An object type represents some kind of object: a thing with its own lifespan that has some existence. The object may or may not be a physical object. It may be a conceptual object.

10.2.1.1. Object types with complex content
Rule 10-2. Object type with complex content is derived from object type
[Rule 10-2] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10. Rules for NIEM modeling, by NIEM concept

This section focuses on building NIEM data models using the XML Schema definition language. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.

NIEM provides a framework for modeling concepts and relationships as XML artifacts. The data model is implemented via XML Schema. However, XML Schema does not provide sufficient structure and constraint to enable translating from a conceptual model to a schema and then to instances of the concepts. NIEM provides additional support for modeling concepts as schemas and provides rules for creating and connecting data that realizes those concepts.

Underlying the NIEM data model are two namespaces: the structures namespace and the appinfo namespace. These two namespaces provide schema components that serve two functions:

  1. They provide support for connecting structural definitions to concepts.
  2. They provide base components from which to derive structural definitions.

These namespaces are distributed with the NIEM data model content but are not themselves considered to be content of the data model. They are, instead, part of the structure on which the data model is built.

This section is organized by concept, rather than component type. This section is integrated with the following sections:

Concepts covered by this section include:

10.1. Categories of NIEM type definitions

The rules in this document use the name of a type as the key indicator of the type’s category. This makes the rules much simpler than doing a deep examination of each type (and its base types) to identify its category. For example, for complex types, the names follow a pattern:

  • Name ends with AssociationType → type is an association type.
  • Name ends with MetadataType → type is a metadata type.
  • Name ends with AugmentationType → type is an augmentation type.
  • Otherwise → type is an object type.
Rule 10-1. Complex type has a category
[Rule 10-1] (REF, EXT) (Constraint)

Within the schema, a complex type definition MUST be one of the following:

  1. An object type.
  2. An association type.
  3. A metadata type.
  4. An augmentation type.

This rule establishes the categories of NIEM complex types. It is a limited set, and each category has distinct semantics, as described by following sections.

10.2. Object

The categories of objects are covered by the following sections:

10.2.1. General object types
[Definition: object type]

In a NIEM-conformant schema, an object type is a complex type definition, an instance of which asserts the existence of an object. An object type represents some kind of object: a thing with its own lifespan that has some existence. The object may or may not be a physical object. It may be a conceptual object.

10.2.1.1. Object types with complex content
Rule 10-2. Object type with complex content is derived from object type
[Rule 10-2] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[exists(xs:complexContent)
                                     and not(ends-with(@name, 'AssociationType')
                                         or ends-with(@name, 'MetadataType')
@@ -635,15 +596,15 @@
                  or ends-with($base-local-name, 'AugmentationType')))"
       >An object type with complex content MUST be derived from structures:ObjectType or from another object type.</sch:assert>
   </sch:rule>
-</sch:pattern>

A base type definition with a {target namespace} that is the XML namespace is prohibited by Rule 9-1, No base type in the XML namespace (REF, EXT), above. A base type definition with a {target namespace} that is not imported as conformant is prohibited by Rule 11-3, Base type definition defined by conformant schema (REF, EXT), below.

10.2.2. Role types and roles

NIEM differentiates between an object and a role of the object. The term role is used here to mean a function or part played by some object. The simplest way to represent a role of an object is to use an element. The following element declaration models the role of a person who undergoes an assessment:

Figure 10-1: An element declaration that constitutes a role without the use of a role type
<xs:element name="AssessmentPerson" type="nc:PersonType" nillable="true">
+</sch:pattern>

A base type definition with a {target namespace} that is the XML namespace is prohibited by Rule 9-1, No base type in the XML namespace (REF, EXT), above. A base type definition with a {target namespace} that is not imported as conformant is prohibited by Rule 11-2, Base type definition defined by conformant schema (REF, EXT), below.

10.2.2. Role types and roles

NIEM differentiates between an object and a role of the object. The term role is used here to mean a function or part played by some object. The simplest way to represent a role of an object is to use an element. The following element declaration models the role of a person who undergoes an assessment:

Figure 10-1: An element declaration that constitutes a role without the use of a role type
<xs:element name="AssessmentPerson" type="nc:PersonType" nillable="true">
   <xs:annotation>
     <xs:documentation>A person who undergoes an assessment.</xs:documentation>
   </xs:annotation>
-</xs:element>

In many cases, there is a further need to represent characteristics and additional information associated with a role of an object. In such cases, the above element is insufficient. When a role must be modeled with additional information, a role type is called for.

For example, when a person is a driver involved in an automotive crash, that person has a particular role in the crash, which is modeled by the element j:CrashDriver.

Figure 10-2: Element j:CrashDriver, modeling the role of a driver in a crash
<xs:element name="CrashDriver" type="j:CrashDriverType" nillable="true">
+</xs:element>

In many cases, there is a further need to represent characteristics and additional information associated with a role of an object. In such cases, the above element is insufficient. When a role must be modeled with additional information, a role type is called for.

For example, when a person is a driver involved in an automotive crash, that person has a particular role in the crash, which is modeled by the element j:CrashDriver.

Figure 10-2: Element j:CrashDriver, modeling the role of a driver in a crash
<xs:element name="CrashDriver" type="j:CrashDriverType" nillable="true">
   <xs:annotation>
     <xs:documentation>A motor vehicle driver involved into a traffic accident.</xs:documentation>
   </xs:annotation>
-</xs:element>

There is more information associated with this role of the driver than just his identity as a person. Information associated with this role include the drivers license, contributing circumstances, distractions, and other properties. These characteristics are modeled as shown in the following figure. The role is modeled as a role type:

Figure 10-3: Role type j:CrashDriverType, modeling a driver involved in a crash
<xs:complexType name="CrashDriverType">
+</xs:element>

There is more information associated with this role of the driver than just his identity as a person. Information associated with this role include the drivers license, contributing circumstances, distractions, and other properties. These characteristics are modeled as shown in the following figure. The role is modeled as a role type:

Figure 10-3: Role type j:CrashDriverType, modeling a driver involved in a crash
<xs:complexType name="CrashDriverType">
   <xs:annotation>
     <xs:documentation>A data type for a motor vehicle driver involved in a traffic accident.</xs:documentation>
   </xs:annotation>
@@ -660,7 +621,7 @@
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
-</xs:complexType>

The term role type has a normative definition:

[Definition: role type]

A role type is an object type that represents a particular function, purpose, usage, or role of one or more objects of its base type.

A role type describes a role of a thing. A role is a function or position played by something in a particular situation or context. A role type holds information that is specific to the role, but that is not specific to the context, and is not specific to thing that plays the role.

In the example (Figure 10-5, An XML instance of a role type, below), a person (John Doe) has the role of being a driver in a crash. Associated with this role are descriptions of a law violation related to him and a law violation related to his driving behavior. These are properties of his role as a driver in a crash.

This data is described by a role type, j:CrashDriverType (described by Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above), which carries elements and attributes that are properties of the role. The role type also carries a RoleOf element, which indicates the base type for the role. The role type describes a role of the base type, which in this case is nc:PersonType, as identified by the type of nc:RoleOfPerson defined by Figure 10-4, Declaration of RoleOf element nc:RoleOfPerson, below.

Developers of NIEM-conformant schemas and exchanges should create and use role types whenever they have information specific to a base object’s function. Such information is a characteristic of the role, and not of the base object. Information that is a characteristic of a base object probably does not belong in a role type.

[Definition: RoleOf element]

A RoleOf element is an element declaration that

A RoleOf element represents a base type for a role type.

We saw the use of RoleOf element nc:RoleOfPerson in Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above. Its definition is the following figure:

Figure 10-4: Declaration of RoleOf element nc:RoleOfPerson
<xs:element name="RoleOfPerson" type="nc:PersonType" substitutionGroup="nc:RoleOf" nillable="true">
+</xs:complexType>

The term role type has a normative definition:

[Definition: role type]

A role type is an object type that represents a particular function, purpose, usage, or role of one or more objects of its base type.

A role type describes a role of a thing. A role is a function or position played by something in a particular situation or context. A role type holds information that is specific to the role, but that is not specific to the context, and is not specific to thing that plays the role.

In the example (Figure 10-5, An XML instance of a role type, below), a person (John Doe) has the role of being a driver in a crash. Associated with this role are descriptions of a law violation related to him and a law violation related to his driving behavior. These are properties of his role as a driver in a crash.

This data is described by a role type, j:CrashDriverType (described by Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above), which carries elements and attributes that are properties of the role. The role type also carries a RoleOf element, which indicates the base type for the role. The role type describes a role of the base type, which in this case is nc:PersonType, as identified by the type of nc:RoleOfPerson defined by Figure 10-4, Declaration of RoleOf element nc:RoleOfPerson, below.

Developers of NIEM-conformant schemas and exchanges should create and use role types whenever they have information specific to a base object’s function. Such information is a characteristic of the role, and not of the base object. Information that is a characteristic of a base object probably does not belong in a role type.

[Definition: RoleOf element]

A RoleOf element is an element declaration that

A RoleOf element represents a base type for a role type.

We saw the use of RoleOf element nc:RoleOfPerson in Figure 10-3, Role type j:CrashDriverType, modeling a driver involved in a crash, above. Its definition is the following figure:

Figure 10-4: Declaration of RoleOf element nc:RoleOfPerson
<xs:element name="RoleOfPerson" type="nc:PersonType" substitutionGroup="nc:RoleOf" nillable="true">
   <xs:annotation>
     <xs:documentation>A person of whom the role object is a function.</xs:documentation>
   </xs:annotation>
@@ -685,7 +646,7 @@
                             or ends-with($type-local-name, 'AugmentationType'))"
       >The type definition of a RoleOf element MUST be an object type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Note that by Rule 11-14, Element type is from conformant namespace (REF, EXT), below, the element’s type must be from a conformant namespace.

Rule 10-4. Only object type has RoleOf element
[Rule 10-4] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Note that by Rule 11-12, Element type is from conformant namespace (REF, EXT), below, the element’s type must be from a conformant namespace.

Rule 10-4. Only object type has RoleOf element
[Rule 10-4] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[
       empty(@appinfo:externalAdapterTypeIndicator)
       and exists(descendant::xs:element[
@@ -696,13 +657,13 @@
                           or ends-with(@name, 'AugmentationType'))"
       >A complex type that includes a RoleOf element in its content model MUST be an object type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Note that RoleOf element and object type are defined terms.

Rule 10-5. RoleOf elements indicate the base types of a role type
[Rule 10-5] (REF, EXT, INS) (Interpretation)

An element declaration that has a local name that begins with the string RoleOf MUST represent a base type, of which the containing element instance represents a role.

Rule 10-6. Instance of RoleOf element indicates a role object
[Rule 10-6] (INS) (Interpretation)

When a parent element has a child element valid to an element declaration that is a RoleOf element,

  • The value of the parent element is a role object.
  • The value of the child element is a base object of the role object.

An instance of a RoleOf element indicates the base object of a role. The prefix RoleOf on the element ensures that a role object may be distinguished from other objects and that its link to the base object is also distinguishable from the additional properties that are characteristics or other data of the role.

NIEM does not require that there be only one RoleOf element within a single type, nor does it require that a particular role object have only a single occurrence of a RoleOf element. However, the use of multiple RoleOf elements may not make sense in all cases. An exchange specification may restrict RoleOf elements to a single occurrence within a type.

This specification does not require that a RoleOf element occur in an instance of a role type. In such a case, the instance of the role type behaves like any other type; it simply does not have a reference to its base object. For example, we may talk about a weapon’s use in an incident without referring to the car that acted as the weapon.

10.2.3. External adapter types and external components

There are a variety of commonly used standards that are represented in XML Schema. Such schemas are generally not NIEM-conformant. NIEM-conformant schemas may reference components defined by these external schema documents. This section provides rules under which NIEM-conformant components may be constructed from schema components that are not NIEM-conformant.

[Definition: external schema document]

An external schema document is any schema document that is not one of

Note that, although the schema document for the structures namespace is not conformant, it is not considered an external schema document because it defines the fundamental framework on which NIEM is built; it is considered a supporting namespace. It is not considered an external schema document because of its supporting nature and is thus a special case of this definition.

A schema component defined by an external schema document may be called an external component. A NIEM-conformant type may use external components in its definition. There are two ways to integrate external components into a NIEM-conformant schema:

  1. An external adapter type may be constructed from externally-defined elements and attributes. A goal of this method is to represent, as a single unit, a set of data that embodies a single concept from an external standard. This is an external adapter type.
  2. A type that is not an external adapter type may incorporate externally-defined attributes.
Figure 10-6: Use of external components to create a NIEM-conformant type

For example, a NIEM-conformant type may be created to represent a bibliographic reference from an external standard. Such an object may be composed of multiple elements (of multiple types) from the external standard. These pieces are put together to form a single NIEM-conformant external adapter type. For example, an author element, a book element, and a publisher element may be used to define a single bibliographic entry type.

A NIEM-conformant type built from these components may be used as any other NIEM-conformant type. That is, elements may be constructed from such a type, and those elements are fully NIEM-conformant.

To construct such a component, a NIEM-conformant schema must import the namespace defined by the external schema document.

Rule 11-36, Reference schema imports reference schema (SET), below, and Rule 11-37, Extension schema document imports reference or extension schema (SET), below, require that xs:import elements be consistent with an importing schema document.

A NIEM-conformant schema has well-known documentation points. Therefore, a schema that imports a NIEM-conformant namespace need not provide additional documentation. However, when an external schema document is imported, appropriate documentation must be provided at the point of import because documentation associated with external schema documents is undefined and variable. In this particular case, documentation of external schema documents is required at their point of use in NIEM.

10.2.3.1. Import of external namespace
Rule 10-7. Import of external namespace has data definition
[Rule 10-7] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Note that RoleOf element and object type are defined terms.

Rule 10-5. RoleOf elements indicate the base types of a role type
[Rule 10-5] (REF, EXT, INS) (Interpretation)

An element declaration that has a local name that begins with the string RoleOf MUST represent a base type, of which the containing element instance represents a role.

Rule 10-6. Instance of RoleOf element indicates a role object
[Rule 10-6] (INS) (Interpretation)

When a parent element has a child element valid to an element declaration that is a RoleOf element,

  • The value of the parent element is a role object.
  • The value of the child element is a base object of the role object.

An instance of a RoleOf element indicates the base object of a role. The prefix RoleOf on the element ensures that a role object may be distinguished from other objects and that its link to the base object is also distinguishable from the additional properties that are characteristics or other data of the role.

NIEM does not require that there be only one RoleOf element within a single type, nor does it require that a particular role object have only a single occurrence of a RoleOf element. However, the use of multiple RoleOf elements may not make sense in all cases. An exchange specification may restrict RoleOf elements to a single occurrence within a type.

This specification does not require that a RoleOf element occur in an instance of a role type. In such a case, the instance of the role type behaves like any other type; it simply does not have a reference to its base object. For example, we may talk about a weapon’s use in an incident without referring to the car that acted as the weapon.

10.2.3. External adapter types and external components

There are a variety of commonly used standards that are represented in XML Schema. Such schemas are generally not NIEM-conformant. NIEM-conformant schemas may reference components defined by these external schema documents. This section provides rules under which NIEM-conformant components may be constructed from schema components that are not NIEM-conformant.

[Definition: external schema document]

An external schema document is any schema document that is not one of

Note that, although the schema document for the structures namespace is not conformant, it is not considered an external schema document because it defines the fundamental framework on which NIEM is built; it is considered a supporting namespace. It is not considered an external schema document because of its supporting nature and is thus a special case of this definition.

A schema component defined by an external schema document may be called an external component. A NIEM-conformant type may use external components in its definition. There are two ways to integrate external components into a NIEM-conformant schema:

  1. An external adapter type may be constructed from externally-defined elements and attributes. A goal of this method is to represent, as a single unit, a set of data that embodies a single concept from an external standard. This is an external adapter type.
  2. A type that is not an external adapter type may incorporate externally-defined attributes.
Figure 10-6: Use of external components to create a NIEM-conformant type

For example, a NIEM-conformant type may be created to represent a bibliographic reference from an external standard. Such an object may be composed of multiple elements (of multiple types) from the external standard. These pieces are put together to form a single NIEM-conformant external adapter type. For example, an author element, a book element, and a publisher element may be used to define a single bibliographic entry type.

A NIEM-conformant type built from these components may be used as any other NIEM-conformant type. That is, elements may be constructed from such a type, and those elements are fully NIEM-conformant.

To construct such a component, a NIEM-conformant schema must import the namespace defined by the external schema document.

Rule 11-48, Reference schema imports reference schema (SET), below, and Rule 11-49, Extension schema document imports reference or extension schema (SET), below, require that xs:import elements be consistent with an importing schema document.

A NIEM-conformant schema has well-known documentation points. Therefore, a schema that imports a NIEM-conformant namespace need not provide additional documentation. However, when an external schema document is imported, appropriate documentation must be provided at the point of import because documentation associated with external schema documents is undefined and variable. In this particular case, documentation of external schema documents is required at their point of use in NIEM.

10.2.3.1. Import of external namespace
Rule 10-7. Import of external namespace has data definition
[Rule 10-7] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import[@appinfo:externalImportIndicator]">
     <sch:assert test="some $definition in xs:annotation/xs:documentation[1] satisfies
                         string-length(normalize-space(string($definition))) &gt; 0"
       >An element xs:import that is annotated as importing an external schema document MUST be a documented component.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.2.3.2. External adapter types
[Definition: external adapter type]

An external adapter type is a NIEM-conformant type that adapts external components for use within NIEM. An external adapter type creates a new class of object that embodies a single concept composed of external components. A NIEM-conformant schema defines an external adapter type.

Rule 10-8. External adapter type has indicator
[Rule 10-8] (REF, EXT) (Interpretation)

A type is an external adapter type if and only if it is a complex type with application information of attribute appinfo:externalAdapterTypeIndicator with a value of true.

An external adapter type should contain the information from an external standard to express a complete concept. This expression should be composed of content entirely from an external schema document. Most likely, the external schema document will be based on an external standard with its own legacy support.

In the case of an external expression that is in the form of model groups, attribute groups, or types, additional elements and type components may be created in an external schema document, and the external adapter type may use those components.

In normal (conformant) type definition, a reference to an attribute or element is a reference to a documented component. Within an external adapter type, the references to the attributes and elements being adapted are references to undocumented components. These components must be documented to provide comprehensibility and interoperability. Since documentation made available by nonconformant schemas is undefined and variable, documentation of these components is required at their point of use, within the conformant schema.

Rule 10-9. Structure of external adapter type definition follows pattern
[Rule 10-9] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.2.3.2. External adapter types
[Definition: external adapter type]

An external adapter type is a NIEM-conformant type that adapts external components for use within NIEM. An external adapter type creates a new class of object that embodies a single concept composed of external components. A NIEM-conformant schema defines an external adapter type.

Rule 10-8. External adapter type has indicator
[Rule 10-8] (REF, EXT) (Interpretation)

A type is an external adapter type if and only if it is a complex type with application information of attribute appinfo:externalAdapterTypeIndicator with a value of true.

An external adapter type should contain the information from an external standard to express a complete concept. This expression should be composed of content entirely from an external schema document. Most likely, the external schema document will be based on an external standard with its own legacy support.

In the case of an external expression that is in the form of model groups, attribute groups, or types, additional elements and type components may be created in an external schema document, and the external adapter type may use those components.

In normal (conformant) type definition, a reference to an attribute or element is a reference to a documented component. Within an external adapter type, the references to the attributes and elements being adapted are references to undocumented components. These components must be documented to provide comprehensibility and interoperability. Since documentation made available by nonconformant schemas is undefined and variable, documentation of these components is required at their point of use, within the conformant schema.

Rule 10-9. Structure of external adapter type definition follows pattern
[Rule 10-9] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[@appinfo:externalAdapterTypeIndicator]">
     <sch:assert test="xs:complexContent/xs:extension[
                         resolve-QName(@base, .) = xs:QName('structures:ObjectType')
@@ -738,7 +699,7 @@
                         empty(@appinfo:externalAdapterTypeIndicator)]"
        >An external adapter type definition MUST NOT be a base type definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

Each external adapter type is meant to stand alone; each type expresses a single concept, and is built from schema components from one or more external schema documents.

10.2.3.3. External attribute use
Rule 10-13. External attribute use only in external adapter type

A complex type that is defined by a reference schema document is permitted to contain an attribute use schema component only if it is an external adapter type. This does not apply to a complex type defined by an extension schema document, which is permitted to use external attributes, as long as each attribute use is a documented component, per Rule 10-14, External attribute use has data definition (REF, EXT), below.

[Rule 10-13] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>

Each external adapter type is meant to stand alone; each type expresses a single concept, and is built from schema components from one or more external schema documents.

10.2.3.3. External attribute use
Rule 10-13. External attribute use only in external adapter type

A complex type that is defined by a reference schema document is permitted to contain an attribute use schema component only if it is an external adapter type. This does not apply to a complex type defined by an extension schema document, which is permitted to use external attributes, as long as each attribute use is a documented component, per Rule 10-14, External attribute use has data definition (REF, EXT), below.

[Rule 10-13] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)),
                                        $import in ancestor::xs:schema[1]/xs:import satisfies (
                                     xs:anyURI($import/@namespace) = $ref-namespace
@@ -746,7 +707,7 @@
     <sch:assert test="exists(ancestor::xs:complexType[1]/@appinfo:externalAdapterTypeIndicator)"
       >An external attribute use MUST be in an external adapter type.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term external adapter type.

Rule 10-14. External attribute use has data definition
[Rule 10-14] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term external adapter type.

Rule 10-14. External attribute use has data definition
[Rule 10-14] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)),
                                        $import in ancestor::xs:schema[1]/xs:import satisfies (
                                     xs:anyURI($import/@namespace) = $ref-namespace
@@ -755,7 +716,7 @@
                         string-length(normalize-space(string($documentation))) &gt; 0"
       >An external attribute use MUST be a documented component with a non-empty data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

The terms documented component and data definition are defined.

Rule 10-15. External attribute use not an ID

NIEM schemas use structures:id to enable references between components. Each NIEM-defined complex type must incorporate a definition for structures:id. [XML] Section 3.3.1, Attribute Types entails that a complex type may have no more than one ID attribute. This means that an external attribute use must not be an ID attribute.

[Rule 10-15] (SET) (Constraint)

An attribute use schema component MUST NOT have an {attribute declaration} with an ID type.

The term attribute use schema component is defined by [XML Schema Structures] Section 3.5.1, The Attribute Use Schema Component. Attribute type ID is defined by [XML] Section 3.3.1, Attribute Types.

10.2.3.4. External element use
Rule 10-16. External element use has data definition
[Rule 10-16] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The terms documented component and data definition are defined.

Rule 10-15. External attribute use not an ID

NIEM schemas use structures:id to enable references between components. Each NIEM-defined complex type must incorporate a definition for structures:id. [XML] Section 3.3.1, Attribute Types entails that a complex type may have no more than one ID attribute. This means that an external attribute use must not be an ID attribute.

[Rule 10-15] (SET) (Constraint)

An attribute use schema component MUST NOT have an {attribute declaration} with an ID type.

The term attribute use schema component is defined by [XML Schema Structures] Section 3.5.1, The Attribute Use Schema Component. Attribute type ID is defined by [XML] Section 3.3.1, Attribute Types.

10.2.3.4. External element use
Rule 10-16. External element use has data definition
[Rule 10-16] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[
       some $ref-namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies
         nf:get-document-element(.)/self::xs:schema//xs:import[
@@ -765,18 +726,20 @@
                         string-length(normalize-space(string($documentation))) &gt; 0"
       >An external attribute use MUST be a documented component with a non-empty data definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

The terms documented component and data definition are defined.

10.2.4. Code types
[Definition: code type]

A code type is a NIEM object type with a content model that is constrained by one or more enumeration facets.

These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.

Rule 10-17. Name of code type ends in CodeType
[Rule 10-17] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:complexType">
-    <sch:let name="has-code-type-name" value="ends-with(@name, 'CodeType')"/>
-    <sch:let name="has-code-type-base" value="
-        exists(xs:simpleContent[
-          exists(xs:*[local-name() = ('extension', 'restriction')
-                      and (ends-with(@base, 'CodeSimpleType')
-                           or ends-with(@base, 'CodeType'))])])"/>
-    <sch:assert test="$has-code-type-name = $has-code-type-base"
-      >A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type.</sch:assert>
-  </sch:rule>
-</sch:pattern>

Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.

10.2.5. Proxy types

The NIEM 3.0 release schema niem/proxy/xsd/3.0/xs.xsd provides complex type bases for some of the simple types in the XML Schema namespace. The complex types in this schema reuse the local names of the XML Schema simple types they extend, even though those names don’t follow the naming structure of most conformant complex types. There is a special exception to naming rules to allow the reuse of the XML Schema simple type names in conformant schemas. This is done to make conformant schemas more understandable to people that are familiar with the names of the XML Schema namespace simple types.

A complex type that is a direct extension of a simple type from the XML Schema namespace (e.g., xs:string, xs:integer, xs:boolean) is allowed to have the same local name as the XML Schema simple type, if and only if the extension adds no content other than the attribute group structures:SimpleObjectAttributeGroup. This allows for an intuitive name when using an XML Schema simple type in a conformant schema.

Rule 10-18. Proxy type has designated structure
[Rule 10-18] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The terms documented component and data definition are defined.

10.2.4. Code types
[Definition: code type]

A code type is a NIEM object type for which each simple value carried by the type corresponds to an entry in a list of distinct conceptual entities.

These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.

Many code types have simple content composed of xs:enumeration values. Code types may also be constructed using the NIEM Code Lists Specification [Code Lists], which supports code lists defined using a variety of methods, including CSV spreadsheets.

Rule 10-17. Name of code type ends in CodeType
[Rule 10-17] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:complexType[exists(xs:simpleContent[
+                       exists(xs:*[local-name() = ('extension', 'restriction')
+                                   and (ends-with(@base, 'CodeSimpleType')
+                                   or ends-with(@base, 'CodeType'))])])]">
+    <sch:report test="not(ends-with(@name, 'CodeType'))"
+                >A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'.</sch:report>
+  </sch:rule>
+</sch:pattern>

See Section 11.1.2.3, Code simple types, below, for the definition of code simple type.

Rule 10-18. Code type corresponds to a code list
[Rule 10-18] (REF, EXT) (Constraint)

A complex type SHOULD have a name ending in CodeType if and only if it has a correspondence to a list of distinct conceptual entities.

Rule 10-19. Element of code type has code representation term
[Rule 10-19] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[exists(@name) and exists(@type) and ends-with(@type, 'CodeType')]">
+    <sch:report test="not(ends-with(@name, 'Code'))"
+      >An element with a type that is a code type SHOULD have a name with representation term "Code"</sch:report>
+  </sch:rule>
+</sch:pattern>

Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies that a data component may carry values from a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.

10.2.5. Proxy types

The NIEM 4.0 release schema niem/proxy/xsd/4.0/xs.xsd provides complex type bases for some of the simple types in the XML Schema namespace. The complex types in this schema reuse the local names of the XML Schema simple types they extend, even though those names don’t follow the naming structure of most conformant complex types. There is a special exception to naming rules to allow the reuse of the XML Schema simple type names in conformant schemas. This is done to make conformant schemas more understandable to people that are familiar with the names of the XML Schema namespace simple types.

A complex type that is a direct extension of a simple type from the XML Schema namespace (e.g., xs:string, xs:integer, xs:boolean) is allowed to have the same local name as the XML Schema simple type, if and only if the extension adds no content other than the attribute group structures:SimpleObjectAttributeGroup. This allows for an intuitive name when using an XML Schema simple type in a conformant schema.

Rule 10-20. Proxy type has designated structure
[Rule 10-20] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[some $name in @name,
                                     $extension in xs:simpleContent/xs:extension,
                                     $base-qname in resolve-QName($extension/@base, $extension) satisfies
@@ -789,7 +752,7 @@
                                 resolve-QName(@ref, .) = xs:QName('structures:SimpleObjectAttributeGroup')]]]"
       >A proxy type MUST have the designated structure. It MUST use xs:extension. It MUST NOT use xs:attribute. It MUST include exactly one xs:attributeGroup reference, which must be to structures:SimpleObjectAttributeGroup.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.3. Associations

Within NIEM, an association is a specific relationship between objects. Associations are used when a simple NIEM property is insufficient to model the relationship clearly, or when you want to model properties of the relationship itself.

Here is an example of an association in an XML instance:

Figure 10-7: An association in an instance
<scr:PersonPhoneAssociation>
+</sch:pattern>
10.3. Associations

Within NIEM, an association is a specific relationship between objects. Associations are used when a simple NIEM property is insufficient to model the relationship clearly, or when you want to model properties of the relationship itself.

Here is an example of an association in an XML instance:

Figure 10-7: An association in an instance
<scr:PersonPhoneAssociation>
   <nc:Person>
     <nc:PersonName>
       <nc:PersonFullName>John Doe</nc:PersonFullName>
@@ -800,7 +763,7 @@
       <nc:TelephoneNumberFullID>(212)555-1212</nc:TelephoneNumberFullID>
     </nc:FullTelephoneNumber>
   </nc:TelephoneNumber>
-</scr:PersonPhoneAssociation>

This example shows an association between a person and a phone number. This relationship is defined by the element scr:PersonPhoneAssociation, the structure of which is defined by the type scr:PersonPhoneAssociationType. In practice, an association type usually defines what kinds of things the association relates, while the association element may refine the meaning of the association.

An example of an association type defined by an XML Schema document follows, in Figure 10-8, A definition of an association type, below.

Note that the NIEM Core schema in NIEM 3.0 defines a type nc:AssociationType, which acts as the base type for all of the other association types defined within NIEM Core. This is a convention adopted by that version of NIEM Core namespace, but is not a requirement of this document. An implementer of a NIEM-conformant schema is not required by this specification to base a new association type on nc:AssociationType.

Figure 10-8: A definition of an association type
  <xs:complexType name="PersonPhoneAssociationType">
+</scr:PersonPhoneAssociation>

This example shows an association between a person and a phone number. This relationship is defined by the element scr:PersonPhoneAssociation, the structure of which is defined by the type scr:PersonPhoneAssociationType. In practice, an association type usually defines what kinds of things the association relates, while the association element may refine the meaning of the association.

An example of an association type defined by an XML Schema document follows, in Figure 10-8, A definition of an association type, below.

Note that the NIEM Core schema in NIEM 4.0 defines a type nc:AssociationType, which acts as the base type for all of the other association types defined within NIEM Core. This is a convention adopted by that version of NIEM Core namespace, but is not a requirement of this document. An implementer of a NIEM-conformant schema is not required by this specification to base a new association type on nc:AssociationType.

Figure 10-8: A definition of an association type
  <xs:complexType name="PersonPhoneAssociationType">
     <xs:annotation>
       <xs:documentation>A data type for a relationship between a PERSON and a PHONE.</xs:documentation>
     </xs:annotation>
@@ -817,7 +780,7 @@
     <xs:annotation>
       <xs:documentation>An association between a PERSON and a PHONE.</xs:documentation>
     </xs:annotation>
-  </xs:element>

This schema fragment shows the definition of an association type that defines a relationship between a person and a telephone number. This is followed by the definition of an association element declaration that uses the association type.

[Definition: association type]

In a NIEM-conformant schema, an association type is a type that establishes a relationship between objects, along with the properties of that relationship. An association type provides a structure that does not establish existence of an object but instead specifies relationships between objects.

[Definition: association]

In a NIEM-conformant schema, an association is an element whose type is an association type.

10.3.1. Association types
Rule 10-19. Association type is derived from association type
[Rule 10-19] (REF, EXT) (Constraint)
<sch:pattern>
+  </xs:element>

This schema fragment shows the definition of an association type that defines a relationship between a person and a telephone number. This is followed by the definition of an association element declaration that uses the association type.

[Definition: association type]

In a NIEM-conformant schema, an association type is a type that establishes a relationship between objects, along with the properties of that relationship. An association type provides a structure that does not establish existence of an object but instead specifies relationships between objects.

[Definition: association]

In a NIEM-conformant schema, an association is an element whose type is an association type.

10.3.1. Association types
Rule 10-21. Association type is derived from association type
[Rule 10-21] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:let name="is-association-type" value="exists(@name[ends-with(., 'AssociationType')])"/>
     <sch:let name="has-association-base-type" value="
@@ -827,13 +790,13 @@
     <sch:assert test="$is-association-type = $has-association-base-type"
       >A type MUST have an association type name if and only if it is derived from an association type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Associations are easily identifiable as such and have a commonly defined base type. Using the qualifier Association immediately identifies a type as representing an association.

10.3.2. Association element declarations
Rule 10-20. Association element type is an association type
[Rule 10-20] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Associations are easily identifiable as such and have a commonly defined base type. Using the qualifier Association immediately identifies a type as representing an association.

10.3.2. Association element declarations
Rule 10-22. Association element type is an association type
[Rule 10-22] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name)]">
     <sch:assert test="exists(@type[ends-with(., 'AssociationType')])
                       = exists(@name[ends-with(., 'Association')])"
       >An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Using the qualifier Association immediately identifies an element as representing an association. This document defines the term association type.

10.4. Augmentations

Developers of domain schemas and other schemas that build on and extend the NIEM release schemas need to be able to define additional characteristics of common types. For example, the JXDM domain, which addresses justice and public safety concerns, considers the following elements to be characteristics of a person, as defined by nc:PersonType:

  • j:PersonMedicalInsuranceIndicator
  • j:PersonProfessionalCertificateText
  • j:PersonSightedIndicator
  • j:PersonFBIIdentification

There are several approaches that could be used to by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:

  • It results in numerous, domain-specific specializations of nc:PersonType, each with common content and extension-specific content.
  • There is no method for the developer of an information exchange specification (IES) to bring these types back together into a single type that carries the attributes desired for the IES. XML Schema does not support multiple inheritance, so there is no way to join together j:PersonType, im:PersonType, and cyfs:PersonType.
  • There is no standard or easy way for the developer to express that the various element instances of the various person types represent the same person, or which parts of those instances are required to be populated; does each person restate the name and birthdate, or is that handled by just one instance?
  • A domain, having created its own j:PersonType that extends nc:PersonType, is, of course, going to create elements of that type. These elements will not be easily reused by other domains, as the Immigration namespace will want to use im:PersonType instead of j:PersonType.

This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community.

To handle this need, NIEM has adopted augmentations. There are several parts that fit together for the definition and use of augmentations:

  • Each object type and association type carries an augmentation point element, which provides a place for domain- and extension-specific content in the type. Augmentation points are optional in extension schema documents, but must appear in reference schema documents. Augmentation points are also defined for the base types for object types and association types:

    • structures:ObjectType has augmentation point structures:ObjectAugmentationPoint.
    • structures:AssociationType has augmentation point structures:AssociationAugmentationPoint.
  • A developer of a domain or other schema that extends common types may define elements that are substitutable for an augmentation point. Each of these elements expresses an additional characteristic or relationship of the base type.
  • A developer may also define an augmentation type, and a corresponding augmentation element of that type, which acts as a bucket of elements that apply to the base type. An augmentation element is defined to be substitutable for an augmentation point, which enables it to appear in instances of that base type.

  • A developer of an information exchange may choose, through selection and subsetting reference schemas:

    • Which types will carry augmentation point elements, and the cardinality (i.e. minOccurs, maxOccurs) of those augmentation point elements
    • Which elements will be included that substitute for an augmentation point. Some of these may be direct elements, while others may have an augmentation type, and carry multiple elements for the base type.
    • Which elements will be carried within the augmentation types; each of these will apply to its base type.
  • Augmentation point elements also appear on structures:ObjectType and structures:AssociationType. This allows schema developers to define elements that may be applied to any object or association.

In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange.

[Definition: augmentation]

An augmentation is an element that

  1. is a child of an element that is an instance of an augmentable type, and
  2. is a member of the substitution group of the augmentation point element declaration for the augmentable type.

As an example, here is a definition for nc:PersonType, which includes its augmentation point element:

Figure 10-9: Definition of augmentable type nc:PersonType
<xs:complexType name="PersonType">
+</sch:pattern>

Using the qualifier Association immediately identifies an element as representing an association. This document defines the term association type.

10.4. Augmentations

Developers of domain schemas and other schemas that build on and extend the NIEM release schemas need to be able to define additional characteristics of common types. For example, the JXDM domain, which addresses justice and public safety concerns, considers the following elements to be characteristics of a person, as defined by nc:PersonType:

  • j:PersonMedicalInsuranceIndicator
  • j:PersonProfessionalCertificateText
  • j:PersonSightedIndicator
  • j:PersonFBIIdentification

There are several approaches that could be used to by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:

  • It results in numerous, domain-specific specializations of nc:PersonType, each with common content and extension-specific content.
  • There is no method for the developer of an information exchange package description (IEPD) to bring these types back together into a single type that carries the attributes desired for the IEPD. XML Schema does not support multiple inheritance, so there would be no way to join together nc:PersonType, j:PersonType, and im:PersonType.
  • There is no standard or easy way for the developer to express that the various element instances of the various person types represent the same person, or which parts of those instances are required to be populated; does each person restate the name and birth-date, or is that handled by just one instance?

This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community.

To handle this need, NIEM has adopted augmentations. There are several parts that fit together for the definition and use of augmentations:

  • Each object type and association type carries an augmentation point element, which provides a place for domain- and extension-specific content in the type. Augmentation points are optional in extension schema documents, but must appear in reference schema documents. Augmentation points are also defined for the base types for object types and association types:

    • structures:ObjectType has augmentation point structures:ObjectAugmentationPoint.
    • structures:AssociationType has augmentation point structures:AssociationAugmentationPoint.
  • A developer of a domain or other schema that extends common types may define elements that are substitutable for an augmentation point. Each of these elements expresses an additional characteristic or relationship of the base type.
  • A developer may also define an augmentation type, and a corresponding augmentation element of that type, which acts as a container of elements that apply to the base type. An augmentation element is defined to be substitutable for an augmentation point, which enables it to appear in instances of that base type.

  • A developer of an information exchange may choose, through selection and subsetting reference schemas:

    • Which types will carry augmentation point elements, and the cardinality (i.e. minOccurs, maxOccurs) of those augmentation point elements
    • Which elements will be included that substitute for an augmentation point. Some of these may be direct elements, while others may have an augmentation type, and carry multiple elements for the base type.
    • Which elements will be carried within the augmentation types; each of these will apply to its base type.
  • Augmentation point elements also appear on structures:ObjectType and structures:AssociationType. This allows schema developers to define elements that may be applied to any object or association.

In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange.

The term augmentation describes any element in a NIEM-conformant instance XML document that appears as a result of being substituted for an augmentation point element. Such an element may have a type that is an augmentation type, or it may be a direct element that represents a property.

[Definition: augmentation]

An augmentation is an element that

  1. is a child of an element that is an instance of an augmentable type, and
  2. is a member of the substitution group of the augmentation point element declaration for the augmentable type.

As an example, here is a definition for nc:PersonType, which includes its augmentation point element:

Figure 10-9: Definition of augmentable type nc:PersonType
<xs:complexType name="PersonType">
   <xs:annotation>
     <xs:documentation>A data type for a human being.</xs:documentation>
   </xs:annotation>
@@ -871,7 +834,8 @@
   <xs:annotation>
     <xs:documentation>Additional information about a person.</xs:documentation>
   </xs:annotation>
-</xs:element>

The augmentation type is derived from structures:AugmentationType and has a name ending in AugmentationType. The augmentation element uses the type, and has a name ending in Augmentation. Note that the thing that binds the augmentation type to the augmentation point is the augmentation element’s use of the augmentation point element as its substitution group. This means that an augmentation type can be reused for multiple types, by creating more augmentation elements that have that type, each with its own substitution group for a different augmentation point.

In addition to defining elements that use an augmentation type, a schema document may define an element that substitutes for an augmentation point element, but does not use an augmentation type. For example, the CBRN namespace defines an augmentation to nc:ScheduleType:

Figure 10-12: An augmentation that is not an augmentation type
            substitutionGroup="nc:ScheduleAugmentationPoint">
+</xs:element>

The augmentation type is derived from structures:AugmentationType and has a name ending in AugmentationType. The augmentation element uses the type, and has a name ending in Augmentation. Note that the thing that binds the augmentation type to the augmentation point is the augmentation element’s use of the augmentation point element as its substitution group. This means that an augmentation type can be reused for multiple types, by creating more augmentation elements that have that type, each with its own substitution group for a different augmentation point.

In addition to defining elements that use an augmentation type, a schema document may define an element that substitutes for an augmentation point element, but does not use an augmentation type. For example, the following CBRN namespace defines an augmentation to nc:ScheduleType. While an element of an augmentation type acts as a container, holding elements that apply to an augmented object, this element is a direct property of a schedule, providing a meaningful characteristic (hours of operation) for a schedule. The resulting syntax is briefer than it would be using an augmentation type; the resulting instance looks similar to how it might look if the schedule type had been extended, rather than augmented.

Figure 10-12: An augmentation that is not an augmentation type
<xs:element name="OperatingSchedule" type="cbrn:OperatingScheduleType"
+            substitutionGroup="nc:ScheduleAugmentationPoint">
   <xs:annotation>
     <xs:documentation>A schedule providing the beginning and ending hours of operation by weekday, for a designated time period.</xs:documentation>
   </xs:annotation>
@@ -888,7 +852,7 @@
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
-</xs:complexType>

This method can be used by an information exchange developer to define individual attributes that can be applied to any augmentable type.

Note that the augmentation method can introduce an additional element into every object type or association type in an exchange, which provides opportunity for some errors in schema development. It is important that developers of exchanges not introduce elements substitutable for an augmentation point into complex types multiple ways, as it can introduce XML Schema’s Unique Particle Attribution errors. A single complex type should not introduce an element via both element substitution and element reference. This constraint is also supported by Rule 11-21, Element or attribute declaration introduced only once into a type (REF, EXT), below.

10.4.1. Augmentable types
[Definition: augmentable type]

An augmentable type is complex type definition that

Rule 10-21. Augmentable type has augmentation point element
[Rule 10-21] (REF) (Constraint)
<sch:pattern>
+</xs:complexType>

This method can be used by an information exchange developer to define individual attributes that can be applied to any augmentable type.

Note that the augmentation method can introduce an additional element into every object type or association type in an exchange, which provides opportunity for some errors in schema development. It is important that developers of exchanges not introduce elements substitutable for an augmentation point into complex types multiple ways, as it can introduce XML Schema’s Unique Particle Attribution errors. A single complex type should not introduce an element via both element substitution and element reference. This constraint is also supported by Rule 11-19, Element or attribute declaration introduced only once into a type (REF, EXT), below.

10.4.1. Augmentable types
[Definition: augmentable type]

An augmentable type is complex type definition that

Rule 10-23. Augmentable type has augmentation point element
[Rule 10-23] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[
                        @name[not(ends-with(., 'MetadataType'))
                              and not(ends-with(., 'AugmentationType'))]
@@ -901,7 +865,7 @@
                         @ref[resolve-QName(., ..) = $augmentation-point-qname]]"
       >An augmentable type MUST contain an element use of its augmentation point element.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-22. Augmentable type has at most one augmentation point element
[Rule 10-22] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-24. Augmentable type has at most one augmentation point element
[Rule 10-24] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[
                        @name[not(ends-with(., 'MetadataType'))
                              and not(ends-with(., 'AugmentationType'))]
@@ -911,10 +875,10 @@
              value="QName(string(nf:get-target-namespace(.)),
                           replace(./@name, 'Type$', 'AugmentationPoint'))"/>
     <sch:assert test="count(xs:complexContent/xs:extension/xs:sequence/xs:element[
-                              @ref[resolve-QName(., ..) = $augmentation-point-qname]]) &lt;= 1"
+                              @ref[resolve-QName(., ..) = $augmentation-point-qname]]) le 1"
       >An augmentable type MUST contain no more than one element use of its augmentation point element.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.4.2. Augmentation point element declarations
Rule 10-23. Augmentation point corresponds to augmentable type
[Rule 10-23] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.4.2. Augmentation point element declarations
Rule 10-25. Augmentation point corresponds to augmentable type
[Rule 10-25] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name[
                                  matches(., 'AugmentationPoint$')])]">
     <sch:let name="element-name" value="@name"/>
@@ -928,19 +892,19 @@
                                 and exists(child::xs:complexContent)])"
       >A schema document containing an augmentation point element declaration MUST also contain a corresponding augmentable type definition.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the terms schema document, element declaration, and augmentable type.

Rule 10-24. An augmentation point has no type
[Rule 10-24] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the terms schema document, element declaration, and augmentable type.

Rule 10-26. An augmentation point has no type
[Rule 10-26] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name[
                                  matches(., 'AugmentationPoint$')])]">
     <sch:assert test="empty(@type)"
         >An augmentation point element MUST have no type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Because an augmentation point element has no type, it will be abstract, per Rule 9-37, Untyped element is abstract (REF, EXT), above

Rule 10-25. An augmentation point has no substitution group
[Rule 10-25] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Because an augmentation point element has no type, it will be abstract, per Rule 9-38, Untyped element is abstract (REF, EXT), above

Rule 10-27. An augmentation point has no substitution group
[Rule 10-27] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name[
                                  matches(., 'AugmentationPoint$')])]">
     <sch:assert test="empty(@substitutionGroup)"
         >An augmentation point element MUST have no substitution group.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.4.3. Augmentation point element use
Rule 10-26. Augmentation point element may only be referenced by its type
[Rule 10-26] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.4.3. Augmentation point element use
Rule 10-28. Augmentation point element may only be referenced by its type
[Rule 10-28] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType//xs:element[exists(@ref[
                        matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
 
@@ -949,44 +913,44 @@
                replace(local-name-from-QName(resolve-QName(@ref, .)), 'AugmentationPoint$', 'Type'))"
       >An augmentation point element MUST only be referenced by its corresponding type.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-27. Augmentation point reference is optional
[Rule 10-27] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-29. Augmentation point reference is optional
[Rule 10-29] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType//xs:element[exists(@ref[
                            matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
     <sch:assert test="exists(@minOccurs) and xs:integer(@minOccurs) = 0"
         >An augmentation point element particle MUST have attribute minOccurs equal to 0.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-28. Augmentation point reference is unbounded
[Rule 10-28] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-30. Augmentation point reference is unbounded
[Rule 10-30] (REF) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType//xs:element[exists(@ref[
                            matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
     <sch:assert test="exists(@maxOccurs) and string(@maxOccurs) = 'unbounded'"
        >An augmentation point element particle MUST have attribute maxOccurs set to unbounded.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-29. Augmentation point reference must be last particle
[Rule 10-29] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-31. Augmentation point reference must be last particle
[Rule 10-31] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType//xs:element[exists(@ref[
                            matches(local-name-from-QName(resolve-QName(., ..)), 'AugmentationPoint$')]) ]">
     <sch:assert test="empty(following-sibling::*)"
        >An augmentation point element particle MUST be the last element occurrence in its content model.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.4.4. Augmentation types
[Definition: augmentation type]

An augmentation type is a complex type definition that

  1. provides elements that establish relationships to a base object or association, rather than to the instance of the augmentation type itself, and
  2. is designed to be the type of an augmentation element declaration.
[Definition: augmentation element declaration]

An augmentation element declaration is an element declaration that

  1. has a type that is an augmentation type, and
  2. carries elements that establish a relationship to its parent object or association
  3. is designed to be used as an augmentation of its parent object or association
Rule 10-30. Element within instance of augmentation type modifies base
[Rule 10-30] (INS) (Interpretation)

Given:

  1. Some element has a value $base-value.
  2. Value $base-value contains element $augmentation.
  3. Element $augmentation has property [element declaration] with a value that is an augmentation element declaration.
  4. Element $augmentation has a value, by reference or by content.
  5. The value of $augmentation contains element $relationship.
  6. Element $relationship has a value, by reference or by content.

Element $relationship establishes a relationship between $base-value and the value of $relationship.

Rule 10-31. Only an augmentation type name ends in AugmentationType
[Rule 10-31] (REF, EXT) (Interpretation)

A schema component that has a name that ends in AugmentationType MUST be an augmentation type.

The primary indicator that a complex type is an augmentation type is its name. Using the qualifier Augmentation immediately identifies a type as an augmentation type.

Rule 10-32. Schema component with name ending in AugmentationType is an augmentation type
[Rule 10-32] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.4.4. Augmentation types
[Definition: augmentation type]

An augmentation type is a complex type definition that

  1. provides elements that establish relationships to a base object or association, rather than to the instance of the augmentation type itself, and
  2. is designed to be the type of an augmentation element declaration.
[Definition: augmentation element declaration]

An augmentation element declaration is an element declaration that

  1. has a type that is an augmentation type, and
  2. carries elements that establish a relationship to its parent object or association
  3. is designed to be used as an augmentation of its parent object or association

This term may be mistaken for another. The term augmentation element declaration describes element declarations defined by schemas, while the term augmentation applies to any element information item within an XML document that appears as the result of being substituted for an augmentation point.

Rule 10-32. Element within instance of augmentation type modifies base
[Rule 10-32] (INS) (Interpretation)

Given:

  1. Some element has a value $base-value.
  2. Value $base-value contains element $augmentation.
  3. Element $augmentation has property [element declaration] with a value that is an augmentation element declaration.
  4. Element $augmentation has a value, by reference or by content.
  5. The value of $augmentation contains element $relationship.
  6. Element $relationship has a value, by reference or by content.

Element $relationship establishes a relationship between $base-value and the value of $relationship.

Rule 10-33. Only an augmentation type name ends in AugmentationType
[Rule 10-33] (REF, EXT) (Interpretation)

A schema component that has a name that ends in AugmentationType MUST be an augmentation type.

The primary indicator that a complex type is an augmentation type is its name. Using the qualifier Augmentation immediately identifies a type as an augmentation type.

Rule 10-34. Schema component with name ending in AugmentationType is an augmentation type
[Rule 10-34] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[ends-with(@name, 'AugmentationType')]">
     <sch:assert test="self::xs:complexType/xs:complexContent/xs:*[
                         (self::xs:extension or self::xs:restriction)
                         and ends-with(@base, 'AugmentationType')]"
        >An augmentation type definition schema component with {name} ending in 'AugmentationType' MUST be an augmentation type definition that is a complex type definition with complex content that extends or restricts an augmentation type.</sch:assert>
   </sch:rule>
-</sch:pattern>

The base type definition of an augmentation type is required to be from a conformant namespace by Rule 11-3, Base type definition defined by conformant schema (REF, EXT), below.

Rule 10-33. Type derived from augmentation type is an augmentation type
[Rule 10-33] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The base type definition of an augmentation type is required to be from a conformant namespace by Rule 11-2, Base type definition defined by conformant schema (REF, EXT), below.

Rule 10-35. Type derived from augmentation type is an augmentation type
[Rule 10-35] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[(self::xs:restriction or self::xs:extension)
                           and ends-with(@base, 'AugmentationType')]">
     <sch:assert test="ancestor::xs:complexType[ends-with(@name, 'AugmentationType')]"
                 >A type definition derived from an augmentation type MUST be an augmentation type definition</sch:assert>
   </sch:rule>
-</sch:pattern>
10.4.5. Augmentation element declarations
Rule 10-34. Augmentation element type is an augmentation type
[Rule 10-34] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.4.5. Augmentation element declarations
Rule 10-36. Augmentation element type is an augmentation type
[Rule 10-36] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name)]">
     <sch:assert test="exists(@type[ends-with(., 'AugmentationType')])
                       = exists(@name[ends-with(., 'Augmentation')])"
       >An element declaration MUST have a name that ends in "Augmentation" if and only if it has a type that is an augmentation type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Using the qualifier Augmentation immediately identifies an element as representing an augmentation.

Rule 10-35. Augmentation elements are not used directly
[Rule 10-35] (REF, SET) (Constraint)

Within a reference schema document, a complex type definition MUST NOT have an element use of

10.5. Metadata

There are rules for use of metadata in instance in Section 12.3, Instance metadata, below.

10.5.1. Metadata types

Within NIEM, metadata is defined as data about data. This may include information such as the security of a piece of data or the source of the data. These pieces of metadata may be composed into a metadata type. The types of data to which metadata may be applied may be constrained.

[Definition: metadata type]

A metadata type describes data about data, that is, information that is not descriptive of objects and their relationships, but is descriptive of the data itself. It is useful to provide a general mechanism for data about data. This provides required flexibility to precisely represent information.

Rule 10-36. Metadata type has data about data
[Rule 10-36] (REF, EXT) (Constraint)

Within the schema, a metadata type MUST contain elements appropriate for a specific class of data about data.

Rule 10-37. Metadata type derived from structures:MetadataType
[Rule 10-37] (REF, EXT) (Constraint)

Within the schema, a metadata type and only a metadata type MUST be derived directly from structures:MetadataType.

A metadata type establishes a specific, named aggregation of data about data. Any type derived from structures:MetadataType is a metadata type. Metadata types should not be derived from other metadata types. Such metadata types should be used as is and additional metadata types defined for additional content.

Rule 10-38. Metadata types are derived from metadata types
[Rule 10-38] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Using the qualifier Augmentation immediately identifies an element as representing an augmentation.

Rule 10-37. Augmentation elements are not used directly
[Rule 10-37] (REF, SET) (Constraint)

Within a reference schema document, a complex type definition MUST NOT have an element use of

10.5. Metadata

There are rules for use of metadata in instance in Section 12.3, Instance metadata, below.

10.5.1. Metadata types

Within NIEM, metadata is defined as data about data. This may include information such as the security of a piece of data or the source of the data. These pieces of metadata may be composed into a metadata type. The types of data to which metadata may be applied may be constrained.

[Definition: metadata type]

A metadata type describes data about data, that is, information that is not descriptive of objects and their relationships, but is descriptive of the data itself. It is useful to provide a general mechanism for data about data. This provides required flexibility to precisely represent information.

Rule 10-38. Metadata type has data about data
[Rule 10-38] (REF, EXT) (Constraint)

Within the schema, a metadata type MUST contain elements appropriate for a specific class of data about data.

Rule 10-39. Metadata type derived from structures:MetadataType
[Rule 10-39] (REF, EXT) (Constraint)

Within the schema, a metadata type and only a metadata type MUST be derived directly from structures:MetadataType.

A metadata type establishes a specific, named aggregation of data about data. Any type derived from structures:MetadataType is a metadata type. Metadata types should not be derived from other metadata types. Such metadata types should be used as is and additional metadata types defined for additional content.

Rule 10-40. Metadata types are derived from metadata types
[Rule 10-40] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType">
     <sch:let name="is-metadata-type" value="exists(@name[ends-with(., 'MetadataType')])"/>
     <sch:let name="has-metadata-base-type" value="
@@ -996,13 +960,13 @@
     <sch:assert test="$is-metadata-type = $has-metadata-base-type"
       >A type MUST have a metadata type name if an only if it is derived from a metadata type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Using the qualifier Metadata immediately identifies a type as representing metadata.

10.5.2. Metadata element declarations
[Definition: metadata element declaration]

A metadata element declaration is an element declaration defined by a reference schema document or an extension schema document that defines a metadata object. A metadata element declaration has a name ending in Metadata, and a {type definition} that is a metadata type.

There are limitations on the meaning of a metadata element in an instance; it does not establish existence of an object, nor is it a property of its containing object.

Rule 10-39. Metadata element declaration type is a metadata type
[Rule 10-39] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Using the qualifier Metadata immediately identifies a type as representing metadata.

10.5.2. Metadata element declarations
[Definition: metadata element declaration]

A metadata element declaration is an element declaration defined by a reference schema document or an extension schema document that defines a metadata object. A metadata element declaration has a name ending in Metadata, and a {type definition} that is a metadata type.

There are limitations on the meaning of a metadata element in an instance; it does not establish existence of an object, nor is it a property of its containing object.

Rule 10-41. Metadata element declaration type is a metadata type
[Rule 10-41] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@name)]">
     <sch:assert test="exists(@type[ends-with(., 'MetadataType')])
                       = exists(@name[ends-with(., 'Metadata')])"
       >An element MUST have a name that ends in 'Metadata' if and only if it has a type that is a metadata type.</sch:assert>
   </sch:rule>
-</sch:pattern>

Using the qualifier Metadata immediately identifies an element as representing metadata. This document defines the term metadata type.

Rule 10-40. Metadata element has applicable elements

Each metadata element declaration may be applied to a set of elements. Any element to which a metadata element may be validly applied is called an applicable element for the metadata element.

[Rule 10-40] (REF, EXT, SET) (Interpretation)

The set of applicable elements for a metadata element declaration are as follows:

  • A metadata element declaration that has neither an attribute appinfo:appliesToTypes nor an attribute appinfo:appliesToElements may be applied to any element.

  • A metadata element declaration that has either an attribute appinfo:appliesToTypes or an attribute appinfo:appliesToElements may be applied to

    • any element whose qualified name is in the value of appinfo:appliesToElements, or any element with a declaration that is in the substitution group of the declaration of such an element, and to
    • any element with a type with a qualified name that is in the value of appinfo:appliesToTypes, or any element with a type that is validly derived from such a type.
10.6. Container elements

All NIEM properties establish a relationship between the object holding the property and the value of the property. For example, an activity object of type nc:ActivityType may have an element nc:ActivityDescriptionText. This element will be of type nc:TextType and represents a NIEM property owned by that activity object. An occurrence of this element within an activity object establishes a relationship between the activity object and the text: the text is the description of the activity.

In a NIEM-conformant instance, an element establishes a relationship between the object that contains it and the element’s value. This relationship between the object and the element may be semantically strong, such as the text description of an activity in the previous example, or it may be semantically weak, with its exact meaning left unstated. In NIEM, the contained element involved in a weakly defined semantic relationship is commonly referred to as a container element.

A container element establishes a weakly defined relationship with its containing element. For example, an object of type nc:ItemDispositionType may have a container element nc:Item of type nc:ItemType. The container element nc:Item does not establish what relationship exists between the object of nc:ItemDispositionType and itself. There could be any of a number of possible semantics between an object and the value of a container element. It could be a contained object, a subpart, a characteristic, or some other relationship. The appearance of this container element inside the nc:ItemDispositionType merely establishes that the disposition has an item.

The name of the container element is usually based on the NIEM type that defines it: nc:PersonType uses a container element nc:Person, while nc:ActivityType uses a container element nc:Activity. The concept of an element as a container element is a notional one.

There are no formalized rules addressing what makes up a container element. A container element is vaguely defined and carries very little semantics about its context and its contents. Accordingly, there is no formal definition of container elements in NIEM: There are no specific artifacts that define a container element; there are no appinfo or other labels for container elements.

The appearance of a container element within a NIEM type carries no additional semantics about the relationship between the property and the containing type. The use of container elements indicates only that there is a relationship; it does not provide any semantics for interpreting that relationship.

For example, a NIEM container element nc:Person would be associated with the NIEM type nc:PersonType. The use of the NIEM container element nc:Person in a containing NIEM type indicates that a person has some association with the instances of the containing NIEM type. But because the nc:Person container element is used, there is no additional meaning about the association of the person and the instance containing it. While there is a person associated with the instance, nothing is known about the relationship except its existence.

The use of the Person container element is in contrast to a NIEM property named nc:AssessmentPerson, also of NIEM type nc:PersonType. When the NIEM property nc:AssessmentPerson is contained within an instance of a NIEM type, it is clear that the person referenced by this property was responsible for an assessment of some type, relevant to the exchange being modeled. The more descriptive name, nc:AssessmentPerson, gives more information about the relationship of the person with the containing instance, as compared with the semantic-free implications associated with the use of the nc:Person container element.

When a NIEM-conformant schema requires a new container element, it may define a new element with a concrete type and a general name, with general semantics. Any schema may define a container element when it requires one.

10.7. The Representation pattern

One need frequently faced by schema developers is for multiple representations for a single concept. For example, for a general concept of a point in time, there are numerous base representations, and innumerable ways to combine them. For example, the XML Schema definition language defines the types xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth, each representing a point in time, or perhaps a span of time. There is a need in XML Schema to be able to represent a general concept like a point in time, along with a variety of representations for the concept.

Note that this need is a bit different than specialization of relationships (e.g., rdfs:subPropertyOf), in that it specifically is to be used to describe and carry the variety of representations for a particular concept. The need is to be able to represent an abstract point in time using a single type, and then to add a set of specific representations for that basic concept.

There are a variety of methods that could be used to satisfy this need. A method could be devised that uses an abstract type, along with a set of concrete extensions of that abstract type. However, there would still be a need for a set of concrete elements to carry the types, as type substitution (distinct from element substitution) is not widely adopted across the NIEM community. As well, it is difficult to create a network of complex types with complex content and complex types with simple content that all substitute for a base type; the XML Schema syntax is complicated. Other alternatives each have their pros and cons.

To handle this need, NIEM has adopted the Representation pattern, in which a type has contains a representation element, and the various representations for that type are in the substitution group for that representation element.

For example, the definition of nc:DateType uses this pattern:

Figure 10-14: A type definition that uses the Representation pattern
<xs:complexType name="DateType">
+</sch:pattern>

Using the qualifier Metadata immediately identifies an element as representing metadata. This document defines the term metadata type.

Rule 10-42. Metadata element has applicable elements

Each metadata element declaration may be applied to a set of elements. Any element to which a metadata element may be validly applied is called an applicable element for the metadata element.

[Rule 10-42] (REF, EXT, SET) (Interpretation)

The set of applicable elements for a metadata element declaration are as follows:

  • A metadata element declaration that has neither an attribute appinfo:appliesToTypes nor an attribute appinfo:appliesToElements may be applied to any element.

  • A metadata element declaration that has either an attribute appinfo:appliesToTypes or an attribute appinfo:appliesToElements may be applied to

    • any element whose qualified name is in the value of appinfo:appliesToElements, or any element with a declaration that is in the substitution group of the declaration of such an element, and to
    • any element with a type with a qualified name that is in the value of appinfo:appliesToTypes, or any element with a type that is validly derived from such a type.
10.6. Container elements

All NIEM properties establish a relationship between the object holding the property and the value of the property. For example, an activity object of type nc:ActivityType may have an element nc:ActivityDescriptionText. This element will be of type nc:TextType and represents a NIEM property owned by that activity object. An occurrence of this element within an activity object establishes a relationship between the activity object and the text: the text is the description of the activity.

In a NIEM-conformant instance, an element establishes a relationship between the object that contains it and the element’s value. This relationship between the object and the element may be semantically strong, such as the text description of an activity in the previous example, or it may be semantically weak, with its exact meaning left unstated. In NIEM, the contained element involved in a weakly defined semantic relationship is commonly referred to as a container element.

A container element establishes a weakly defined relationship with its containing element. For example, an object of type nc:ItemDispositionType may have a container element nc:Item of type nc:ItemType. The container element nc:Item does not establish what relationship exists between the object of nc:ItemDispositionType and itself. There could be any of a number of possible semantics between an object and the value of a container element. It could be a contained object, a subpart, a characteristic, or some other relationship. The appearance of this container element inside the nc:ItemDispositionType merely establishes that the disposition has an item.

The name of the container element is usually based on the NIEM type that defines it: nc:PersonType uses a container element nc:Person, while nc:ActivityType uses a container element nc:Activity. The concept of an element as a container element is a notional one.

There are no formalized rules addressing what makes up a container element. A container element is vaguely defined and carries very little semantics about its context and its contents. Accordingly, there is no formal definition of container elements in NIEM: There are no specific artifacts that define a container element; there are no appinfo or other labels for container elements.

The appearance of a container element within a NIEM type carries no additional semantics about the relationship between the property and the containing type. The use of container elements indicates only that there is a relationship; it does not provide any semantics for interpreting that relationship.

For example, a NIEM container element nc:Person would be associated with the NIEM type nc:PersonType. The use of the NIEM container element nc:Person in a containing NIEM type indicates that a person has some association with the instances of the containing NIEM type. But because the nc:Person container element is used, there is no additional meaning about the association of the person and the instance containing it. While there is a person associated with the instance, nothing is known about the relationship except its existence.

The use of the Person container element is in contrast to a NIEM property named nc:AssessmentPerson, also of NIEM type nc:PersonType. When the NIEM property nc:AssessmentPerson is contained within an instance of a NIEM type, it is clear that the person referenced by this property was responsible for an assessment of some type, relevant to the exchange being modeled. The more descriptive name, nc:AssessmentPerson, gives more information about the relationship of the person with the containing instance, as compared with the semantic-free implications associated with the use of the nc:Person container element.

When a NIEM-conformant schema requires a new container element, it may define a new element with a concrete type and a general name, with general semantics. Any schema may define a container element when it requires one.

10.7. The Representation pattern

One need frequently faced by schema developers is for multiple representations for a single concept. For example, for a general concept of a point in time, there are numerous base representations, and innumerable ways to combine them. For example, the XML Schema definition language defines the types xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth, each representing a point in time, or perhaps a span of time. There is a need in XML Schema to be able to represent a general concept like a point in time, along with a variety of representations for the concept.

Note that this need is a bit different than specialization of relationships (e.g., rdfs:subPropertyOf), in that it specifically is to be used to describe and carry the variety of representations for a particular concept. The need is to be able to represent an abstract point in time using a single type, and then to add a set of specific representations for that basic concept.

There are a variety of methods that could be used to satisfy this need. A method could be devised that uses an abstract type, along with a set of concrete extensions of that abstract type. However, there would still be a need for a set of concrete elements to carry the types, as type substitution (distinct from element substitution) is not widely adopted across the NIEM community. As well, it is difficult to create a network of complex types with complex content and complex types with simple content that all substitute for a base type; the XML Schema syntax is complicated. Other alternatives each have their pros and cons.

To handle this need, NIEM has adopted the Representation pattern, in which a type has contains a representation element, and the various representations for that type are in the substitution group for that representation element.

For example, the definition of nc:DateType uses this pattern:

Figure 10-14: A type definition that uses the Representation pattern
<xs:complexType name="DateType">
   <xs:annotation>
     <xs:documentation>A data type for a calendar date.</xs:documentation>
   </xs:annotation>
@@ -1044,62 +1008,87 @@
   <xs:annotation>
     <xs:documentation>A year and month.</xs:documentation>
   </xs:annotation>
-</xs:element>

This method has several benefits:

  • Its implementation requires a minimum number of additional schema components. There is only the one abstract representation element; all other elements are concrete and needed to carry strongly typed values.
  • It is simple to implement. The method requires only elements, and the definition of each element is quite simple.
  • It is straightforward to use, as its implementation is based on element substitution, which is already widely used by NIEM.
  • It is highly extensible. Any domain or exchange specification may define additional representations for any concept, by defining new elements substitutable for the representation element.
Rule 10-41. Name of element that ends in Representation is abstract
[Rule 10-41] (REF, EXT) (Constraint)
<sch:pattern>
+</xs:element>

This method has several benefits:

  • Its implementation requires a minimum number of additional schema components. There is only the one abstract representation element; all other elements are concrete and needed to carry strongly typed values.
  • It is simple to implement. The method requires only elements, and the definition of each element is quite simple.
  • It is straightforward to use, as its implementation is based on element substitution, which is already widely used by NIEM.
  • It is highly extensible. Any domain or exchange specification may define additional representations for any concept, by defining new elements substitutable for the representation element.
Rule 10-43. Name of element that ends in Representation is abstract
[Rule 10-43] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[@name[ends-with(., 'Representation')]]">
     <sch:report test="empty(@abstract) or xs:boolean(@abstract) = false()"
       >An element declaration with a name that ends in 'Representation' SHOULD have the {abstract} property with a value of "true".</sch:report>
   </sch:rule>
-</sch:pattern>
[Definition: representation element declaration]

A representation element declaration is an element declaration that is abstract, and that has a {name} that ends in Representation.

Rule 10-42. A substitution for a representation element declaration is a value for a type
[Rule 10-42] (REF, EXT) (Interpretation)

Any element declaration that is substitutable for a representation element declaration represents an optional representation of a value of a type that carries the representation element.

10.8. Naming rules

This section outlines the rules used to create names for NIEM data components previously discussed in this document. Data component names must be understood easily both by humans and by machine processes. These rules improve name consistency by restricting characters, terms, and syntax that could otherwise allow too much variety and potential ambiguity. These rules also improve readability of names for humans, facilitate parsing of individual terms that compose names, and support various automated tasks associated with dictionary and controlled vocabulary maintenance.

Rule 10-43. Schema component name composed of English words
[Rule 10-43] (REF, EXT) (Constraint)

The name of any XML Schema component defined by the schema MUST be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED].

The English language has many spelling variations for the same word. For example, American English program has a corresponding British spelling programme. This variation has the potential to cause interoperability problems when XML components are exchanged because of the different names used by the same elements. Providing users with a dictionary standard for spelling will mitigate this potential interoperability issue.

Rule 10-44. Schema component names have only specific characters
[Rule 10-44] (REF, EXT) (Constraint)

The name of any XML Schema component defined by the schema MUST contain only the following characters:

  • Upper-case letters (A–Z).
  • Lower-case letters (a–z).
  • Digits (0–9).
  • Hyphen (-).

Other characters, such as the underscore (_) character and the period (.) character MUST NOT appear in component names in NIEM-conformant schemas.

Rule 10-45. Hyphen in component name is a separator
[Rule 10-45] (REF, EXT) (Constraint)

The hyphen character (-) MAY appear in component names only when used as a separator between parts of a single word, phrase, or value, which would otherwise be incomprehensible without the use of a separator.

Names of standards and specifications, in particular, tend to consist of series of discrete numbers. Such names require some explicit separator to keep the values from running together. The separator used within NIEM is the hyphen.

Names of NIEM components follow the rules of XML Schema, by Rule 7-3, Document is a schema document (REF, EXT), above. NIEM components also follow the rules specified herein for each type of XML Schema component.

10.8.1. Character case

Names of conformant components use camel case formatting. Camel case is the convention of writing compound words or phrases with no spaces and an initial lowercase or uppercase letter, with each remaining word element beginning with an uppercase letter. UpperCamelCase is written with an initial uppercase letter, and lowerCamelCase is written with an initial lowercase letter.

Rule 10-46. Names use camel case
[Rule 10-46] (REF, EXT) (Constraint)

The name of any XML Schema component defined by the schema MUST use the camel case formatting convention.

Rule 10-47. Attribute name begins with lower case letter
[Rule 10-47] (REF, EXT) (Constraint)

Within the schema, any attribute declaration MUST have a name that begins with a lower-case letter (a–z).

Rule 10-48. Name of schema component other than attribute begins with upper case letter
[Rule 10-48] (REF, EXT) (Constraint)

Within the schema, any XML Schema component other than an attribute declaration MUST have a name that begins with an upper-case letter (A–Z).

The foregoing rules establish lowerCamelCase for all NIEM components that are XML attributes and UpperCamelCase for all NIEM components that are types, elements, or groups.

10.8.2. Use of acronyms and abbreviations

Acronyms and abbreviations have the ability to improve readability and comprehensibility of large, complex, or frequently used terms. They also obscure meaning and impair understanding when their definitions are not clear or when they are used injudiciously. They should be used with great care. Acronyms and abbreviations that are used must be documented and used consistently.

Rule 10-49. Names use common abbreviations
[Rule 10-49] (REF, EXT) (Constraint)

The schema MUST use, in defined names, the abbreviations identified by Table 10-1, Abbreviations used in schema component names, rather than their full meanings.

Table 10-1: Abbreviations used in schema component names
AbbreviationFull Meaning
IDIdentifier
URIUniform Resource Identifier

Consistent, controlled, and documented abridged terms that are used frequently and/or tend to be lengthy can support readability, clarity, and reduction of name length.

10.8.2.1. Use of Acronyms, Initialisms, Abbreviations, and Jargon

The NDR establishes appinfo for local terminology that introduces such terms into the schema document in which the appinfo appears.

[Definition: local term]

In a conformant schema document, a local term is a word, phrase, acronym, or other string of characters for which all of the following are true:

  1. It is not a term defined in the [OED], or it has a non-OED definition, or its word sense may not be clear.
  2. It is introduced into the schema document via an appinfo element appinfo:LocalTerm.
  3. It is used in the local name of a schema component within the schema document.

Local terminology is introduced into a schema document by the use of appinfo:LocalTerm within the schema.

See additional rules constraining the use of local terminology in Section 10.9.2, Local terminology, below.

Rule 10-50. Local term declaration is local to its schema document
[Rule 10-50] (REF, EXT) (Interpretation)

An element appinfo:LocalTerm MUST establish the meaning of a local term only within the XML Schema document in which it occurs. There MUST NOT be any transitive inheritance of local terminology within schema documents that import the containing schema document.

Rule 10-51. Local terminology interpretation
[Rule 10-51] (REF, EXT) (Interpretation)

An element information item appinfo:LocalTerm MUST establish a term as follows:

  1. The value of the attribute term is the local term; it may occur as a term within the name of a schema component within the schema document.
  2. The value of the attribute literal is the meaning of the local term, provided as a full, plain-text form of the term. This may be useful when a local term is an abbreviation, acronym, or diminutive form of a longer term.
  3. The value of the attribute definition is a dictionary-style description of the meaning of the local term.
  4. The value of the attribute sourceURIs is a list of URIs, each of which is an identifier or locator for an originating or authoritative document defining the term.
  5. Each child element information item appinfo:SourceText is a plain text citation of, reference to, or bibliographic entry for an originating or authoritative document defining the term.
10.8.3. Word forms
Rule 10-52. Singular form is preferred in name
[Rule 10-52] (REF, EXT) (Constraint)

A noun used as a term in the name of an XML Schema component MUST be in singular form unless the concept itself is plural.

Rule 10-53. Present tense is preferred in name
[Rule 10-53] (REF, EXT) (Constraint)

A verb used as a term in the name of an XML Schema component MUST be used in the present tense unless the concept itself is past tense.

Rule 10-54. Name does not have nonessential words
[Rule 10-54] (REF, EXT) (Constraint)

Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.

Articles (e.g., a, an, the), conjunctions (e.g., and, or, but), and prepositions (e.g., at, by, for, from, in, of, to) are all disallowed in NIEM component names, unless they are required. For example, PowerOfAttorneyCode requires the preposition. These rules constrain slight variations in word forms and types to improve consistency and reduce potentially ambiguous or confusing component names.

Rule 10-55. Component name follows pattern

Elements in NIEM-conformant schemas are given names that follow a specific pattern. This pattern comes from [ISO 11179-5].

[Rule 10-55] (REF, EXT) (Constraint)

Except as specified elsewhere in this document, any element or attribute defined within the schema MUST have a name that takes the form:

  • Object-class qualifier terms (0 or more).
  • An object class term (1).
  • Property qualifier terms (0 or more).
  • A property term (1).
  • Representation qualifier terms (0 or more).
  • A representation term (0 or 1).

Consistent naming rules are helpful for users who wish to understand components with which they are unfamiliar, as well as for users to find components with known semantics. This rule establishes the basic structure for an element or attribute name, in line with the rules for names under [ISO 11179-5]. Note that many elements with complex type should not have a representation term.

10.8.4. Object-class term

NIEM adopts an object-oriented approach to representation of data. Object classes represent what [ISO 11179-5] refers to as things of interest in a universe of discourse that may be found in a model of that universe. An object class or object term is a word that represents a class of real-world entities or concepts. An object-class term describes the applicable context for a NIEM component.

Rule 10-56. Object-class term identifies concrete category
[Rule 10-56] (REF, EXT) (Constraint)

The object-class term of a NIEM component MUST consist of a term identifying a category of concrete concepts or entities.

The object-class term indicates the object category that this data component describes or represents. This term provides valuable context and narrows the scope of the component to an actual class of things or concepts.

Example:

Concept term: Activity

Entity term: Vehicle

10.8.5. Property term

Objects or concepts are usually described in terms of their characteristic properties, data attributes, or constituent subparts. Most objects can be described by several characteristics. Therefore, a property term in the name of a data component represents a characteristic or subpart of an object class and generally describes the essence of that data component.

Rule 10-57. Property term describes characteristic or subpart
[Rule 10-57] (REF, EXT) (Constraint)

A property term MUST describe or represent a characteristic or subpart of an entity or concept.

The property term describes the central meaning of the data component.

10.8.6. Qualifier terms

Qualifier terms modify object, property, representation, or other qualifier terms to increase semantic precision and reduce ambiguity. Qualifier terms may precede or succeed the terms they modify. The goal for the placement of qualifier terms is to generally follow the rules of ordinary English while maintaining clarity.

Rule 10-58. Name may have multiple qualifier terms
[Rule 10-58] (REF, EXT) (Constraint)

Multiple qualifier terms MAY be used within a component name as necessary to ensure clarity and uniqueness within its namespace and usage context.

Rule 10-59. Name has minimum necessary number of qualifier terms
[Rule 10-59] (REF, EXT) (Constraint)

The number of qualifier terms SHOULD be limited to the absolute minimum required to make the component name unique and understandable.

Rule 10-60. Order of qualifies is not significant
[Rule 10-60] (REF, EXT) (Constraint)

The order of qualifiers MUST NOT be used to differentiate names.

Very large vocabularies may have many similar and closely related properties and concepts. The use of object, property, and representation terms alone is often not sufficient to construct meaningful names that can uniquely distinguish such components. Qualifier terms provide additional context to resolve these subtleties. However, swapping the order of qualifiers rarely (if ever) changes meaning; qualifier ordering is no substitute for meaningful terms.

10.8.7. Representation terms

The representation terms for a component name serve several purposes in NIEM:

  1. It can indicate the style of component. For example, types are clearly labeled with the representation term Type.
  2. It helps prevent name conflicts and confusion. For example, elements and types may not be given the same name.
  3. It indicates the nature of the value carried by element. Labeling elements and attributes with a notional indicator of the content eases discovery and comprehension.
Rule 10-61. Redundant term in name is omitted
[Rule 10-61] (REF, EXT) (Constraint)

If any word in the representation term is redundant with any word in the property term, one occurrence SHOULD be deleted.

This rule, carried over from 11179, is designed to prevent repeating terms unnecessarily within component names. For example, this rule allows designers to avoid naming an element PersonFirstNameName.

The valid value set of a data element or value domain is described by the representation term. NIEM uses a standard set of representation terms in the representation portion of a NIEM-conformant component name. Table 10-2, Representation terms, below, lists the primary representation terms and a definition for the concept associated with the use of that term. The table also lists secondary representation terms that may represent more specific uses of the concept associated with the primary representation term.

Table 10-2: Representation terms
Primary Representation TermSecondary Representation TermDefinition
Amount-A number of monetary units specified in a currency where the unit of currency is explicit or implied.
BinaryObject-A set of finite-length sequences of binary octets.
GraphicA diagram, graph, mathematical curves, or similar representation
PictureA visual representation of a person, object, or scene
SoundA representation for audio
VideoA motion picture representation; may include audio encoded within
CodeA character string (i.e., letters, figures, and symbols) that for brevity, language independence, or precision represents a definitive value of an attribute.
DateTimeA particular point in the progression of time together with relevant supplementary information.
DateA particular day, month, and year in the Gregorian calendar.
TimeA particular point in the progression of time within an unspecified 24-hour day.
DurationAn amount of time; the length of a time span.
IDA character string to identify and distinguish uniquely one instance of an object in an identification scheme from all other objects in the same scheme together with relevant supplementary information.
URIA string of characters used to identify (or name) a resource. The main purpose of this identifier is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. A URI is either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The specific syntax for each is defined by [RFC 3986].
IndicatorA list of two mutually exclusive Boolean values that express the only possible states of a property.
MeasureA numeric value determined by measuring an object along with the specified unit of measure.
NumericNumeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure.
ValueA result of a calculation.
RateA representation of a ratio where the two units are not included.
PercentA representation of a ratio in which the two units are the same.
QuantityA counted number of nonmonetary units possibly including fractions.
Text-A character string (i.e., a finite sequence of characters) generally in the form of words of a language.
NameA word or phrase that constitutes the distinctive designation of a person, place, thing, or concept.
ListA sequence of values. This representation term is used in tandem with another of the listed representation terms.
AbstractAn element that may represent a concept, rather than a concrete property. This representation term may be used in tandem with another of the listed representation terms.
Rule 10-62. Element with simple content has representation term
[Rule 10-62] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of simple content MUST use an appropriate representation term as found in Table 10-2, Representation terms.

This rule is also supported by Rule 11-16, Name of element declaration with simple content has representation term (REF, EXT), below, and Rule 11-17, Name of element declaration with simple content has representation term (SET), below, which provide tests that a top-level declaration has a representation term.

Rule 10-63. Name has representation term when appropriate
[Rule 10-63] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of complex content, and that corresponds to a concept listed in Table 10-2, Representation terms, MUST use a representation term from that table.

An element that represents a value listed in the table should have a representation term. It should do so even if its type is complex with multiple parts. For example, a type with multiple fields may represent an audio binary, a date, or a name.

Rule 10-64. Name has representation term only when appropriate
[Rule 10-64] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of complex content and that does not correspond to a concept listed in Table 10-2, Representation terms MUST NOT use a representation term.

10.9. Machine-readable annotations

XML Schema provides application information schema components to provide for automatic processing and machine-readable content for schemas, as described by [XML Schema Structures] Section 3.13.2, XML Representation of Annotation Schema Components. NIEM utilizes application information to convey information that is outside schema definition and outside human-readable text definitions. NIEM uses application information to convey high-level data model concepts and additional syntax to support the NIEM conceptual model and validation of NIEM-conformant XML instances.

XML elements, attributes, and text content may appear as machine-readable annotations within an XML Schema document. The methods provided by XML Schema for machine-readable annotations are:

  1. An element in the XML Schema namespace (e.g., xs:schema, xs:complexType, …) may carry attributes from namespaces other than the XML Schema namespace. By the rules of XML Schema, any XML Schema element may have attributes that are from other namespaces. These attributes do not participate in XML Schema validation, but may carry information useful to tools that process schemas. In [XML Schema Structures], these attributes are described in the XML Representation summary of XML Schema elements as {any attributes with non-schema namespace . . .}, for example in Section 3.2.2, XML Representation of Attribute Declaration Schema Components.
  2. XML Schemas may include xs:appinfo elements, which may include arbitrary XML content. This XML does not participate in XML Schema validation, but may communicate useful information to schema readers or processors. These are described by [XML Schema Structures] in Section 3.13.1, The Annotation Schema Component and Section 3.13.2, XML Representation of Annotation Schema Components.

This document defines the term machine-readable annotation to normatively refer to such annotations within XML Schema documents:

[Definition: machine-readable annotation]

An information item within a schema is defined to be a machine-readable annotation when all of the following are true:

  1. It is one of the following:

    1. It is an element information item that is a child of an xs:appinfo element.
    2. It is an attribute information item that satisfies the {any attributes with non- schema namespace . . .} clause within the declaration of an XML Schema element.
  2. The namespace name property of the item is not the XML namespace, XML Schema namespace, or the XSI namespace.

Attributes from the XML namespace, the XML Schema namespace, and the XML Schema instance namespace have special meanings within XML Schema, and may have effects on validation, and so are not considered machine-readable annotations.

[Definition: application information]

A component is said to have application information of some element $element when the XML Schema element that defines the component has an immediate child element xs:annotation, which has an immediate child element xs:appinfo, which has as an immediate child the element $element.

If a component is described as having some application information, this means that the elements in question appear in an xs:appinfo annotation of the element that defines the component.

The majority of uses of application information from the appinfo namespace are described in the modeling rules for the specific component.

Rule 10-65. Machine-readable annotations are valid
[Rule 10-65] (REF, EXT) (Constraint)

Every element information item or attribute information item that appears as a machine-readable annotation in a schema MUST be a valid instance, according to its specification.

The specification for an element or attribute may be via an XML Schema, a Schematron schema, via a DTD, by some other specification, or by other means. This rule is intended to allow NIEM schema developers to leverage relevant vocabularies without being limited by the vocabulary’s method of specification, while ensuring that developers do not subvert or misuse those vocabularies.

10.9.1. The NIEM appinfo namespace

NIEM defines a single namespace that holds components for use in NIEM-conformant schema application information. This namespace is referred to as the appinfo namespace.

[Definition: appinfo namespace]

The appinfo namespace is the namespace represented by the URI http://release.niem.gov/niem/appinfo/4.0/.

The appinfo namespace defines attributes which provide additional semantics for components built by NIEM-conformant schemas. The XML Schema document for the appinfo namespace appears in Appendix C, Appinfo namespace, below.

10.9.1.1. Deprecation

The appinfo schema provides a construct for indicating that a construct is deprecated. A deprecated component is one whose use is not recommended. A deprecated component may be kept in a schema for support of older versions but should not be used in new efforts. A deprecated component may be removed, replaced, or renamed in a later version of a namespace.

[Definition: deprecated component]

A deprecated component is one that developers are discouraged from using, typically because a better alternative exists, yet which is maintained in the schema for compatibility with previous versions of the namespace.

The definition for deprecated component is adapted from [JLS] Section 9.6.4.6, @Deprecated.

Rule 10-66. Component marked as deprecated is deprecated component
[Rule 10-66] (REF, EXT) (Interpretation)

A schema component that has an attribute appinfo:deprecated with a value of true MUST be a deprecated component.

Deprecation can allow version management to be more consistent; versions of schema may be incrementally improved without introducing validation problems and incompatibility. As XML Schema lacks a deprecation mechanism, NIEM defines such a mechanism.

Rule 10-67. Deprecated annotates schema component
[Rule 10-67] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
[Definition: representation element declaration]

A representation element declaration is an element declaration that is abstract, and that has a {name} that ends in Representation.

Rule 10-44. A substitution for a representation element declaration is a value for a type
[Rule 10-44] (REF, EXT) (Interpretation)

Any element declaration that is substitutable for a representation element declaration represents an optional representation of a value of a type that carries the representation element.

10.8. Naming rules

This section outlines the rules used to create names for NIEM data components previously discussed in this document. Data component names must be understood easily both by humans and by machine processes. These rules improve name consistency by restricting characters, terms, and syntax that could otherwise allow too much variety and potential ambiguity. These rules also improve readability of names for humans, facilitate parsing of individual terms that compose names, and support various automated tasks associated with dictionary and controlled vocabulary maintenance.

Rule 10-45. Schema component name composed of English words
[Rule 10-45] (REF, EXT) (Constraint)

The name of any XML Schema component defined by the schema MUST be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED].

The English language has many spelling variations for the same word. For example, American English program has a corresponding British spelling programme. This variation has the potential to cause interoperability problems when XML components are exchanged because of the different names used by the same elements. Providing users with a dictionary standard for spelling will mitigate this potential interoperability issue.

Rule 10-46. Schema component names have only specific characters
[Rule 10-46] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:*[exists(@name)]">
+    <sch:assert test="matches(@name, '^[A-Za-z0-9\-_\.]*$')"
+      >The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period.</sch:assert>
+  </sch:rule>
+</sch:pattern>

Only the following characters are allowed in the name of an XML Schema component defined by the schema:

  • Upper-case letters (A–Z).
  • Lower-case letters (a–z).
  • Digits (0–9).
  • Underscore (_).
  • Hyphen (-).
  • Period (.).

Other characters, such as unicode characters outside the ASCII character set, are explicitly prohibited from the name of an XML Schema component defined by the schema.

Rule 10-47. Punctuation in component name is a separator
[Rule 10-47] (REF, EXT) (Constraint)

The characters hyphen (-), underscore (_) MAY appear in a component name only when used as a separator between parts of a word, phrase, or value, which would otherwise be incomprehensible without the use of a separator. The period character (.) MAY appear in component names only when appearing as a separator (as above) or as a decimal within a numeric value. A punctuation character MUST NOT be used as a substitute for camel case in component names, or as a method to avoid camel case in component names.

Names of standards and specifications, in particular, tend to consist of series of discrete numbers. Such names require some explicit separator to keep the values from running together. The separator used within NIEM is the hyphen.

Names of NIEM components follow the rules of XML Schema, by Rule 7-3, Document is a schema document (REF, EXT), above. NIEM components also follow the rules specified herein for each type of XML Schema component.

10.8.1. Character case

Names of conformant components use camel case formatting. Camel case is the convention of writing compound words or phrases with no spaces and an initial lowercase or uppercase letter, with each remaining word element beginning with an uppercase letter. UpperCamelCase is written with an initial uppercase letter, and lowerCamelCase is written with an initial lowercase letter.

Rule 10-48. Names use camel case
[Rule 10-48] (REF, EXT) (Constraint)

The name of any XML Schema component defined by the schema MUST use the camel case formatting convention.

Rule 10-49. Attribute name begins with lower case letter
[Rule 10-49] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:attribute[exists(@name)]">
+    <sch:assert test="matches(@name, '^[a-z]')"
+      >Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter
+      ('a'-'z').</sch:assert>
+  </sch:rule>
+</sch:pattern>
Rule 10-50. Name of schema component other than attribute and proxy type begins with upper case letter
[Rule 10-50] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:attribute">
+    <sch:report test="false()">This rule does not apply to an attribute.</sch:report>
+  </sch:rule>
+  <sch:rule context="xs:complexType[some $name in @name,
+                                    $extension in xs:simpleContent/xs:extension,
+                                    $base-qname in resolve-QName($extension/@base, $extension) satisfies
+                                    $base-qname = QName('http://www.w3.org/2001/XMLSchema', $name)]">
+    <sch:report test="false()">This rule does not apply to a proxy types.</sch:report>
+  </sch:rule>
+  <sch:rule context="xs:*[exists(@name)]">
+    <sch:assert test="matches(@name, '^[A-Z]')"
+      >Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z').</sch:assert>
+  </sch:rule>
+</sch:pattern>

The preceding rules establish lowerCamelCase for NIEM attributes, and UpperCamelCase for all other NIEM components, except proxy types, defined by Section 10.2.5, Proxy types, above.

10.8.2. Use of acronyms and abbreviations

Acronyms and abbreviations have the ability to improve readability and comprehensibility of large, complex, or frequently used terms. They also obscure meaning and impair understanding when their definitions are not clear or when they are used injudiciously. They should be used with great care. Acronyms and abbreviations that are used must be documented and used consistently.

Rule 10-51. Names use common abbreviations
[Rule 10-51] (REF, EXT) (Constraint)

The schema SHOULD use, in defined names, the abbreviations identified by Table 10-1, Abbreviations used in schema component names, rather than their full meanings.

Table 10-1: Abbreviations used in schema component names
AbbreviationFull Meaning
IDIdentifier
URIUniform Resource Identifier

Consistent, controlled, and documented abridged terms that are used frequently and/or tend to be lengthy can support readability, clarity, and reduction of name length.

10.8.2.1. Use of Acronyms, Initialisms, Abbreviations, and Jargon

The NDR establishes appinfo for local terminology that introduces such terms into the schema document in which the appinfo appears.

[Definition: local term]

In a conformant schema document, a local term is a word, phrase, acronym, or other string of characters for which all of the following are true:

  1. It is not a term defined in the [OED], or it has a non-OED definition, or its word sense may not be clear.
  2. It is introduced into the schema document via an appinfo element appinfo:LocalTerm.
  3. It is used in the local name of a schema component within the schema document.

Local terminology is introduced into a schema document by the use of appinfo:LocalTerm within the schema.

See additional rules constraining the use of local terminology in Section 10.9.2, Local terminology, below.

Rule 10-52. Local term declaration is local to its schema document
[Rule 10-52] (REF, EXT) (Interpretation)

An element appinfo:LocalTerm MUST establish the meaning of a local term only within the XML Schema document in which it occurs. There MUST NOT be any transitive inheritance of local terminology within schema documents that import the containing schema document.

Rule 10-53. Local terminology interpretation
[Rule 10-53] (REF, EXT) (Interpretation)

An element information item appinfo:LocalTerm MUST establish a term as follows:

  1. The value of the attribute term is the local term; it may occur as a term within the name of a schema component within the schema document.
  2. The value of the attribute literal is the meaning of the local term, provided as a full, plain-text form of the term. This may be useful when a local term is an abbreviation, acronym, or diminutive form of a longer term.
  3. The value of the attribute definition is a dictionary-style description of the meaning of the local term.
  4. The value of the attribute sourceURIs is a list of URIs, each of which is an identifier or locator for an originating or authoritative document defining the term.
  5. Each child element information item appinfo:SourceText is a plain text citation of, reference to, or bibliographic entry for an originating or authoritative document defining the term.
10.8.3. Word forms
Rule 10-54. Singular form is preferred in name
[Rule 10-54] (REF, EXT) (Constraint)

A noun used as a term in the name of an XML Schema component MUST be in singular form unless the concept itself is plural.

Rule 10-55. Present tense is preferred in name
[Rule 10-55] (REF, EXT) (Constraint)

A verb used as a term in the name of an XML Schema component MUST be used in the present tense unless the concept itself is past tense.

Rule 10-56. Name does not have nonessential words
[Rule 10-56] (REF, EXT) (Constraint)

Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.

Articles (e.g., a, an, the), conjunctions (e.g., and, or, but), and prepositions (e.g., at, by, for, from, in, of, to) are all disallowed in NIEM component names, unless they are required. For example, PowerOfAttorneyCode requires the preposition. These rules constrain slight variations in word forms and types to improve consistency and reduce potentially ambiguous or confusing component names.

Rule 10-57. Component name follows pattern

Elements in NIEM-conformant schemas are given names that follow a specific pattern. This pattern comes from [ISO 11179-5].

[Rule 10-57] (REF, EXT) (Constraint)

Except as specified elsewhere in this document, any element or attribute defined within the schema SHOULD have a name that takes the form:

  • Object-class qualifier terms (0 or more).
  • An object class term (1).
  • Property qualifier terms (0 or more).
  • A property term (1).
  • Representation qualifier terms (0 or more).
  • A representation term (0 or 1).

Consistent naming rules are helpful for users who wish to understand components with which they are unfamiliar, as well as for users to find components with known semantics. This rule establishes the basic structure for an element or attribute name, in line with the rules for names under [ISO 11179-5]. Note that many elements with complex type should not have a representation term.

10.8.4. Object-class term

NIEM adopts an object-oriented approach to representation of data. Object classes represent what [ISO 11179-5] refers to as things of interest in a universe of discourse that may be found in a model of that universe. An object class or object term is a word that represents a class of real-world entities or concepts. An object-class term describes the applicable context for a NIEM component.

Rule 10-58. Object-class term identifies concrete category
[Rule 10-58] (REF, EXT) (Constraint)

The object-class term of a NIEM component MUST consist of a term identifying a category of concrete concepts or entities.

The object-class term indicates the object category that this data component describes or represents. This term provides valuable context and narrows the scope of the component to an actual class of things or concepts.

Example:

Concept term: Activity

Entity term: Vehicle

10.8.5. Property term

Objects or concepts are usually described in terms of their characteristic properties, data attributes, or constituent subparts. Most objects can be described by several characteristics. Therefore, a property term in the name of a data component represents a characteristic or subpart of an object class and generally describes the essence of that data component.

Rule 10-59. Property term describes characteristic or subpart
[Rule 10-59] (REF, EXT) (Constraint)

A property term MUST describe or represent a characteristic or subpart of an entity or concept.

The property term describes the central meaning of the data component.

10.8.6. Qualifier terms

Qualifier terms modify object, property, representation, or other qualifier terms to increase semantic precision and reduce ambiguity. Qualifier terms may precede or succeed the terms they modify. The goal for the placement of qualifier terms is to generally follow the rules of ordinary English while maintaining clarity.

Rule 10-60. Name may have multiple qualifier terms
[Rule 10-60] (REF, EXT) (Constraint)

Multiple qualifier terms MAY be used within a component name as necessary to ensure clarity and uniqueness within its namespace and usage context.

Rule 10-61. Name has minimum necessary number of qualifier terms
[Rule 10-61] (REF, EXT) (Constraint)

The number of qualifier terms SHOULD be limited to the absolute minimum required to make the component name unique and understandable.

Rule 10-62. Order of qualifies is not significant
[Rule 10-62] (REF, EXT) (Constraint)

The order of qualifiers MUST NOT be used to differentiate names.

Very large vocabularies may have many similar and closely related properties and concepts. The use of object, property, and representation terms alone is often not sufficient to construct meaningful names that can uniquely distinguish such components. Qualifier terms provide additional context to resolve these subtleties. However, swapping the order of qualifiers rarely (if ever) changes meaning; qualifier ordering is no substitute for meaningful terms.

10.8.7. Representation terms

The representation terms for a component name serve several purposes in NIEM:

  1. It can indicate the style of component. For example, types are clearly labeled with the representation term Type.
  2. It helps prevent name conflicts and confusion. For example, elements and types may not be given the same name.
  3. It indicates the nature of the value carried by element. Labeling elements and attributes with a notional indicator of the content eases discovery and comprehension.
Rule 10-63. Redundant term in name is omitted
[Rule 10-63] (REF, EXT) (Constraint)

If any word in the representation term is redundant with any word in the property term, one occurrence SHOULD be deleted.

This rule, carried over from 11179, is designed to prevent repeating terms unnecessarily within component names. For example, this rule allows designers to avoid naming an element PersonFirstNameName.

The valid value set of a data element or value domain is described by the representation term. NIEM uses a standard set of representation terms in the representation portion of a NIEM-conformant component name. Table 10-2, Representation terms, below, lists the primary representation terms and a definition for the concept associated with the use of that term. The table also lists secondary representation terms that may represent more specific uses of the concept associated with the primary representation term.

Table 10-2: Representation terms
Primary Representation TermSecondary Representation TermDefinition
Amount-A number of monetary units specified in a currency where the unit of currency is explicit or implied.
BinaryObject-A set of finite-length sequences of binary octets.
GraphicA diagram, graph, mathematical curves, or similar representation
PictureA visual representation of a person, object, or scene
SoundA representation for audio
VideoA motion picture representation; may include audio encoded within
CodeA character string (i.e., letters, figures, and symbols) that for brevity, language independence, or precision represents a definitive value of an attribute.
DateTimeA particular point in the progression of time together with relevant supplementary information.
DateA particular day, month, and year in the Gregorian calendar.
TimeA particular point in the progression of time within an unspecified 24-hour day.
DurationAn amount of time; the length of a time span.
IDA character string to identify and distinguish uniquely one instance of an object in an identification scheme from all other objects in the same scheme together with relevant supplementary information.
URIA string of characters used to identify (or name) a resource. The main purpose of this identifier is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. A URI is either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The specific syntax for each is defined by [RFC 3986].
IndicatorA list of two mutually exclusive Boolean values that express the only possible states of a property.
MeasureA numeric value determined by measuring an object along with the specified unit of measure.
NumericNumeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure.
ValueA result of a calculation.
RateA representation of a ratio where the two units are not included.
PercentA representation of a ratio in which the two units are the same.
QuantityA counted number of non-monetary units possibly including fractions.
Text-A character string (i.e., a finite sequence of characters) generally in the form of words of a language.
NameA word or phrase that constitutes the distinctive designation of a person, place, thing, or concept.
ListA sequence of values. This representation term is used in tandem with another of the listed representation terms.
AbstractAn element that may represent a concept, rather than a concrete property. This representation term may be used in tandem with another of the listed representation terms.
Rule 10-64. Element with simple content has representation term
[Rule 10-64] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of simple content SHOULD use an appropriate representation term as found in Table 10-2, Representation terms.

This rule is also supported by Rule 11-14, Name of element declaration with simple content has representation term (REF, EXT), below, and Rule 11-15, Name of element declaration with simple content has representation term (SET), below, which provide tests that a top-level declaration has a representation term.

Rule 10-65. Name has representation term when appropriate
[Rule 10-65] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of complex content, and that corresponds to a concept listed in Table 10-2, Representation terms, SHOULD use a representation term from that table.

An element that represents a value listed in the table should have a representation term. It should do so even if its type is complex with multiple parts. For example, a type with multiple fields may represent an audio binary, a date, or a name.

Rule 10-66. Name has representation term only when appropriate
[Rule 10-66] (REF, EXT) (Constraint)

Within the schema, the name of an element declaration that is of complex content and that does not correspond to a concept listed in Table 10-2, Representation terms SHOULD NOT use a representation term.

10.9. Machine-readable annotations

XML Schema provides application information schema components to provide for automatic processing and machine-readable content for schemas, as described by [XML Schema Structures] Section 3.13.2, XML Representation of Annotation Schema Components. NIEM utilizes application information to convey information that is outside schema definition and outside human-readable text definitions. NIEM uses application information to convey high-level data model concepts and additional syntax to support the NIEM conceptual model and validation of NIEM-conformant XML instances.

XML elements, attributes, and text content may appear as machine-readable annotations within an XML Schema document. The methods provided by XML Schema for machine-readable annotations are:

  1. An element in the XML Schema namespace (e.g., xs:schema, xs:complexType, …) may carry attributes from namespaces other than the XML Schema namespace. By the rules of XML Schema, any XML Schema element may have attributes that are from other namespaces. These attributes do not participate in XML Schema validation, but may carry information useful to tools that process schemas. In [XML Schema Structures], these attributes are described in the XML Representation summary of XML Schema elements as {any attributes with non-schema namespace . . .}, for example in Section 3.2.2, XML Representation of Attribute Declaration Schema Components.
  2. XML Schemas may include xs:appinfo elements, which may include arbitrary XML content. This XML does not participate in XML Schema validation, but may communicate useful information to schema readers or processors. These are described by [XML Schema Structures] in Section 3.13.1, The Annotation Schema Component and Section 3.13.2, XML Representation of Annotation Schema Components.

This document defines the term machine-readable annotation to normatively refer to such annotations within XML Schema documents:

[Definition: machine-readable annotation]

An information item within a schema is defined to be a machine-readable annotation when all of the following are true:

  1. It is one of the following:

    1. It is an element information item that is a child of an xs:appinfo element.
    2. It is an attribute information item that satisfies the {any attributes with non- schema namespace . . .} clause within the declaration of an XML Schema element.
  2. The namespace name property of the item is not the XML namespace, XML Schema namespace, or the XSI namespace.

Attributes from the XML namespace, the XML Schema namespace, and the XML Schema instance namespace have special meanings within XML Schema, and may have effects on validation, and so are not considered machine-readable annotations.

[Definition: application information]

A component is said to have application information of some element $element when the XML Schema element that defines the component has an immediate child element xs:annotation, which has an immediate child element xs:appinfo, which has as an immediate child the element $element.

If a component is described as having some application information, this means that the elements in question appear in an xs:appinfo annotation of the element that defines the component.

The majority of uses of application information from the appinfo namespace are described in the modeling rules for the specific component.

Rule 10-67. Machine-readable annotations are valid
[Rule 10-67] (REF, EXT) (Constraint)

Every element information item or attribute information item that appears as a machine-readable annotation in a schema MUST be a valid instance, according to its specification.

The specification for an element or attribute may be via an XML Schema, a Schematron schema, via a DTD, by some other specification, or by other means. This rule is intended to allow NIEM schema developers to leverage relevant vocabularies without being limited by the vocabulary’s method of specification, while ensuring that developers do not subvert or misuse those vocabularies.

10.9.1. The NIEM appinfo namespace

NIEM defines a single namespace that holds components for use in NIEM-conformant schema application information. This namespace is referred to as the appinfo namespace.

[Definition: appinfo namespace]

The appinfo namespace is the namespace represented by the URI http://release.niem.gov/niem/appinfo/4.0/.

The appinfo namespace defines attributes which provide additional semantics for components built by NIEM-conformant schemas. The XML Schema document for the appinfo namespace appears in Appendix C, Appinfo namespace, below.

10.9.1.1. Deprecation

The appinfo schema provides a construct for indicating that a construct is deprecated. A deprecated component is one whose use is not recommended. A deprecated component may be kept in a schema for support of older versions but should not be used in new efforts. A deprecated component may be removed, replaced, or renamed in a later version of a namespace.

[Definition: deprecated component]

A deprecated component is one that developers are discouraged from using, typically because a better alternative exists, yet which is maintained in the schema for compatibility with previous versions of the namespace.

The definition for deprecated component is adapted from [JLS] Section 9.6.4.6, @Deprecated.

Rule 10-68. Component marked as deprecated is deprecated component
[Rule 10-68] (REF, EXT) (Interpretation)

A schema component that has an attribute appinfo:deprecated with a value of true MUST be a deprecated component.

Deprecation can allow version management to be more consistent; versions of schema may be incrementally improved without introducing validation problems and incompatibility. As XML Schema lacks a deprecation mechanism, NIEM defines such a mechanism.

Rule 10-69. Deprecated annotates schema component
[Rule 10-69] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:deprecated)]">
     <sch:assert test="namespace-uri-from-QName(node-name(.)) = xs:anyURI('http://www.w3.org/2001/XMLSchema')"
             >The attribute appinfo:deprecated MUST be owned by an element with a namespace name <namespace-uri-for-prefix>xs</namespace-uri-for-prefix>.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-68. External import indicator annotates import
[Rule 10-68] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-70. External import indicator annotates import
[Rule 10-70] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:externalImportIndicator)]">
     <sch:assert test="exists(self::xs:import)"
         >The attribute {http://release.niem.gov/niem/appinfo/4.0/}externalImportIndicator MUST be owned by an element xs:import.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-69. External adapter type indicator annotates complex type
[Rule 10-69] (REF) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-71. External adapter type indicator annotates complex type
[Rule 10-71] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:externalAdapterTypeIndicator)]">
     <sch:assert test="exists(self::xs:complexType)"
             >The attribute appinfo:externalAdapterTypeIndicator MUST be owned by an element xs:complexType.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.9.1.2. appinfo:appliesToTypes annotation
Rule 10-70. appinfo:appliesToTypes annotates metadata element
[Rule 10-70] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.9.1.2. appinfo:appliesToTypes annotation
Rule 10-72. appinfo:appliesToTypes annotates metadata element
[Rule 10-72] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:appliesToTypes)]">
     <sch:assert test="exists(self::xs:element[exists(@name)
                                and ends-with(@name, 'Metadata')])"
       >The attribute appinfo:appliesToTypes MUST be owned by a metadata element.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-71. appinfo:appliesToTypes references types
[Rule 10-71] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-73. appinfo:appliesToTypes references types
[Rule 10-73] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:appliesToTypes)]">
     <sch:assert test="every $item in tokenize(normalize-space(@appinfo:appliesToTypes), ' ') satisfies
                         exists(nf:resolve-type(., resolve-QName($item, .)))"
       >Every item in @appinfo:appliesToTypes MUST resolve to a type.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.9.1.3. appinfo:appliesToElements annotation
Rule 10-72. appinfo:appliesToElements annotates metadata element
[Rule 10-72] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.9.1.3. appinfo:appliesToElements annotation
Rule 10-74. appinfo:appliesToElements annotates metadata element
[Rule 10-74] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:appliesToElements)]">
     <sch:assert test="exists(self::xs:element[
                           exists(@name)
                           and ends-with(@name, 'Metadata')])"
             >The attribute appinfo:appliesToElements MUST be owned by a metadata element.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 10-73. appinfo:appliesToElements references elements
[Rule 10-73] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 10-75. appinfo:appliesToElements references elements
[Rule 10-75] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@appinfo:appliesToElements)]">
     <sch:assert test="every $item in tokenize(normalize-space(@appinfo:appliesToElements), ' ') satisfies
                         count(nf:resolve-element(., resolve-QName($item, .))) = 1"
       >Every item in @appinfo:appliesToElements MUST resolve to an element.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.9.2. Local terminology
Rule 10-74. appinfo:LocalTerm annotates schema
[Rule 10-74] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.9.2. Local terminology
Rule 10-76. appinfo:LocalTerm annotates schema
[Rule 10-76] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="appinfo:LocalTerm">
     <sch:assert test="parent::xs:appinfo[parent::xs:annotation[parent::xs:schema]]"
       >The element appinfo:LocalTerm MUST be application information on an element xs:schema.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term application information.

Rule 10-75. appinfo:LocalTerm has literal or definition
[Rule 10-75] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term application information.

Rule 10-77. appinfo:LocalTerm has literal or definition
[Rule 10-77] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="appinfo:LocalTerm">
     <sch:assert test="exists(@literal) or exists(@definition)"
             >The element {http://release.niem.gov/niem/appinfo/4.0/}LocalTerm MUST have a literal or definition.</sch:assert>
   </sch:rule>
-</sch:pattern>
10.10. NIEM structural facilities

NIEM provides the structures schema that contains base types for types defined in NIEM- conformant schemas. It provides base elements to act as heads for substitution groups. It also provides attributes that provide facilities not otherwise provided by XML Schema. These structures should be used to augment XML data. The structures provided are not meant to replace fundamental XML organization methods; they are intended to assist them.

[Definition: structures namespace]

The structures namespace is the namespace represented by the URI http://release.niem.gov/niem/structures/4.0/.

The structures namespace is a single namespace, separate from namespaces that define NIEM-conformant data. This document refers to this content via the prefix structures.

Rule 10-76. Use structures as specified
[Rule 10-76] (REF, EXT, INS) (Constraint)

The schema or instance MUST use content within the NIEM structures namespace as specified in this document and ONLY as specified by this document.

This rule further enforces uniformity and consistency by mandating use of the NIEM structures namespace as is, without modification. Users are not allowed to insert types, attributes, etc. that are not specified by this document.

11. Rules for NIEM modeling, by XML Schema component

This section focuses on building NIEM data models using XML schema. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.

11.1. Type definition components
Rule 11-1. Name of type ends in Type
[Rule 11-1] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
10.10. NIEM structural facilities

NIEM provides the structures schema that contains base types for types defined in NIEM- conformant schemas. It provides base elements to act as heads for substitution groups. It also provides attributes that provide facilities not otherwise provided by XML Schema. These structures should be used to augment XML data. The structures provided are not meant to replace fundamental XML organization methods; they are intended to assist them.

[Definition: structures namespace]

The structures namespace is the namespace represented by the URI http://release.niem.gov/niem/structures/4.0/.

The structures namespace is a single namespace, separate from namespaces that define NIEM-conformant data. This document refers to this content via the prefix structures.

Rule 10-78. Use structures as specified
[Rule 10-78] (REF, EXT, INS) (Constraint)

The schema or instance MUST use content within the NIEM structures namespace as specified in this document and ONLY as specified by this document.

This rule further enforces uniformity and consistency by mandating use of the NIEM structures namespace as is, without modification. Users are not allowed to insert types, attributes, etc. that are not specified by this document.

11. Rules for NIEM modeling, by XML Schema component

This section focuses on building NIEM data models using XML schema. Whereas Section 9, Rules for a NIEM profile of XML Schema, above, addressed shrinking the XML Schema definition language to a smaller set of features, this section constructs new NIEM-specific features to address modeling and interoperability problems. This includes naming rules, categories of types, and augmentations.

11.1. Type definition components
Rule 11-1. Name of type ends in Type
[Rule 11-1] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[some $name in @name,
                                     $extension in xs:simpleContent/xs:extension,
                                     $base-qname in resolve-QName($extension/@base, $extension) satisfies
@@ -1110,18 +1099,7 @@
     <sch:assert test="ends-with(@name, 'Type')"
       >A type definition schema component that does not define a proxy type MUST have a name that ends in "Type".</sch:assert>
   </sch:rule>
-</sch:pattern>

Use of the representation term Type immediately identifies XML types in a NIEM-conformant schema and prevents naming collisions with corresponding XML elements and attributes. The exception for proxy types ensures that simple NIEM-compatible uses of base XML Schema types are familiar to people with XML Schema experience.

Note that the first sch:rule and subsequent sch:report serve to provide an exception to the rule for proxy types. It does not establish a constraint on the data.

Rule 11-2. Name of type other than proxy type is in upper camel case
[Rule 11-2] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:complexType[some $name in @name,
-                                    $extension in xs:simpleContent/xs:extension,
-                                    $base-qname in resolve-QName($extension/@base, $extension) satisfies
-                                    $base-qname = QName('http://www.w3.org/2001/XMLSchema', $name)]">
-    <sch:report test="false()">The name of a proxy type is not upper camel case.</sch:report>
-  </sch:rule>
-  <sch:rule context="xs:*[(self::xs:simpleType or self::xs:complexType) and exists(@name)]">
-    <sch:assert test="matches(@name, '^([A-Z][A-Za-z0-9\-]*)+$')"
-      >A type definition schema component that does not define a proxy type MUST be in upper camel case.</sch:assert>
-  </sch:rule>
-</sch:pattern>

Note that the first sch:rule and q subsequent sch:report (with @test-="false()") serve to provide an exception to this rule for proxy types. It does not establish a constraint on the data.

11.1.1. Type definition hierarchy
Rule 11-3. Base type definition defined by conformant schema
[Rule 11-3] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Use of the representation term Type immediately identifies XML types in a NIEM-conformant schema and prevents naming collisions with corresponding XML elements and attributes. The exception for proxy types ensures that simple NIEM-compatible uses of base XML Schema types are familiar to people with XML Schema experience.

Note that the first sch:rule and subsequent sch:report serve to provide an exception to the rule for proxy types. It does not establish a constraint on the data.

11.1.1. Type definition hierarchy
Rule 11-2. Base type definition defined by conformant schema
[Rule 11-2] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:*[exists(@base)]">
     <sch:assert test="some $base-namespace in namespace-uri-from-QName(resolve-QName(@base, .)) satisfies (
                         $base-namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
@@ -1130,17 +1108,12 @@
                                                                    and empty(@appinfo:externalImportIndicator)]))"
       >The {base type definition} of a type definition MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.1.2. Simple type definition
Rule 11-4. Name of simple type ends in SimpleType
[Rule 11-4] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.1.2. Simple type definition
Rule 11-3. Name of simple type ends in SimpleType
[Rule 11-3] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:simpleType[@name]">
     <sch:assert test="ends-with(@name, 'SimpleType')"
       >A simple type definition schema component MUST have a name that ends in "SimpleType".</sch:assert>
   </sch:rule>
-</sch:pattern>

Specific uses of type definitions have similar syntax but very different effects on data definitions. Schemas that clearly identify complex and simple type definitions are easier to understand without tool support. This rule ensures that names of simple types end in SimpleType.

Rule 11-5. Name of simple type is upper camel case
[Rule 11-5] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:simpleType[exists(@name)]">
-    <sch:assert test="matches(string(@name), '^([A-Z][A-Za-z0-9\-]*)+$')"
-      >The name of a simple type definition schema component MUST be upper camel case.</sch:assert>
-  </sch:rule>
-</sch:pattern>
11.1.2.1. Derivation by list
Rule 11-6. Use lists only when data is uniform
[Rule 11-6] (REF, EXT) (Constraint)

Within the schema, a simple type definition that uses xs:list SHOULD NOT be defined if any member of the list requires a property or metadata that is different than other members of the list. All members of the list SHOULD have the same metadata, and should be related via the same properties.

The use of lists should be reserved for cases where the data is fairly uniform.

Items in a list are not individually addressable by NIEM metadata techniques. The items are also not individually referencable by elements or attributes; one will have a value of the entire list, including all the items in the list. NIEM provides no method for individually addressing an item in a list. If an individual item in a list needs to be marked up in a manner different than other items in the list, the use of individual elements may be preferred to the definition of a list simple type.

Rule 11-7. List item type defined by conformant schemas
[Rule 11-7] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Specific uses of type definitions have similar syntax but very different effects on data definitions. Schemas that clearly identify complex and simple type definitions are easier to understand without tool support. This rule ensures that names of simple types end in SimpleType.

11.1.2.1. Derivation by list
Rule 11-4. Use lists only when data is uniform
[Rule 11-4] (REF, EXT) (Constraint)

Within the schema, a simple type definition that uses xs:list SHOULD NOT be defined if any member of the list requires a property or metadata that is different than other members of the list. All members of the list SHOULD have the same metadata, and should be related via the same properties.

The use of lists should be reserved for cases where the data is fairly uniform.

Items in a list are not individually addressable by NIEM metadata techniques. The items may not be individually referenced by elements or attributes; one will have a value of the entire list, including all the items in the list. NIEM provides no method for individually addressing an item in a list. If an individual item in a list needs to be marked up in a manner different than other items in the list, the use of individual elements may be preferred to the definition of a list simple type.

Rule 11-5. List item type defined by conformant schemas
[Rule 11-5] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:list[exists(@itemType)]">
     <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@itemType, .))"/>
     <sch:assert test="$namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
@@ -1149,7 +1122,7 @@
                                     and empty(@appinfo:externalImportIndicator)])"
       >The item type of a list simple type definition MUST have a target namespace equal to the target namespace of the XML Schema document within which it is defined, or a namespace that is imported as conformant by the schema document within which it is defined.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.1.2.2. Derivation by union
Rule 11-8. Union member types defined by conformant schemas
[Rule 11-8] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.1.2.2. Derivation by union
Rule 11-6. Union member types defined by conformant schemas
[Rule 11-6] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:union[exists(@memberTypes)]">
     <sch:assert test="every $qname in tokenize(normalize-space(@memberTypes), ' '),
                             $namespace in namespace-uri-from-QName(resolve-QName($qname, .))
@@ -1159,24 +1132,19 @@
                                            and empty(@appinfo:externalImportIndicator)]))"
                 >Every member type of a union simple type definition MUST have a target namespace that is equal to either the target namespace of the XML Schema document within which it is defined or a namespace that is imported as conformant by the schema document within which it is defined.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.1.2.3. Code simple types
[Definition: code simple type]

A code simple type is a simple type definition schema component that is constrained by one or more enumeration facets.

These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.

Rule 11-9. Name of a code simple type has standard suffix
[Rule 11-9] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.1.2.3. Code simple types
[Definition: code simple type]

A code simple type is a simple type definition schema component for which each value carried by the type corresponds to an entry in a list of distinct conceptual entities.

These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals.

Many code simple types are composed of xs:enumeration values. Code simple types may also be constructed using the NIEM Code Lists Specification [Code Lists], which supports code lists defined using a variety of methods, including CSV spreadsheets.

Rule 11-7. Name of a code simple type has standard suffix
[Rule 11-7] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:simpleType[exists(@name)
       and (xs:restriction/xs:enumeration
            or xs:restriction[ends-with(local-name-from-QName(resolve-QName(@base, .)), 'CodeSimpleType')])]">
-    <sch:assert test="ends-with(@name, 'CodeSimpleType')"
-      >A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType".</sch:assert>
-  </sch:rule>
-</sch:pattern>
Rule 11-10. Code simple type has enumerations
[Rule 11-10] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:simpleType[exists(@name) and ends-with(@name, 'CodeSimpleType')]">
-    <sch:assert test="xs:restriction[ends-with(local-name-from-QName(resolve-QName(@base, .)), 'CodeSimpleType')]
-                      or xs:restriction/xs:enumeration
-                      or (for $union in xs:union,
-                             $member-types in $union/@memberTypes return
-                           some $member-type in tokenize(normalize-space($member-types), ' ') satisfies
-                             ends-with(local-name-from-QName(resolve-QName($member-type, $union)), 'CodeSimpleType'))"
-      >A code simple type MUST be derived from a code simple type or have an enumeration facet.</sch:assert>
-  </sch:rule>
-</sch:pattern>

Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.

11.1.3. Complex type definition
Rule 11-11. Complex type with simple content has structures:SimpleObjectAttributeGroup

Within a reference schema document, a complex type with simple content can be created in one of two ways:

  1. By extension of an existing complex type with simple content.
  2. By extension of an existing simple type.

Both of these methods use the element xs:extension. Although these two methods have similar syntax, there are subtle differences. NIEM’s conformance rules ensure that any complex type has the necessary attributes for representing IDs, references, metadata, and relationship metadata. Case 1 does not require adding these attributes, as they are guaranteed to occur in the base type. However, in case 2, in which a new complex type is created from a simple type, the attributes for complex types must be added. This is done by reference to the attribute group structures:SimpleObjectAttributeGroup.

[Rule 11-11] (REF, EXT) (Constraint)
<sch:pattern>
+    <sch:report test="not(ends-with(@name, 'CodeSimpleType'))"
+      >A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType".</sch:report>
+  </sch:rule>
+</sch:pattern>
Rule 11-8. Code simple type corresponds to a code list
[Rule 11-8] (REF, EXT) (Constraint)

A simple type SHOULD have a name ending in CodeSimpleType if and only if it has a correspondence to a list of distinct conceptual entities.

Rule 11-9. Attribute of code simple type has code representation term
[Rule 11-9] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:attribute[exists(@name) and exists(@type) and ends-with(@type, 'CodeSimpleType')]">
+    <sch:report test="not(ends-with(@name, 'Code'))"
+      >An attribute with a type that is a code simple type SHOULD have a name with representation term "Code"</sch:report>
+  </sch:rule>
+</sch:pattern>

Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies that a data component may carry values from a fixed list of codes. Such a component may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values.

11.1.3. Complex type definition
Rule 11-10. Complex type with simple content has structures:SimpleObjectAttributeGroup

Within a reference schema document, a complex type with simple content can be created in one of two ways:

  1. By extension of an existing complex type with simple content.
  2. By extension of an existing simple type.

Both of these methods use the element xs:extension. Although these two methods have similar syntax, there are subtle differences. NIEM’s conformance rules ensure that any complex type has the necessary attributes for representing IDs, references, metadata, and relationship metadata. Case 1 does not require adding these attributes, as they are guaranteed to occur in the base type. However, in case 2, in which a new complex type is created from a simple type, the attributes for complex types must be added. This is done by reference to the attribute group structures:SimpleObjectAttributeGroup.

[Rule 11-10] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:simpleContent/xs:extension[
       some $base-qname in resolve-QName(@base, .) satisfies
         namespace-uri-from-QName($base-qname) = xs:anyURI('http://www.w3.org/2001/XMLSchema')
@@ -1194,17 +1162,12 @@
         <xs:attributeGroup ref="structures:SimpleObjectAttributeGroup"/>
       </xs:extension>
     </xs:simpleContent>
-  </xs:complexType>
11.2. Declaration components
11.2.1. Element declaration
Rule 11-12. Element name is upper camel case
[Rule 11-12] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:element[exists(@name)]">
-    <sch:assert test="matches(string(@name), '^([A-Z][A-Za-z0-9\-]*)+$')"
-                >The name of an element declaration MUST be upper camel case.</sch:assert>
-  </sch:rule>
-</sch:pattern>

This document defines the term element declaration.

Rule 11-13. Element type does not have a simple type name
[Rule 11-13] (REF, EXT) (Constraint)
<sch:pattern>
+  </xs:complexType>
11.2. Declaration components
11.2.1. Element declaration
Rule 11-11. Element type does not have a simple type name
[Rule 11-11] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@type)]">
     <sch:assert test="not(ends-with(@type, 'SimpleType'))"
                 >The {type definition} of an element declaration MUST NOT have a {name} that ends in 'SimpleType'.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term element declaration.

Rule 11-14. Element type is from conformant namespace
[Rule 11-14] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term element declaration.

Rule 11-12. Element type is from conformant namespace
[Rule 11-12] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@type)]">
     <sch:assert test="for $type-qname in resolve-QName(@type, .),
                           $type-namespace in namespace-uri-from-QName($type-qname) return
@@ -1214,32 +1177,34 @@
                                     and empty(@appinfo:externalImportIndicator)])"
                 >The {type definition} of an element declaration MUST have a {target namespace} that is the target namespace, or one that is imported as conformant.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term element declaration.

Additional prohibitions on element types are defined by Rule 9-40, Element type not in the XML namespace (REF, EXT), above, and Rule 9-41, Element type is not simple type (REF, EXT), above.

Rule 11-15. Name of element that ends in Abstract is abstract
[Rule 11-15] (REF, EXT) (Constraint)
<sch:pattern>
-  <sch:rule context="xs:element[@name[ends-with(., 'Abstract')]]">
-    <sch:assert test="exists(@abstract) and xs:boolean(@abstract) = true()"
-      >An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true".</sch:assert>
+</sch:pattern>

This document defines the term element declaration.

Additional prohibitions on element types are defined by Rule 9-41, Element type not in the XML namespace (REF, EXT), above, and Rule 9-42, Element type is not simple type (REF, EXT), above.

Rule 11-13. Name of element that ends in Abstract is abstract
[Rule 11-13] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[@name]">
+    <sch:report test="not(exists(@abstract[xs:boolean(.) = true()]) 
+                          eq (ends-with(@name, 'Abstract') 
+                              or ends-with(@name, 'AugmentationPoint')
+                              or ends-with(@name, 'Representation')))">An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true".</sch:report>
   </sch:rule>
-</sch:pattern>
11.2.1.1. Object element declarations

This rule checks all cases that are testable in a single schema document.

Rule 11-16. Name of element declaration with simple content has representation term
[Rule 11-16] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.2.1.1. Object element declarations

This rule checks all cases that are testable in a single schema document.

Rule 11-14. Name of element declaration with simple content has representation term
[Rule 11-14] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[@name and @type
                                 and (some $type-qname in resolve-QName(@type, .) satisfies (
                                        nf:get-target-namespace(.) = namespace-uri-from-QName($type-qname)
                                        and nf:resolve-type(., $type-qname)/xs:simpleContent))]">
-    <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                        ends-with(@name, $representation-term)"
-      >The name of an element declaration that is of simple content MUST use a representation term.</sch:assert>
+    <sch:report test="every $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
+                            not(ends-with(@name, $representation-term))"
+      >The name of an element declaration that is of simple content SHOULD use a representation term.</sch:report>
   </sch:rule>
-</sch:pattern>

Representation terms are defined by Table 10-2, Representation terms, above. This Schematron rule supports Rule 10-62, Element with simple content has representation term (REF, EXT), above.

Rule 11-17. Name of element declaration with simple content has representation term

This rule only checks the cases not testable in the (REF, EXT) version.

[Rule 11-17] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>

Representation terms are defined by Table 10-2, Representation terms, above. This Schematron rule supports Rule 10-64, Element with simple content has representation term (REF, EXT), above.

Rule 11-15. Name of element declaration with simple content has representation term

This rule only checks the cases not testable in the (REF, EXT) version.

[Rule 11-15] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[@name and @type
        and (nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument'))
             or nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument')))
        and (some $type-qname in resolve-QName(@type, .) satisfies (
               nf:get-target-namespace(.) != namespace-uri-from-QName($type-qname)
               and nf:resolve-type(., $type-qname)/xs:simpleContent))]">
-    <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                        ends-with(@name, $representation-term)"
-      >the name of an element declaration that is of simple content MUST use a representation term.</sch:assert>
+    <sch:report test="every $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
+                            not(ends-with(@name, $representation-term))"
+      >the name of an element declaration that is of simple content SHOULD use a representation term.</sch:report>
   </sch:rule>
-</sch:pattern>

Representation terms are defined by Table 10-2, Representation terms, above. This rule supports Rule 10-62, Element with simple content has representation term (REF, EXT), above.

11.2.2. Element substitution group
Rule 11-18. Element substitution group defined by conformant schema
[Rule 11-18] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

Representation terms are defined by Table 10-2, Representation terms, above. This rule supports Rule 10-64, Element with simple content has representation term (REF, EXT), above.

11.2.2. Element substitution group
Rule 11-16. Element substitution group defined by conformant schema
[Rule 11-16] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(@substitutionGroup)]">
     <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@substitutionGroup, .))"/>
     <sch:assert test="$namespace = nf:get-target-namespace(.)
@@ -1248,7 +1213,7 @@
                                     and empty(@appinfo:externalImportIndicator)])"
       >An element substitution group MUST have either the target namespace or a namespace that is imported as conformant.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.2.3. Attribute declaration
Rule 11-19. Attribute type defined by conformant schema
[Rule 11-19] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.2.3. Attribute declaration
Rule 11-17. Attribute type defined by conformant schema
[Rule 11-17] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@type)]">
     <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@type, .))"/>
     <sch:assert test="$namespace = (nf:get-target-namespace(.), xs:anyURI('http://www.w3.org/2001/XMLSchema'))
@@ -1257,13 +1222,13 @@
                                     and empty(@appinfo:externalImportIndicator)])"
       >The type of an attribute declaration MUST have the target namespace or the XML Schema namespace or a namespace that is imported as conformant.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 11-20. Attribute name uses representation term
[Rule 11-20] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 11-18. Attribute name uses representation term
[Rule 11-18] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[exists(@name)]">
-    <sch:assert test="some $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
-                        ends-with(@name, $representation-term)"
-                >An attribute name MUST end with a representation term.</sch:assert>
+    <sch:report test="every $representation-term in ('Amount', 'BinaryObject', 'Graphic', 'Picture', 'Sound', 'Video', 'Code', 'DateTime', 'Date', 'Time', 'Duration', 'ID', 'URI', 'Indicator', 'Measure', 'Numeric', 'Value', 'Rate', 'Percent', 'Quantity', 'Text', 'Name', 'List') satisfies
+                            not(ends-with(@name, $representation-term))"
+                >An attribute name SHOULD end with a representation term.</sch:report>
   </sch:rule>
-</sch:pattern>
11.2.4. Notation declaration
11.3. Model group components
11.3.1. Model group
11.3.2. Particle
11.3.2.1. Element use
Rule 11-21. Element or attribute declaration introduced only once into a type
[Rule 11-21] (REF, EXT) (Constraint)

Within the schema, an element declaration or attribute declaration MUST NOT be introduced more than once into a type definition. This applies to content acquired by a type by any means, including from a base type definition, via element substitution groups, or through the use of attribute groups.

This rule ensures that a type definition does not incorporate a component multiple times. As information exchange specifications often contain multiple versions of schemas, including reference schemas as well as subset and constraint schemas, it may be easy to omit an element or attribute in one version of the schema, only to reincorporate it via an extension. This can cause difficulties in integrating such schemas, as it may be impossible to use a reference schema if an attribute is added twice, in both a base type and an extension type, since that would make it an invalid schema.

Incorporating a component multiple times can also make it difficult to avoid violating XML Schema’s unique particle attribution constraint, which is described by [XML Schema Structures] Section 3.8.6, Constraints on Model Group Schema Components. This can create difficulty if an element is added both directly, and via a substitution group head. In such a case, a parser may not be able to determine which element use is responsible for an element in an instance, which is a violation of the UPA constraint.

This rule is also intended to prevent developers from creating complicated sequences of recurring elements. Such definitions are difficult for developers to satisfy in code, and can cause havoc with XML Schema language binding tools. If an element is needed more than once, or if a particular sequence of elements is needed, a developer should consider the use of flexible content models (via substitution groups) along with additional rules.

Rule 11-22. Element reference defined by conformant schema
[Rule 11-22] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.2.4. Notation declaration
11.3. Model group components
11.3.1. Model group
11.3.2. Particle
11.3.2.1. Element use
Rule 11-19. Element or attribute declaration introduced only once into a type
[Rule 11-19] (REF, EXT) (Constraint)

Within the schema, an element declaration or attribute declaration MUST NOT be introduced more than once into a type definition. This applies to content acquired by a type by any means, including from a base type definition, via element substitution groups, or through the use of attribute groups.

This rule ensures that a type definition does not incorporate a component multiple times. As information exchange specifications often contain multiple versions of schemas, including reference schemas as well as subset and constraint schemas, it may be easy to omit an element or attribute in one version of the schema, only to reincorporate it via an extension. This can cause difficulties in integrating such schemas, as it may be impossible to use a reference schema if an attribute is added twice, in both a base type and an extension type, since that would make it an invalid schema.

Incorporating a component multiple times can also make it difficult to avoid violating XML Schema’s unique particle attribution constraint, which is described by [XML Schema Structures] Section 3.8.6, Constraints on Model Group Schema Components. This can create difficulty if an element is added both directly, and via a substitution group head. In such a case, a parser may not be able to determine which element use is responsible for an element in an instance, which is a violation of the UPA constraint.

This rule is also intended to prevent developers from creating complicated sequences of recurring elements. Such definitions are difficult for developers to satisfy in code, and can cause havoc with XML Schema language binding tools. If an element is needed more than once, or if a particular sequence of elements is needed, a developer should consider the use of flexible content models (via substitution groups) along with additional rules.

Rule 11-20. Element reference defined by conformant schema
[Rule 11-20] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[exists(ancestor::xs:complexType[empty(@appinfo:externalAdapterTypeIndicator)]) and @ref]">
     <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@ref, .))"/>
     <sch:assert test="$namespace = nf:get-target-namespace(.)
@@ -1272,7 +1237,7 @@
                                     and empty(@appinfo:externalImportIndicator)])"
       >An element reference MUST be to a component that has a namespace that is either the target namespace of the schema document in which it appears, or which is imported as conformant by that schema document.</sch:assert>
   </sch:rule>
-</sch:pattern>

The term schema document is a defined term.

11.3.3. Attribute use
Rule 11-23. Referenced attribute defined by conformant schemas
[Rule 11-23] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

The term schema document is a defined term.

11.3.3. Attribute use
Rule 11-21. Referenced attribute defined by conformant schemas
[Rule 11-21] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attribute[@ref]">
     <sch:let name="namespace" value="namespace-uri-from-QName(resolve-QName(@ref, .))"/>
     <sch:assert test="some $namespace in namespace-uri-from-QName(resolve-QName(@ref, .)) satisfies (
@@ -1283,7 +1248,7 @@
                              and empty(@appinfo:externalImportIndicator)])"
       >An attribute {}ref MUST have the target namespace or a namespace that is imported as conformant.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.3.3.1. Attribute group use
Rule 11-24. Schema uses only known attribute groups

In conformant schemas, use of attribute groups is restricted. The only attribute group defined by NIEM for use in conformant schemas is structures:SimpleObjectAttributeGroup. This attribute group provides the attributes necessary for IDs, references, metadata, and relationship metadata. In addition, there are attributes defined by ISM and NTK namespaces, which may be used in conformant schemas. Rationale for this use is provided in Section 7.6, IC-ISM and IC-NTK, above.

[Rule 11-24] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.3.3.1. Attribute group use
Rule 11-22. Schema uses only known attribute groups

In conformant schemas, use of attribute groups is restricted. The only attribute group defined by NIEM for use in conformant schemas is structures:SimpleObjectAttributeGroup. This attribute group provides the attributes necessary for IDs, references, metadata, and relationship metadata. In addition, there are attributes defined by ISM and NTK namespaces, which may be used in conformant schemas. Rationale for this use is provided in Section 7.6, IC-ISM and IC-NTK, above.

[Rule 11-22] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:attributeGroup[@ref]">
     <sch:assert test="some $ref in resolve-QName(@ref, .) satisfies (
                         $ref = xs:QName('structures:SimpleObjectAttributeGroup')
@@ -1291,82 +1256,108 @@
                                                              xs:anyURI('urn:us:gov:ic:ntk')))"
       >An attribute group reference MUST be structures:SimpleObjectAttributeGroup or have the IC-ISM or IC-NTK namespace.</sch:assert>
   </sch:rule>
-</sch:pattern>
11.3.4. Wildcard
11.4. Identity-constraint definition components
11.5. Group definition components
11.5.1. Model group definition
11.5.2. Attribute group definition
11.6. Annotation components

NIEM-conformant schemas define data models for the purpose of information exchange. A major part of defining data models is the proper definition of the contents of the model. What does a component mean, and what might it contain? How should it be used? NIEM- conformant schemas contain the invariant part of the definitions for the data model. The set of definitions includes:

  1. A text definition of each component. This describes what the component means. The term used in this specification for such a text definition is data definition.
  2. The structural definition of each component. This is made up of XML Schema component definitions, along with certain application information (via xs:appinfo).

When possible, meaning is expressed via XML Schema mechanisms: type derivation, element substitution, specific types and structures, as well as names that are trivially parseable. Beyond that, NIEM-specific syntax must be used, as discussed in this section.

11.6.1. Human-readable documentation

Note that Rule 11-29, Data definition follows 11179-4 requirements (REF, EXT), below, and Rule 11-30, Data definition follows 11179-4 recommendations (REF, EXT), below, apply [ISO 11179-4] definition rules to documented components.

Rule 11-25. Data definition does not introduce ambiguity
[Rule 11-25] (REF, EXT) (Constraint)

Words or synonyms for the words within a data definition MUST NOT be reused as terms in the corresponding component name if those words dilute the semantics and understanding of, or impart ambiguity to, the entity or concept that the component represents.

This document defines the term data definition.

Rule 11-26. Object class has only one meaning
[Rule 11-26] (REF, EXT) (Constraint)

An object class MUST have one and only one associated semantic meaning (i.e., a single word sense) as described in the definition of the component that represents that object class.

Rule 11-27. Data definition of a part does not redefine the whole
[Rule 11-27] (REF, EXT) (Constraint)

An object class MUST NOT be redefined within the definitions of the components that represent properties or subparts of that entity or class.

Data definitions should be concise, precise, and unambiguous without embedding additional definitions of data elements that have already been defined once elsewhere (such as object classes). [ISO 11179-4] says that definitions should not be nested inside other definitions. Furthermore, a data dictionary is not a language dictionary. It is acceptable to reuse terms (object class, property term, and qualifier terms) from a component name within its corresponding definition to enhance clarity, as long as the requirements and recommendations of [ISO 11179-4] are not violated. This further enhances brevity and precision.

Rule 11-28. Do not leak representation into data definition
[Rule 11-28] (REF, EXT) (Constraint)

A data definition MUST NOT contain explicit representational or data typing information such as number of characters, classes of characters, range of mathematical values, etc., unless the very nature of the component can be described only by such information.

A component definition is intended to describe semantic meaning only, not representation or structure. How a component with simple content is represented is indicated through the representation term, but the primary source of representational information should come from the XML Schema definition of the types themselves. A developer should try to keep a component’s data definition decoupled from its representation.

Rule 11-29. Data definition follows 11179-4 requirements
[Rule 11-29] (REF, EXT) (Constraint)

Each data definition MUST conform to the requirements for data definitions provided by [ISO 11179-4] Section 5.2, Requirements.

Rule 11-30. Data definition follows 11179-4 recommendations
[Rule 11-30] (REF, EXT) (Constraint)

Each data definition SHOULD conform to the recommendations for data definitions provided by [ISO 11179-4] Section 5.3, Recommendations.

11.6.1.1. Data definition opening phrases
Rule 11-31. Standard opening phrase for element
[Rule 11-31] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.3.4. Wildcard
11.4. Identity-constraint definition components
11.5. Group definition components
11.5.1. Model group definition
11.5.2. Attribute group definition
11.6. Annotation components

NIEM-conformant schemas define data models for the purpose of information exchange. A major part of defining data models is the proper definition of the contents of the model. What does a component mean, and what might it contain? How should it be used? NIEM- conformant schemas contain the invariant part of the definitions for the data model. The set of definitions includes:

  1. A text definition of each component. This describes what the component means. The term used in this specification for such a text definition is data definition.
  2. The structural definition of each component. This is made up of XML Schema component definitions, along with certain application information (via xs:appinfo).

When possible, meaning is expressed via XML Schema mechanisms: type derivation, element substitution, specific types and structures, as well as names that may be easily parsed. Beyond that, NIEM-specific syntax must be used, as discussed in this section.

11.6.1. Human-readable documentation

Note that Rule 11-27, Data definition follows 11179-4 requirements (REF, EXT), below, and Rule 11-28, Data definition follows 11179-4 recommendations (REF, EXT), below, apply [ISO 11179-4] definition rules to documented components.

Rule 11-23. Data definition does not introduce ambiguity
[Rule 11-23] (REF, EXT) (Constraint)

Words or synonyms for the words within a data definition MUST NOT be reused as terms in the corresponding component name if those words dilute the semantics and understanding of, or impart ambiguity to, the entity or concept that the component represents.

This document defines the term data definition.

Rule 11-24. Object class has only one meaning
[Rule 11-24] (REF, EXT) (Constraint)

An object class MUST have one and only one associated semantic meaning (i.e., a single word sense) as described in the definition of the component that represents that object class.

Rule 11-25. Data definition of a part does not redefine the whole
[Rule 11-25] (REF, EXT) (Constraint)

An object class MUST NOT be redefined within the definitions of the components that represent properties or subparts of that entity or class.

Data definitions should be concise, precise, and unambiguous without embedding additional definitions of data elements that have already been defined once elsewhere (such as object classes). [ISO 11179-4] says that definitions should not be nested inside other definitions. Furthermore, a data dictionary is not a language dictionary. It is acceptable to reuse terms (object class, property term, and qualifier terms) from a component name within its corresponding definition to enhance clarity, as long as the requirements and recommendations of [ISO 11179-4] are not violated. This further enhances brevity and precision.

Rule 11-26. Do not leak representation into data definition
[Rule 11-26] (REF, EXT) (Constraint)

A data definition MUST NOT contain explicit representational or data typing information such as number of characters, classes of characters, range of mathematical values, etc., unless the very nature of the component can be described only by such information.

A component definition is intended to describe semantic meaning only, not representation or structure. How a component with simple content is represented is indicated through the representation term, but the primary source of representational information should come from the XML Schema definition of the types themselves. A developer should try to keep a component’s data definition decoupled from its representation.

Rule 11-27. Data definition follows 11179-4 requirements
[Rule 11-27] (REF, EXT) (Constraint)

Each data definition MUST conform to the requirements for data definitions provided by [ISO 11179-4] Section 5.2, Requirements.

Rule 11-28. Data definition follows 11179-4 recommendations
[Rule 11-28] (REF, EXT) (Constraint)

Each data definition SHOULD conform to the recommendations for data definitions provided by [ISO 11179-4] Section 5.3, Recommendations.

11.6.1.1. Data definition opening phrases
11.6.1.1.1. Element opening phrases
Rule 11-29. Standard opening phrase for augmentation point element
[Rule 11-29] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[ends-with(@name, 'AugmentationPoint')]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(starts-with(lower-case(normalize-space(.)), 'an augmentation point '))"
       >The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...".</sch:report>
   </sch:rule>
+</sch:pattern>
Rule 11-30. Standard opening phrase for augmentation element
[Rule 11-30] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[ends-with(@name, 'Augmentation')]/xs:annotation/xs:documentation[1]">
-    <sch:report test="not(some $phrase in ('supplements ', 'additional information about ')
-                            satisfies starts-with(lower-case(normalize-space(.)), $phrase))"
+    <sch:report test="every $phrase in ('supplements ', 'additional information about ')
+                      satisfies not(starts-with(lower-case(normalize-space(.)), $phrase))"
       >The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Metadata')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-31. Standard opening phrase for metadata element
[Rule 11-31] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Metadata')
+                                and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '(metadata about|information that further qualifies)'))"
       >The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Association') and empty(@abstract)
-                       ]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-32. Standard opening phrase for association element
[Rule 11-32] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Association')
+                                and not(xs:boolean(@abstract) eq true())]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)),
                                   '^an?( .*)? (relationship|association)'))"
       >The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...".</sch:report>
   </sch:rule>
+</sch:pattern>
Rule 11-33. Standard opening phrase for abstract element
[Rule 11-33] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:element[xs:boolean(@abstract) = true()
-                       ]/xs:annotation/xs:documentation[1]">
+                       and not(ends-with(@name, 'AugmentationPoint'))]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(starts-with(lower-case(normalize-space(.)), 'a data concept'))"
       >The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Date')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-34. Standard opening phrase for date element
[Rule 11-34] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Date') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (date|month|year)'))"
       >The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Quantity')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-35. Standard opening phrase for quantity element
[Rule 11-35] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Quantity') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (count|number)'))"
       >The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Picture')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-36. Standard opening phrase for picture element
[Rule 11-36] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Picture') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? (image|picture|photograph)'))"
       >The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Indicator')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-37. Standard opening phrase for indicator element
[Rule 11-37] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Indicator') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^true if .*; false (otherwise|if)'))"
       >The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Identification')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-38. Standard opening phrase for identification element
[Rule 11-38] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Identification') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^an?( .*)? identification'))"
       >The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[ends-with(@name, 'Name')]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-39. Standard opening phrase for name element
[Rule 11-39] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[ends-with(@name, 'Name') and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^(a|an)( .*)? name'))"
       >The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...".</sch:report>
   </sch:rule>
-  <sch:rule context="xs:element[@name]/xs:annotation/xs:documentation[1]">
+</sch:pattern>
Rule 11-40. Standard opening phrase for element
[Rule 11-40] (REF, EXT) (Constraint)
<sch:pattern>
+  <sch:rule context="xs:element[@name 
+                                and not(ends-with(@name, 'Indicator'))
+                                and not(ends-with(@name, 'Augmentation'))
+                                and not(ends-with(@name, 'Metadata'))
+                                and not(xs:boolean(@abstract) eq true())]
+                       /xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^an? '))"
-      >The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)".</sch:report>
+      >The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)".</sch:report>
   </sch:rule>
-</sch:pattern>
Rule 11-32. Standard opening phrase for complex type
[Rule 11-32] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
11.6.1.1.2. Complex type opening phrases
Rule 11-41. Standard opening phrase for association type
[Rule 11-41] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[ends-with(@name, 'AssociationType')]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type for (a relationship|an association)'))"
-      >The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...".</sch:report>
+      >The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...".</sch:report>
   </sch:rule>
+</sch:pattern>
Rule 11-42. Standard opening phrase for augmentation type
[Rule 11-42] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[ends-with(@name, 'AugmentationType')]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type (that supplements|for additional information about)'))"
       >The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...".</sch:report>
   </sch:rule>
+</sch:pattern>
Rule 11-43. Standard opening phrase for metadata type
[Rule 11-43] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType[ends-with(@name, 'MetadataType')]/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type for (metadata about|information that further qualifies)'))"
       >The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...".</sch:report>
   </sch:rule>
+</sch:pattern>
Rule 11-44. Standard opening phrase for complex type
[Rule 11-44] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:complexType/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type'))"
-      >The data definition for a type SHOULD begin with the standard opening phrase "a data type...".</sch:report>
+      >The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...".</sch:report>
   </sch:rule>
-</sch:pattern>
Rule 11-33. Standard opening phrase for simple type
[Rule 11-33] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 11-45. Standard opening phrase for simple type
[Rule 11-45] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:simpleType/xs:annotation/xs:documentation[1]">
     <sch:report test="not(matches(lower-case(normalize-space(.)), '^a data type'))"
-      >The data definition for a type SHOULD begin with a standard opening phrase "a data type...".</sch:report>
+      >The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...".</sch:report>
   </sch:rule>
-</sch:pattern>
11.7. Schema as a whole
11.7.1. xs:schema document element restrictions
Rule 11-34. Same namespace means same components
[Rule 11-34] (REF, EXT) (Interpretation)

Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, if and only if they represent the same set of components.

Rule 11-35. Different version means different view
[Rule 11-35] (REF, EXT) (Interpretation)

Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, and different values for attribute version carried by the element xs:schema if and only if they are different views of the same set of components.

These rules embody the basic philosophy behind NIEM’s use of namespaced components: A component is uniquely identified by its class (e.g. element, attribute, type), its namespace (a URI), and its local name (an unqualified string). Any two matching component identifiers refer to the same component, even if the versions of the schemas containing each are different.

11.8. Schema assembly
Rule 11-36. Reference schema imports reference schema
[Rule 11-36] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>
11.7. Schema as a whole
11.7.1. xs:schema document element restrictions
Rule 11-46. Same namespace means same components
[Rule 11-46] (REF, EXT) (Interpretation)

Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, if and only if they represent the same set of components.

Rule 11-47. Different version means different view
[Rule 11-47] (REF, EXT) (Interpretation)

Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, and different values for attribute version carried by the element xs:schema if and only if they are different views of the same set of components.

These rules embody the basic philosophy behind NIEM’s use of components with namespaces: A component is uniquely identified by its class (e.g. element, attribute, type), its namespace (a URI), and its local name (an unqualified string). Any two matching component identifiers refer to the same component, even if the versions of the schemas containing each are different.

11.8. Schema assembly
Rule 11-48. Reference schema imports reference schema
[Rule 11-48] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import[
                          nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument'))
                          and exists(@namespace)
@@ -1377,7 +1368,7 @@
                         nf:has-effective-conformance-target-identifier($schema, xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ReferenceSchemaDocument'))"
       >A namespace imported as conformant from a reference schema document MUST identify a namespace defined by a reference schema document.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the term reference schema document.

Rule 11-37. Extension schema document imports reference or extension schema
[Rule 11-37] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the term reference schema document.

Rule 11-49. Extension schema document imports reference or extension schema
[Rule 11-49] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import[
                          nf:has-effective-conformance-target-identifier(., xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument'))
                          and exists(@namespace)
@@ -1389,19 +1380,19 @@
                         or nf:has-effective-conformance-target-identifier($schema, xs:anyURI('http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument')))"
       >A namespace imported as conformant from an extension schema document MUST identify a namespace defined by a reference schema document or an extension schema document.</sch:assert>
   </sch:rule>
-</sch:pattern>

This document defines the terms extension schema document and reference schema document.

11.8.1. Supporting namespaces are imported as conformant

There are several namespaces that are treated specially by the NIEM NDR. When the following namespaces are imported into a conformant schema document, they must be imported as if they are conformant. That is, the xs:import element must not have an attribute appinfo:externalImportIndicator with a value of true.

Rule 11-38. Structures imported as conformant
[Rule 11-38] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>

This document defines the terms extension schema document and reference schema document.

11.8.1. Supporting namespaces are imported as conformant

There are several namespaces that are treated specially by the NIEM NDR. When the following namespaces are imported into a conformant schema document, they must be imported as if they are conformant. That is, the xs:import element must not have an attribute appinfo:externalImportIndicator with a value of true.

Rule 11-50. Structures imported as conformant
[Rule 11-50] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import[exists(@namespace)
                                and xs:anyURI(@namespace) = xs:anyURI('http://release.niem.gov/niem/structures/4.0/')]">
     <sch:assert test="empty(@appinfo:externalImportIndicator)"
       >An import of the structures namespace MUST NOT be labeled as an external import.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 11-39. XML namespace imported as conformant
[Rule 11-39] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 11-51. XML namespace imported as conformant
[Rule 11-51] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import[exists(@namespace)
                                and xs:anyURI(@namespace) = xs:anyURI('http://www.w3.org/XML/1998/namespace')]">
     <sch:assert test="empty(@appinfo:externalImportIndicator)"
       >An import of the XML namespace MUST NOT be labeled as an external import.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 11-40. Each namespace may have only a single root schema in a schema set
[Rule 11-40] (SET) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 11-52. Each namespace may have only a single root schema in a schema set
[Rule 11-52] (SET) (Constraint)
<sch:pattern>
   <sch:rule context="xs:schema[exists(@targetNamespace)
                                and (some $element
                                    in nf:resolve-namespace(., xs:anyURI(@targetNamespace))
@@ -1409,7 +1400,7 @@
     <sch:assert test="count(nf:resolve-namespace(., xs:anyURI(@targetNamespace))) = 1"
                 >A namespace may appear as a root schema in a schema set only once.</sch:assert>
   </sch:rule>
-</sch:pattern>
Rule 11-41. Consistently marked namespace imports

XML Schemas allows multiple xs:import elements for the same namespace, which allows for multiple sets of annotations and schema locations.

[Rule 11-41] (REF, EXT) (Constraint)
<sch:pattern>
+</sch:pattern>
Rule 11-53. Consistently marked namespace imports

XML Schemas allows multiple xs:import elements for the same namespace, which allows for multiple sets of annotations and schema locations.

[Rule 11-53] (REF, EXT) (Constraint)
<sch:pattern>
   <sch:rule context="xs:import">
     <sch:let name="namespace" value="@namespace"/>
     <sch:let name="is-conformant" value="empty(@appinfo:externalImportIndicator)"/>
@@ -1418,44 +1409,47 @@
                       or $is-conformant = empty($first/@appinfo:externalImportIndicator)"
             >All xs:import elements that have the same namespace MUST have the same conformance marking via appinfo:externalImportIndicator.</sch:assert>
   </sch:rule>
-</sch:pattern>
12. XML instance document rules

This specification attempts to restrict XML instance data as little as possible while still maintaining interoperability.

NIEM does not require a specific encoding or specific requirements for the XML prologue, except as specified by [XML].

Rule 12-1. Instance must be schema-valid
[Rule 12-1] (INS) (Constraint)

The XML document MUST be schema-valid, as assessed against a conformant schema document set, composed of authoritative, comprehensive schema documents for the relevant namespaces.

The schemas that define the exchange must be authoritative. Each is the reference schema or extension schema for the namespace it defines. Application developers may use other schemas for various purposes, but for the purposes of determining conformance, the authoritative schemas are relevant.

This rule should not be construed to mean that XML validation must be performed on all XML instances as they are served or consumed; only that the XML instances validate if XML validation is performed. The XML Schema component definitions specify XML documents and element information items, and the instances should follow the rules given by the schemas, even when validation is not performed.

NIEM embraces the use of XML Schema instance attributes, including xsi:type, xsi:nil, and xsi:schemaLocation, as specified by [XML Schema Structures].

12.1. Content elements

In XML instances, relationships between data objects are expressed as XML elements:

  1. Data objects are expressed as XML elements.
  2. XML elements contain attributes and other elements.

In this way, there is a relationship between the outer element (the containing element, also called the parent element) and the inner elements (the contained elements, also called as the child elements). An element that contains its content in this way is called a content element.

[Definition: content element]

A content element is an element information item that does not contain an attribute structures:ref. A content element expresses its value as text and element content of the element information item.

The most common NIEM patterns use content elements to represent most data. The following is an example of a content element in use. All elements in this example are content elements.

Figure 12-1: Example of content elements
<nc:Item>
-  <nc:ItemOwner>
-    <nc:EntityPerson>
+</sch:pattern>
12. XML instance document rules

This specification attempts to restrict XML instance data as little as possible while still maintaining interoperability.

NIEM does not require a specific encoding or specific requirements for the XML prologue, except as specified by [XML].

Rule 12-1. Instance must be schema-valid
[Rule 12-1] (INS) (Constraint)

The XML document MUST be schema-valid, as assessed against a conformant schema document set, composed of authoritative, comprehensive schema documents for the relevant namespaces.

The schemas that define the exchange must be authoritative. Each is the reference schema or extension schema for the namespace it defines. Application developers may use other schemas for various purposes, but for the purposes of determining conformance, the authoritative schemas are relevant.

This rule should not be construed to mean that XML validation must be performed on all XML instances as they are served or consumed; only that the XML instances validate if XML validation is performed. The XML Schema component definitions specify XML documents and element information items, and the instances should follow the rules given by the schemas, even when validation is not performed.

NIEM embraces the use of XML Schema instance attributes, including xsi:type, xsi:nil, and xsi:schemaLocation, as specified by [XML Schema Structures].

12.1. The meaning of NIEM data

The main way that NIEM XML data represents relationships and values is via the hierarchy of XML elements in an XML document. For example, the following fragment of an XML document:

Figure 12-1: Example of content elements
<nc:Person>
+  <nc:PersonName>
+    <nc:PersonFullName>John Doe</nc:PersonFullName>
+  </nc:PersonName>
+</nc:Person>

In this instance, the XML elements describe relationships between data objects:

Table 12-1: Meaning of NIEM XML
XML descriptionThe Meaning of the data
The top element occurs within some context, about which we do not know anything.There is some object, representing whatever is outside the outer element.
The top element is nc:Person. The NIEM reference schema defines the type of the element as nc:PersonType.There is a relationship, called nc:Person, between the unknown context object and an object of type nc:PersonType.
The next element is nc:PersonName. The schema indicates that element is of type nc:PersonNameType.There is a relationship called nc:PersonName between the object of type nc:PersonType and an object of type nc:PersonNameType.
The next element is nc:PersonFullName. The schema shows that the element is of type nc:PersonNameTextType.There is a relationship, called nc:PersonFullName from the object of type nc:PersonNameType and an object of type nc:PersonNameTextType.
Within that element is the simple value John Doe. The schema tells us the content of that element is of simple type xs:string.The object of type nc:PersonNameTextType has a value that is the literal John Doe.

To summarize:

  1. Data objects and literal values are expressed in XML as the values of elements and attributes.
  2. The names of the XML elements and attributes identify and describe the relationships between the objects and literals.
  3. The names of the XML Schema complex types and simple types describe the data objects.

NIEM is designed so that NIEM XML data is a form of RDF data. This is described in some detail by Section 5, The NIEM conceptual model, above, in particular Section 5.6.3, NIEM instance mappings to RDF, above. The XML data, above, corresponds to the following graph. Here, the circles are data objects, and the arrows show relationships, between the objects, and between the objects and their types:

Figure 12-2: Diagram showing the meaning of XML data
Rule 12-2. Empty content has no meaning
[Rule 12-2] (INS) (Interpretation)

Within the instance, the meaning of an element with no content is that additional properties are not asserted. There MUST NOT be additional meaning interpreted for an element with no content.

Elements without content only show a lack of asserted information. That is, all that is asserted is what is explicitly stated, through a combination of XML instance data and its schema. Data that is not present makes no claims. It may be absent due to lack of availability, lack of knowledge, or deliberate withholding of information. These cases should be modeled explicitly, if they are required.

12.2. Identifiers and references

Nested elements, shown above, are sufficient to represent simple data that takes the form of a tree. However, the use of nested elements has limitations; expression of all relationships via nested elements is not always possible. Situations that cause problems include:

  • Cycles: some object has a relationship that, when followed, eventually circles back to itself. For example, suppose that Bob has a sister relationship to Sue, who has a brother relationship back to Bob. This is not a tree, and so needs some representation other than just nested elements.
  • Reuse: multiple objects have a relationship to a common object. For example, suppose Bob and Sue both have a mother relationship to Sally. Expressed via nested elements, this would result in a duplicate representation of Sally.

NIEM provides two different ways to solve this problem: the use of local references pointing to local identifiers, and the use of uniform resource identifiers (URIs). These two methods are similar, and can interoperate, but have distinctions, as described by Section 12.2.3, Differentiating reference-to-identifier links and use of URIs, below.

Rule 12-3. Element has only one resource identifying attribute
[Rule 12-3] (INS) (Constraint)
<sch:pattern>
+  <sch:rule context="*[exists(@structures:id) or exists(@structures:ref) or exists(@structures:uri)]">
+    <sch:assert test="count(@structures:id | @structures:ref | @structures:uri) le 1"
+      >An element MUST NOT have more than one attribute that is structures:id, structures:ref, or structures:uri.</sch:assert>
+  </sch:rule>
+</sch:pattern>
12.2.1. Local identifiers and references

The XML specifications define ID and IDREF attributes, which act as references in XML data. This is supported by XML Schema, and NIEM uses ID and IDREF as one way to reference data across data objects. Under this framework:

  • Within an XML document, each value of any attribute of type xs:ID must be unique. For example, if an element has an attribute of type xs:ID with the value of Bob, then there may not be any other attribute in the document that is of type xs:ID that also has the value Bob. NIEM provides attribute structures:id of type xs:ID to act as a standard local identifier.
  • Within an XML document, the value of any attribute of type xs:IDREF must appear somewhere within the document as the value of some attribute of type xs:ID. For example, if an attribute of type xs:IDREF has the value Bob, then somewhere within that XML document there must be an attribute of type xs:ID with the value Bob. NIEM provides attribute structures:ref as a standard local reference.
  • These constraints, that IDs must be unique, and that IDREFs must refer to IDs, are XML constraints, not unique to NIEM.
  • There are additional constraints placed on XML documents and XML schemas regarding the use of ID and IDREF attributes. For example, an element may not have two attributes of type ID.

In short, within a NIEM-conformant XML document, an attribute structures:ref refers to an attribute structures:id. These attributes may appear in an XML document to express that an object that is the value of an element is the same as some other object within the document. For example, in the following example, the user of the weapon (Bart) is the same person that is the subject of the arrest:

Figure 12-3: Example of structures:id and structures:ref
<j:Arrest>
+  <j:ArrestInvolvedWeapon>
+    <nc:WeaponUser structures:id="bart">
       <nc:PersonName>
-        <nc:PersonFullName>John Doe</nc:PersonFullName>
+        <nc:PersonGivenName>Bart</nc:PersonGivenName>
       </nc:PersonName>
-    </nc:EntityPerson>
-  </nc:ItemOwner>
-</nc:Item>
12.2. Reference elements

Content elements are sufficient to represent data that takes the form of a tree. However, use of content elements has limitations; expression of all relationships via element containment is not always possible. Situations that cause problems include:

  • Cycles: the relationships transitively held by an object include a relationship to itself.

    For example, suppose that object 1 has a relationship to object 2 and object 2 has a relationship to object 1. This is not a tree, and so needs some representation other than a simple tree.

  • Reuse: multiple objects have a relationship to a common object.

    For example, suppose object 1 has a relationship to object 2 and object 3 has a relationship to object 2. Expressed via containment, this would result in a duplicate of object 2.

A method that solves this problem is the use of references. In a C or assembler, you could use a pointer. In C++, a reference might be used. In Java, a reference value might be used. The method defined by the XML standard is the use of ID and IDREF. An IDREF refers to an ID. NIEM uses this method and assigns to it specific semantics.

Naive solutions to these problems that use only content elements require techniques such as repeating data and identifying and excluding duplicate data; these operation entail the use of excess storage and processing time.

It is good to avoid these problems; in order to avoid them, NIEM allows reference elements. A reference element expresses a relationship to another object by using a reference attribute, structures:ref. In Figure 12-2, Example of reference element, below, the outer object is the content of nc:Item, which is an object of type nc:ItemType. It has a relationship nc:ItemOwner to the object that is the content of the nc:Entity element.

Figure 12-2: Example of reference element
<nc:Item>
-  <nc:ItemOwner structures:ref="m82"/>
-</nc:Item>
-<nc:Entity structures:id="m82">
-  <nc:EntityPerson>
-    <nc:PersonName>
-      <nc:PersonFullName>John Doe</nc:PersonFullName>
-    </nc:PersonName>
-  </nc:EntityPerson>
-</nc:Entity>

NIEM XML instances use IDREF attributes to establish links between XML elements.

[Definition: reference element]

A reference element is an element information item that has an attribute structures:ref. A reference element refers to its value by reference, instead of carrying it as content.

Rule 12-2. Attribute structures:ref must reference structures:id
[Rule 12-2] (INS) (Constraint)
<sch:pattern>
+    </nc:WeaponUser>
+  </j:ArrestInvolvedWeapon>
+  <j:ArrestSubject>
+    <nc:RoleOfPerson structures:ref="bart"/>
+  </j:ArrestSubject>
+</j:Arrest>

Note that rules below establish that relationships established using structures:id and structures:ref have the exact same meaning as relationships established using nested elements. An information exchange specification may constrain them differently, or prefer one over the other, but from a NIEM perspective, they have the same meaning.

Rule 12-4. Attribute structures:ref must reference structures:id

Although many attributes with ID and IDREF semantics are defined by many vocabularies, for consistency, within a NIEM XML document any attribute structures:ref must refer to an attribute structures:id, and not any other attribute.

[Rule 12-4] (INS) (Constraint)
<sch:pattern>
   <sch:rule context="*[@structures:ref]">
     <sch:let name="ref" value="@structures:ref"/>
     <sch:assert test="exists(//*[@structures:id = $ref])"
       >The value of an attribute structures:ref MUST match the value of an attribute structures:id of some element in the XML document.</sch:assert>
   </sch:rule>
-</sch:pattern>

This mirrors the terminology in [XML] subsection Validity constraint: IDREF within Section 3.3.1, Attribute Types, except it requires the target attribute to be structures:id, rather than any attribute of type ID.

Rule 12-3. Linked elements have same validation root
[Rule 12-3] (INS) (Constraint)

Given that:

Every element that has an attribute structures:ref MUST have a referencing element validation root that is equal to the referenced element validation root.

The term validation root is defined by [XML Schema Structures] Section 5.2, Assessing Schema-Validity. It is established as a part of validity assessment of an XML document. It is required because relationships between the types of elements cannot be established if those elements were not assessed together.

Rule 12-4. Attribute structures:ref references element of correct type
[Rule 12-4] (INS) (Constraint)

Given that:

Every element that has an attribute structures:ref MUST have a referenced element type definition that is validly derived from the referencing element type definition.

The term validly derived is as established by [XML Schema Structures] subsection Schema Component Constraint: Type Derivation OK (Complex) within Section 3.4.6, Constraints on Complex Type Definition Schema Components.

This rule requires that the type of the element pointed to by a structures:ref attribute must be of (or derived from) the type of the reference element.

12.2.1. Reference and content elements have same meaning

An important aspect of the use of NIEM reference and content elements is that they have the same meaning. The use of a content element versus a reference element is merely for convenience and ease of serialization. There is no change in meaning or semantics between content and reference elements.

Any claim that content elements represent composition while reference elements represent aggregation is incorrect. Any life cycle dependency is not expressed through the use of content and reference elements, and is not an explicit part of the NIEM model.

Rule 12-5. Reference and content elements have the same meaning
[Rule 12-5] (INS) (Interpretation)

There MUST NOT be any difference in meaning between a relationship established via an element declaration instantiated as a content element and that element declaration instantiated as a reference element.

There is no difference in meaning between relationships established by content elements and those established by reference elements. They are simply two mechanisms for expressing connections between objects. Neither mechanism implies that properties are intrinsic or extrinsic; such characteristics must be explicitly stated in property definitions.

Being of type xs:ID and xs:IDREF, validating schema parsers will perform certain checks on the values of structures:id and structures:ref. Specifically, no two IDs may have the same value. This includes structures:id and other IDs that may be used within an XML document. Also, any value of structures:ref must also appear as the value of an ID.

By this rule, the following two XML fragments have the same meaning. First, Figure 12-3, Example with a backward reference, below, shows a person object being expressed, followed by a backwards reference to it. Second, Figure 12-4, Example with a forward reference, below, shows a person as a forward reference to the person object that is expressed later, within the definition of a witness. Both of these XML fragments have the same semantics.

Figure 12-3: Example with a backward reference
<nc:Person structures:id="c58">
+</sch:pattern>

This mirrors the terminology in [XML] subsection Validity constraint: IDREF within Section 3.3.1, Attribute Types, except it requires the target attribute to be structures:id, rather than any attribute of type ID.

Rule 12-5. Linked elements have same validation root

NIEM supports type-safe references: references using structures:ref and structures:id must preserve the type constraints that would apply if nested elements were used instead of a reference. For example, an element of type nc:PersonType must always refer to another element of type nc:PersonType, or a type derived from nc:PersonType, when using structures:ref to establish the relationship.

[Rule 12-5] (INS) (Constraint)

Given that:

Every element that has an attribute structures:ref MUST have a referencing element validation root that is equal to the referenced element validation root.

The term validation root is defined by [XML Schema Structures] Section 5.2, Assessing Schema-Validity. It is established as a part of validity assessment of an XML document. It is required because relationships between the types of elements cannot be established if those elements were not assessed together.

Rule 12-6. Attribute structures:ref references element of correct type
[Rule 12-6] (INS) (Constraint)

Given that:

Every element that has an attribute structures:ref MUST have a referenced element type definition that is validly derived from the referencing element type definition.

The term validly derived is as established by [XML Schema Structures] subsection Schema Component Constraint: Type Derivation OK (Complex) within Section 3.4.6, Constraints on Complex Type Definition Schema Components.

This rule requires that the type of the element pointed to by a structures:ref attribute must be of (or derived from) the type of the reference element.

12.2.2. Uniform resource identifiers in NIEM data

NIEM supports the linked data methodology through the use of uniform resource identifiers (URIs), expressed through the attribute structures:uri in XML documents . This attribute works much like structures:ref and structures:id, and overlaps somewhat. Linked data introduces key terminology:

  • Anything modeled or addressed by an information system may be called a resource: people, vehicles, reports, documents, relationships, ideas: anything that is talked about and modeled in an information system is a resource.
  • Every resource may have a name, called a uniform resource identifier (URI).

As described in Section 5.4, Unique identification of data objects, above, structures:uri, structures:id, and structures:ref each denote a resource identifier. Although a structures:ref must always refer to a structures:id, and a value of structures:id must be unique within its document, a structures:uri may refer to any of structures:uri, structures:ref, or structures:id.

Rule 12-7. structures:uri denotes resource identifier
[Rule 12-7] (INS) (Interpretation)

The value of an attribute structures:uri is a URI-reference, as defined by [RFC 3986], which denotes a resource identifier on the element holding the attribute, in accordance with evaluation consistent with [RFC 3986] and [XML Base].

The attributes structures:id and structures:ref each have a mapping to equivalent values of structures:uri.

Rule 12-8. structures:id denotes resource identifier
[Rule 12-8] (INS) (Interpretation)

The value of the structures:id with a value of $value denotes a resource identifier on the element holding the attribute, as would be denoted by an attribute structures:uri with a value of #$value.

Rule 12-9. structures:ref denotes resource identifier
[Rule 12-9] (INS) (Interpretation)

The value of the structures:ref with a value of $value denotes a resource identifier on the element holding the attribute, as would be denoted by an attribute structures:uri with a value of #$value.

For example, structures:id="hello" and structures:ref="hello" each denote the same resource identifier for an element as if it held an attribute structures:uri="#hello".

Consistent with Section 5.4, Unique identification of data objects, above, a set of elements that each have the same resource identifier denote the same object, which has that given identifier. This means that, in an XML representation, the properties of an object may be spread across a set of elements that share an identifier.

12.2.3. Differentiating reference-to-identifier links and use of URIs

These two methods are similar, and can interoperate, but have distinctions:

  • With ref-to-id links, both structures:ref and structures:id are required to be within the same document.
  • With ref-to-id links, both structures:id and structures:ref are required to be validated against the same schema.
  • Ref-to-id links provide and require type safety, in that the type of an object pointed to by structures:ref must be consistent with the referencing element’s type declaration.
  • The value of structures:id must be unique for IDs within the document.
  • The value of structures:ref must appear within the document as the value of an attribute structures:id.
  • An attribute structures:uri is a URI-reference that can reference any resource, inside or outside the document.
  • A structures:uri can reference any structures:id within the same document, or in another conformant document.
  • A structures:uri can reference any structures:ref within the same document, or in another conformant document.
  • Any structures:uri may reference any other structures:uri, within the same document, or in another conformant document.
12.2.4. Reference and content elements have same meaning

An important aspect of the use of nested elements, ref-to-id references, and URI references, is that they all have the same meaning. Expressing a relationship via a nested element, versus an ref-to-id reference is merely for convenience and ease of serialization. There is no change in meaning or semantics between relationships expressed by sub-elements versus relationships expressed by structures:ref or structures:uri.

Any claim that nested elements represent composition while references represent aggregation is incorrect. No life cycle dependency is implied by either method.

Rule 12-10. Nested elements and references have the same meaning.
[Rule 12-10] (INS) (Interpretation)

There MUST NOT be any difference in meaning between a relationship established via an element declaration instantiated by a nested element, and that element declaration instantiated via reference.

There is no difference in meaning between relationships established by sub-elements and those established by references. They are simply two mechanisms for expressing connections between objects. Neither mechanism implies that properties are intrinsic or extrinsic; such characteristics must be explicitly stated in property definitions.

Being of type xs:ID and xs:IDREF, validating schema parsers will perform certain checks on the values of structures:id and structures:ref. Specifically, no two IDs may have the same value. This includes structures:id and other IDs that may be used within an XML document. Also, any value of structures:ref must also appear as the value of an ID.

By this rule, the following two XML fragments have the same meaning. First, Figure 12-4, Example with a backward reference, below, shows a person object being expressed, followed by a backwards reference to it. Second, Figure 12-5, Example with a forward reference, below, shows a person as a forward reference to the person object that is expressed later, within the definition of a witness. Both of these XML fragments have the same semantics.

Figure 12-4: Example with a backward reference
<nc:Person structures:id="c58">
   <nc:PersonName>
     <nc:PersonFullName>John Doe</nc:PersonFullName>
   </nc:PersonName>
 </nc:Person>
 <j:Witness>
   <nc:RoleOfPerson structures:ref="c58"/>
-</j:Witness>
Figure 12-4: Example with a forward reference
<nc:Person structures:ref="t85"/>
+</j:Witness>
Figure 12-5: Example with a forward reference
<nc:Person structures:ref="t85"/>
 <j:Witness>
   <nc:RoleOfPerson structures:id="t85">
     <nc:PersonName>
       <nc:PersonFullName>John Doe</nc:PersonFullName>
     </nc:PersonName>
   </nc:RoleOfPerson>
-</j:Witness>

NIEM-conformant data instances may use content elements and reference elements as needed, to represent the meaning of the fundamental data. There is no difference in meaning between reference and content data representations. The two different methods are available for ease of representation. No difference in meaning should be implied by the use of one method or the other.

Assertions that indicate included data is intrinsic, while referenced data is extrinsic, are not valid and are not applicable to NIEM-conformant data instances and data definitions.

Rule 12-6. Empty content has no meaning
[Rule 12-6] (INS) (Interpretation)

Within the instance, the meaning of an element with no content is that additional properties are not asserted. There MUST NOT be additional meaning interpreted for an element with no content.

Elements without content only show a lack of asserted information. That is, all that is asserted is what is explicitly stated, through a combination of XML instance data and its schema. Data that is not present makes no claims. It may be absent due to lack of availability, lack of knowledge, or deliberate withholding of information. These cases should be modeled explicitly, if they are required.

12.3. Instance metadata

NIEM provides the metadata mechanism for giving information about object assertions. An object may have an attribute that refers to one or more metadata objects. A structures:metadata attribute indicates that a data item has the given metadata. A structures:relationshipMetadata attribute asserts that the link (or relationship) established by an element has the given metadata.

Figure 12-5: Example of metadata used in an instance
<nc:Person>
+</j:Witness>

NIEM-conformant data instances may use either representation as needed, to represent the meaning of the fundamental data. There is no difference in meaning between reference and content data representations. The two different methods are available for ease of representation. No difference in meaning should be implied by the use of one method or the other.

Assertions that indicate included data is intrinsic, while referenced data is extrinsic, are not valid and are not applicable to NIEM-conformant data instances and data definitions.

12.3. Instance metadata

NIEM provides the metadata mechanism for giving information about object assertions. An object may have an attribute that refers to one or more metadata objects. A structures:metadata attribute indicates that a data item has the given metadata. A structures:relationshipMetadata attribute asserts that the link (or relationship) established by an element has the given metadata.

Figure 12-6: Example of metadata used in an instance
<nc:Person>
   <nc:PersonBirthDate structures:metadata="j86">
     <nc:Date>1945-12-01</nc:Date>
   </nc:PersonBirthDate>
@@ -1473,24 +1467,24 @@
 </nc:Metadata>
 <nc:Metadata structures:id="k25">
   <nc:ProbabilityPercent>0.25</nc:ProbabilityPercent>
-</nc:Metadata>

This example shows a person named John Doe, born 12/1/1945. This data has several pieces of metadata on it:

  • Metadata s22 asserts Adam Barber gave the name.
  • Metadata j86 asserts the name and the birth date were reported on 4/26/2005.
  • Link metadata o67 asserts a 25% probability that the name goes with the person.

This shows several characteristics of metadata:

  • Metadata objects may appear outside the data they describe.
  • Metadata objects may be reused.
  • Data may refer to more than one metadata object.
  • Metadata pertains to an object or simple content, while link metadata pertains to the relationship between objects.

An instance would not be valid XML if the structures:metadata or structures:relationshipMetadata attributes contained references for which there were no defined IDs. The instance would not be NIEM-conformant if the references were not to IDs defined with the structures:id attribute.

Application of metadata to a type or element to which it is not applicable is not NIEM-conformant. A metadata element may be labeled as applicable to multiple elements via attribute appinfo:appliesToElements, or to multiple types via attribute appinfo:appliesToTypes. In either case it may apply to an instance of any of the listed elements or types. A metadata element with neither attribute appinfo:appliesToElements nor attribute appinfo:appliesToTypes may be applied to any element of any type.

Rule 12-7. Metadata applies to referring entity
[Rule 12-7] (INS) (Interpretation)

Within an element instance, when an object $O links to a metadata object via an attribute structures:metadata, the information in the metadata object MUST be applied to the object $O.

structures:metadata applies metadata to an object.

Rule 12-8. Referent of structures:relationshipMetadata annotates relationship
[Rule 12-8] (INS) (Interpretation)

Within an element instance, when an object $O1 contains an element $E, with content object $O2 or with a reference to object $O2, and $O2 links to a metadata object via an attribute structures:relationshipMetadata, the information in the metadata object MUST be applied to the relationship $E between $O1 and $O2.

structures:relationshipMetadata applies metadata to a relationship between two objects.

Rule 12-9. Values of structures:metadata refer to values of structures:id
[Rule 12-9] (INS) (Constraint)

Given that each IDREF in the value of an attribute structures:metadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.

Rule 12-10. Value of structures:relationshipMetadata refers to value of structures:id
[Rule 12-10] (INS) (Constraint)

Given that each IDREF in the value of an attribute structures:relationshipMetadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.

Rule 12-11. structures:metadata and structures:relationshipMetadata refer to metadata elements
[Rule 12-11] (INS) (Constraint)

Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a metadata element declaration.

Although not implemented in Schematron, this rule covers the cases not covered by Rule 12-12, Attribute structures:metadata references metadata element (INS), below.

Rule 12-12. Attribute structures:metadata references metadata element
[Rule 12-12] (INS) (Constraint)
<sch:pattern>
+</nc:Metadata>

This example shows a person named John Doe, born 12/1/1945. This data has several pieces of metadata on it:

  • Metadata s22 asserts Adam Barber gave the name.
  • Metadata j86 asserts the name and the birth date were reported on 4/26/2005.
  • Link metadata o67 asserts a 25% probability that the name goes with the person.

This shows several characteristics of metadata:

  • Metadata objects may appear outside the data they describe.
  • Metadata objects may be reused.
  • Data may refer to more than one metadata object.
  • Metadata pertains to an object or simple content, while link metadata pertains to the relationship between objects.

An instance would not be valid XML if the structures:metadata or structures:relationshipMetadata attributes contained references for which there were no defined IDs. The instance would not be NIEM-conformant if the references were not to IDs defined with the structures:id attribute.

Application of metadata to a type or element to which it is not applicable is not NIEM-conformant. A metadata element may be labeled as applicable to multiple elements via attribute appinfo:appliesToElements, or to multiple types via attribute appinfo:appliesToTypes. In either case it may apply to an instance of any of the listed elements or types. A metadata element with neither attribute appinfo:appliesToElements nor attribute appinfo:appliesToTypes may be applied to any element of any type.

Rule 12-11. Metadata applies to referring entity
[Rule 12-11] (INS) (Interpretation)

Within an element instance, when an object $O links to a metadata object via an attribute structures:metadata, the information in the metadata object MUST be applied to the object $O.

structures:metadata applies metadata to an object.

Rule 12-12. Referent of structures:relationshipMetadata annotates relationship
[Rule 12-12] (INS) (Interpretation)

Within an element instance, when an object $O1 contains an element $E, with content object $O2 or with a reference to object $O2, and $O2 links to a metadata object via an attribute structures:relationshipMetadata, the information in the metadata object MUST be applied to the relationship $E between $O1 and $O2.

structures:relationshipMetadata applies metadata to a relationship between two objects.

Rule 12-13. Values of structures:metadata refer to values of structures:id
[Rule 12-13] (INS) (Constraint)

Given that each IDREF in the value of an attribute structures:metadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.

Rule 12-14. Value of structures:relationshipMetadata refers to value of structures:id
[Rule 12-14] (INS) (Constraint)

Given that each IDREF in the value of an attribute structures:relationshipMetadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id.

Rule 12-15. structures:metadata and structures:relationshipMetadata refer to metadata elements
[Rule 12-15] (INS) (Constraint)

Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a metadata element declaration.

Although not implemented in Schematron, this rule covers the cases not covered by Rule 12-16, Attribute structures:metadata references metadata element (INS), below.

Rule 12-16. Attribute structures:metadata references metadata element
[Rule 12-16] (INS) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@structures:metadata)]">
     <sch:assert test="every $metadata-ref in tokenize(normalize-space(@structures:metadata), ' ') satisfies
                         exists(//*[exists(@structures:id[. = $metadata-ref])
                                    and ends-with(local-name(), 'Metadata')])"
       >Each item in the value of an attribute structures:metadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element.</sch:assert>
   </sch:rule>
-</sch:pattern>

Note that this will NOT diagnose a scenario in which the element with a name ending in Metadata is an external element; additional tests would be required to catch that.

Rule 12-13. Attribute structures:relationshipMetadata references metadata element
[Rule 12-13] (INS) (Constraint)
<sch:pattern>
+</sch:pattern>

Note that this will NOT diagnose a scenario in which the element with a name ending in Metadata is an external element; additional tests would be required to catch that.

Rule 12-17. Attribute structures:relationshipMetadata references metadata element
[Rule 12-17] (INS) (Constraint)
<sch:pattern>
   <sch:rule context="*[exists(@structures:relationshipMetadata)]">
     <sch:assert test="every $metadata-ref in tokenize(normalize-space(@structures:relationshipMetadata), ' ') satisfies
                         exists(//*[exists(@structures:id[. = $metadata-ref])
                                    and ends-with(local-name(), 'Metadata')])"
       >Each item in the value of an attribute structures:relationshipMetadata MUST appear as the value of an attribute structures:id with an owner element that is a metadata element.</sch:assert>
   </sch:rule>
-</sch:pattern>

Note that this will NOT diagnose a scenario in which the element with a name ending in Metadata is an external element; additional tests would be required to catch that.

Rule 12-14. Metadata is applicable to element
[Rule 12-14] (INS) (Constraint)

Given that an element $SUBJECT-ELEMENT uses a metadata element $METADATA-ELEMENT through a value in either an attribute structures:metadata or an attribute structures:relationshipMetadata, the element $SUBJECT-ELEMENT MUST be an applicable element for $METADATA-ELEMENT.

The applicable elements for a metadata element are identified by Rule 10-40, Metadata element has applicable elements (REF, EXT, SET), above.

Appendix A. References

[ClarkNS]: Clark, J. XML Namespaces, 4 February 1999. Available from http://www.jclark.com/xml/xmlns.htm.

[ConfReq]: Lynne Rosenthal, and Mark Skall, eds. Conformance Requirements for Specifications v1.0. The Organization for the Advancement of Structured Information Standards (OASIS), March 15, 2002. https://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf.

[CTAS]: Roberts, Webb. NIEM Conformance Targets Attribute Specification, Version 3.0. NIEM Technical Architecture Committee, July 31, 2014. http://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/NIEM-CTAS-3.0-2014-07-31.html.

[ISO 11179-4]: ISO/IEC 11179-4 Information Technology — Metadata Registries (MDR) — Part 4: Formulation of Data Definitions Second Edition, 15 July 2004. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035346_ISO_IEC_11179-4_2004(E).zip.

[ISO 11179-5]: ISO/IEC 11179-5:2005, Information technology — Metadata registries (MDR) — Part 5: Naming and identification principles. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035347_ISO_IEC_11179-5_2005(E).zip.

[JSON LD]: Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, and Niklas Lindstrom. JSON-LD 1.0, A JSON-Based Serialization for Linked Data, W3C Recommendation. Edited by Manu Sporny, Gregg Kellogg, and Markus Lanthaler. W3C, January 16, 2014. https://www.w3.org/TR/2014/REC-json-ld-20140116/.

[JLS]: James Gosling, Bill Joy, Guy Steele, Gilad Bracha, and Alex Buckley. The Java Language Specification, Java SE 8 Edition. Oracle Corp, March 3, 2014. http://docs.oracle.com/javase/specs/jls/se8/html/.

[N-ary]: Defining N-ary Relations on the Semantic Web, W3C Working Group Note, 12 April 2006. Available from http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412//.

[OED]: Oxford English Dictionary, Third Edition, Oxford University Press, November 2010. http://dictionary.oed.com/.

[RDF Concepts]: Richard Cyganiak, David Wood, and Markus Lanthaler, eds. RDF 1.1 Concepts and Abstract Syntax. The World Wide Web Consortium (W3C), February 25, 2014. http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.

[RFC 2119]: Bradner, S. Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. Available from http://www.ietf.org/rfc/rfc2119.txt.

[RFC 3986]: Berners-Lee, T., et al. Uniform Resource Identifier (URI): Generic Syntax, Request for Comments 3986, January 2005. Available from http://tools.ietf.org/html/rfc3986.

[XML]: Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation, 16 August 2006. Available from http://www.w3.org/TR/2008/REC-xml-20081126/.

[XML Base]: Jonathan Marsh, and Richard Tobin, eds. XML Base (Second Edition), W3C Recommendation. W3C, January 28, 2009. Available from http://www.w3.org/TR/2009/REC-xmlbase-20090128/.

[XML Infoset]: Cowan, John, and Richard Tobin. XML Information Set (Second Edition), 4 February 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.

[XML Namespaces]: Namespaces in XML 1.0 (Third Edition), W3C Recommendation, 8 December 2009. Available from http://www.w3.org/TR/2009/REC-xml-names-20091208/.

[XML Namespaces Errata]: Namespaces in XML Errata, 6 December 2002. Available from http://www.w3.org/XML/xml-names-19990114-errata.

[XML Schema Structures]: XML Schema Part 1: Structures Second Edition, W3C Recommendation, 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.

[XML Schema Datatypes]: XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28 October 2004. Available at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.

[Schematron]: ISO/IEC STANDARD 19757-3: Information technology — Document Schema Definition Languages (DSDL) Part 3: Rule-based validation — Schematron, ISO/IEC, 1 June 2006. Retrieved from http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip.

[XPath 2]: Berglund, Anders, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon. XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation, 3 January 2011. http://www.w3.org/TR/2010/REC-xpath20-20101214/.

Appendix B. Structures namespace
<?xml version="1.0" encoding="US-ASCII"?>
+</sch:pattern>

Note that this will NOT diagnose a scenario in which the element with a name ending in Metadata is an external element; additional tests would be required to catch that.

Rule 12-18. Metadata is applicable to element
[Rule 12-18] (INS) (Constraint)

Given that an element $SUBJECT-ELEMENT uses a metadata element $METADATA-ELEMENT through a value in either an attribute structures:metadata or an attribute structures:relationshipMetadata, the element $SUBJECT-ELEMENT MUST be an applicable element for $METADATA-ELEMENT.

The applicable elements for a metadata element are identified by Rule 10-42, Metadata element has applicable elements (REF, EXT, SET), above.

Appendix A. References

[ClarkNS]: Clark, J. XML Namespaces, 4 February 1999. Available from http://www.jclark.com/xml/xmlns.htm.

[ConfReq]: Lynne Rosenthal, and Mark Skall, eds. Conformance Requirements for Specifications v1.0. The Organization for the Advancement of Structured Information Standards (OASIS), March 15, 2002. https://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf.

[CTAS]: Roberts, Webb. NIEM Conformance Targets Attribute Specification, Version 3.0. NIEM Technical Architecture Committee, July 31, 2014. http://reference.niem.gov/niem/specification/conformance-targets-attribute/3.0/NIEM-CTAS-3.0-2014-07-31.html.

[ISO 11179-4]: ISO/IEC 11179-4 Information Technology — Metadata Registries (MDR) — Part 4: Formulation of Data Definitions Second Edition, 15 July 2004. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035346_ISO_IEC_11179-4_2004(E).zip.

[ISO 11179-5]: ISO/IEC 11179-5:2005, Information technology — Metadata registries (MDR) — Part 5: Naming and identification principles. Available from http://standards.iso.org/ittf/PubliclyAvailableStandards/c035347_ISO_IEC_11179-5_2005(E).zip.

[JSON LD]: Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, and Niklas Lindstrom. JSON-LD 1.0, A JSON-Based Serialization for Linked Data, W3C Recommendation. Edited by Manu Sporny, Gregg Kellogg, and Markus Lanthaler. W3C, January 16, 2014. https://www.w3.org/TR/2014/REC-json-ld-20140116/.

[JLS]: James Gosling, Bill Joy, Guy Steele, Gilad Bracha, and Alex Buckley. The Java Language Specification, Java SE 8 Edition. Oracle Corp, March 3, 2014. http://docs.oracle.com/javase/specs/jls/se8/html/.

[N-ary]: Defining N-ary Relations on the Semantic Web, W3C Working Group Note, 12 April 2006. Available from http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412//.

[Code Lists]: Webb Roberts. NIEM Code Lists Specification. NIEM Technical Architecture Committee (NTAC), June 20, 2016. Available from https://reference.niem.gov/niem/specification/code-lists/1.0/niem-code-lists-1.0-2016-06-20.html.

[OED]: Oxford English Dictionary, Third Edition, Oxford University Press, November 2010. http://dictionary.oed.com/.

[RDF Concepts]: Richard Cyganiak, David Wood, and Markus Lanthaler, eds. RDF 1.1 Concepts and Abstract Syntax. The World Wide Web Consortium (W3C), February 25, 2014. http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.

[RFC 2119]: Bradner, S. Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. Available from http://www.ietf.org/rfc/rfc2119.txt.

[RFC 3986]: Berners-Lee, T., et al. Uniform Resource Identifier (URI): Generic Syntax, Request for Comments 3986, January 2005. Available from http://tools.ietf.org/html/rfc3986.

[XML]: Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation, 16 August 2006. Available from http://www.w3.org/TR/2008/REC-xml-20081126/.

[XML Base]: Jonathan Marsh, and Richard Tobin, eds. XML Base (Second Edition), W3C Recommendation. W3C, January 28, 2009. Available from http://www.w3.org/TR/2009/REC-xmlbase-20090128/.

[XML Infoset]: Cowan, John, and Richard Tobin. XML Information Set (Second Edition), 4 February 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.

[XML Namespaces]: Namespaces in XML 1.0 (Third Edition), W3C Recommendation, 8 December 2009. Available from http://www.w3.org/TR/2009/REC-xml-names-20091208/.

[XML Namespaces Errata]: Namespaces in XML Errata, 6 December 2002. Available from http://www.w3.org/XML/xml-names-19990114-errata.

[XML Schema Structures]: XML Schema Part 1: Structures Second Edition, W3C Recommendation, 28 October 2004. Available from http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.

[XML Schema Datatypes]: XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28 October 2004. Available at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.

[Schematron]: ISO/IEC STANDARD 19757-3: Information technology — Document Schema Definition Languages (DSDL) Part 3: Rule-based validation — Schematron, ISO/IEC, 1 June 2006. Retrieved from http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip.

[XPath 2]: Berglund, Anders, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon. XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation, 3 January 2011. http://www.w3.org/TR/2010/REC-xpath20-20101214/.

Appendix B. Structures namespace
<?xml version="1.0" encoding="US-ASCII"?>
 <xs:schema
     targetNamespace="http://release.niem.gov/niem/structures/4.0/"
-    version="4.0alpha1"
+    version="4.0"
     xmlns:structures="http://release.niem.gov/niem/structures/4.0/"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
@@ -1503,6 +1497,7 @@
     <xs:attributeGroup name="SimpleObjectAttributeGroup">
         <xs:attribute ref="structures:id"/>
         <xs:attribute ref="structures:ref"/>
+        <xs:attribute ref="structures:uri"/>
         <xs:attribute ref="structures:metadata"/>
         <xs:attribute ref="structures:relationshipMetadata"/>
         <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
@@ -1514,6 +1509,7 @@
         </xs:sequence>
         <xs:attribute ref="structures:id"/>
         <xs:attribute ref="structures:ref"/>
+        <xs:attribute ref="structures:uri"/>
         <xs:attribute ref="structures:metadata"/>
         <xs:attribute ref="structures:relationshipMetadata"/>
         <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
@@ -1531,6 +1527,7 @@
         </xs:sequence>
         <xs:attribute ref="structures:id"/>
         <xs:attribute ref="structures:ref"/>
+        <xs:attribute ref="structures:uri"/>
         <xs:attribute ref="structures:metadata"/>
         <xs:attribute ref="structures:relationshipMetadata"/>
         <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
@@ -1545,12 +1542,14 @@
     <xs:complexType name="MetadataType" abstract="true">
         <xs:attribute ref="structures:id"/>
         <xs:attribute ref="structures:ref"/>
+        <xs:attribute ref="structures:uri"/>
         <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
     </xs:complexType>
 
     <xs:complexType name="AugmentationType" abstract="true">
         <xs:attribute ref="structures:id"/>
         <xs:attribute ref="structures:ref"/>
+        <xs:attribute ref="structures:uri"/>
         <xs:attribute ref="structures:metadata"/>
         <xs:anyAttribute namespace="urn:us:gov:ic:ism urn:us:gov:ic:ntk" processContents="lax"/>
     </xs:complexType>
@@ -1559,7 +1558,7 @@
Appendix C. Appinfo namespace
<?xml version="1.0" encoding="US-ASCII"?>
 <xs:schema
     targetNamespace="http://release.niem.gov/niem/appinfo/4.0/"
-    version="4.0alpha1"
+    version="4.0"
     xmlns:appinfo="http://release.niem.gov/niem/appinfo/4.0/"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
@@ -1647,4 +1646,4 @@
   </xs:simpleType>
 
 </xs:schema>
-
Appendix D. Index of definitions
Appendix E. Index of rules
Appendix F. General index
\ No newline at end of file +
Appendix D. Index of definitions
Appendix E. Index of rules
Appendix F. General index
\ No newline at end of file diff --git a/ndr-doc.txt b/niem-ndr-doc.txt similarity index 82% rename from ndr-doc.txt rename to niem-ndr-doc.txt index b5a8d60..6d1c7b5 100644 --- a/ndr-doc.txt +++ b/niem-ndr-doc.txt @@ -1,38 +1,38 @@ National Information Exchange Model Naming and Design Rules -Version 4.0beta1 +Version 4.0beta2 -March 31, 2017 +June 27, 2017 NIEM Technical Architecture Committee (NTAC) -Contents +Abstract - The table of contents is omitted from this edition. + This document specifies the data model, XML Schema components, and XML data for use with the National Information Exchange Model (NIEM) version 4.0. -Table of Figures +Authors - The table of figures is omitted from this edition. + Webb Roberts, Georgia Tech Research Institute (), Lead Author -Table of Tables +Status - The table of tables is omitted from this edition. + This document is a draft of the specification for XML Schema documents, components, and instances for use with NIEM 4. It presents a technical architecture that has evolved through the collaborative work of the NIEM Business Architecture Committee (NBAC), the NIEM Technical Architecture Committee (NTAC), and their predecessors. -Authors + This specification is a product of the NIEM Program Management Office (PMO). - Webb Roberts, Georgia Tech Research Institute (), Lead Author + Updates, revisions, and errata for this specification are posted to https://github.com/NIEM/NIEM-NDR. Please submit comments on this specification as issues at https://github.com/NIEM/NIEM-NDR/issues. -Abstract +Contents - This document specifies the data model, XML Schema components, and XML data for use with the National Information Exchange Model (NIEM) version 4.0. + The table of contents is omitted from this edition. -Status +Table of Figures - This document is an early draft of the specification for XML Schema documents, components, and instances for use with NIEM 4. It presents a technical architecture that has evolved through the collaborative work of the NIEM Business Architecture Committee (NBAC), the NIEM Technical Architecture Committee (NTAC), and their predecessors. + The table of figures is omitted from this edition. - This specification is a product of the NIEM Program Management Office (PMO). +Table of Tables - Send comments on this specification via email to niem-comments@lists.gatech.edu. + The table of tables is omitted from this edition. 1. Introduction @@ -46,7 +46,7 @@ Status 1.1. Scope - This document was developed to specify NIEM 3.0. Later releases of NIEM may be specified by later versions of this document. The document covers the following issues in depth: + This document was developed to specify NIEM 4.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 @@ -176,19 +176,19 @@ Status 2.4.2. Use of normative Schematron - This document defines many normative rules using Schematron rule-based validation syntax, as defined by [Schematron]. For example, see Rule 9-28, Complex type content is explicitly simple or complex. Effort has been made to make the rules precise and unambiguous. Very detailed text descriptions of rules can introduce ambiguity, and they are not directly executable by users. Providing NDR rules that are expressed as Schematron rules ensures that the rules are precise, and that they are directly executable through commercially-available and free tools. + This document defines many normative rules using Schematron rule-based validation syntax, as defined by [Schematron]. For example, see Rule 9-29, Complex type content is explicitly simple or complex. Effort has been made to make the rules precise and unambiguous. Very detailed text descriptions of rules can introduce ambiguity, and they are not directly executable by users. Providing NDR rules that are expressed as Schematron rules ensures that the rules are precise, and that they are directly executable through commercially-available and free tools. Many rules herein do not have executable Schematron supporting them. Some are not fit for automatic validation, and others may be difficult or cumbersome to express in Schematron. In neither case are such rules any less normative. A rule that has no Schematron is just as normative as a rule that does have Schematron. The level of requirements and recommendations within a rule is expressed using terminology from [RFC 2119] as described in Section 3.1, RFC 2119 terminology, below. The Schematron rules are written using XPath2 as defined by [XPath 2]. These executable rules are normative. - An execution of a Schematron pattern that issues a failed assertion (represented via sch:assert) represents a validation error, and signifies that the assessed artifact violates a requirement of a conformance rule. An example of a constraint rule that uses schematron is Rule 9-10, Simple type definition is top-level. + An execution of a Schematron pattern that issues a failed assertion (represented via sch:assert) represents a validation error, and signifies that the assessed artifact violates a requirement of a conformance rule. An example of a constraint rule that uses Schematron is Rule 9-10, Simple type definition is top-level. An execution of a Schematron pattern that issues a report (represented via sch:report) indicates cause for concern. This may be: - * An indication that the automated rules are not sufficient to validate a conformance rule, and that another means is required to ensure conformance. This is frequently a reference to another specification. For example, see Rule 9-83, Target namespace is absolute URI, which references [RFC 3986]. + * An indication that the automated rules are not sufficient to validate a conformance rule, and that another means is required to ensure conformance. This is frequently a reference to another specification. For example, see Rule 9-84, Target namespace is absolute URI, which references [RFC 3986]. - * an indication that an automated rule has found that the assessed artifact violates a recommendation of the specification (e.g., a SHOULD, rather than a MUST), and that attention should be paid to ensure that the artifact maintains the spirit of the specification. For example, see Rule 10-41, Name of element that ends in "Representation" is abstract. + * an indication that an automated rule has found that the assessed artifact violates a recommendation of the specification (e.g., a SHOULD, rather than a MUST), and that attention should be paid to ensure that the artifact maintains the spirit of the specification. For example, see Rule 10-43, Name of element that ends in "Representation" is abstract. In either case, a diagnostic report generated by testing an XML document against the Schematron rules may identify specific locations (e.g., line numbers) within the document that need further attention. @@ -237,7 +237,6 @@ Status - Note that the binding of the prefix xml to the XML namespace ("http://www.w3.org/XML/1998/namespace") is implicit. @@ -474,7 +473,7 @@ Status Any schema that defines components that are intended to be incorporated into NIEM Core or a NIEM domain will be defined as a reference schema. - The rules for reference schema documents are more stringent than are the rules for other classes of NIEM-conformant schemas. Reference schema documents are intended to support the broadest reuse. They are very uniform in their structure. As they are the primary definitions for schema components, they do not need to restrict other data definitions, and they are not allowed to use XML Schema's restriction mechanism (e.g., Rule 9-29, Complex content uses extension). Reference schema documents are intended to be as regular and simple as possible. + The rules for reference schema documents are more stringent than are the rules for other classes of NIEM-conformant schemas. Reference schema documents are intended to support the broadest reuse. They are very uniform in their structure. As they are the primary definitions for schema components, they do not need to restrict other data definitions, and they are not allowed to use XML Schema's restriction mechanism (e.g., Rule 9-30, Complex content uses extension). Reference schema documents are intended to be as regular and simple as possible. 4.1.2. Extension schema document @@ -582,13 +581,9 @@ Rule 4-3. Schema is CTAS-conformant [Rule 4-3] (REF, EXT) - - - The document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - - + The schema document MUST be a conformant document as defined by the NIEM Conformance Targets Attribute Specification. - The term "conformant document" is defined by [CTAS] Section 3.2, Conformance to this Specification. Note that this rule uses sch:report to provide a location that must be checked for conformance to an external standard, and does not itself provide any enforcement or checking of the actual rule. + The term "conformant document" is defined by [CTAS] Section 3.2, Conformance to this Specification. Rule 4-4. Document element has attribute ct:conformanceTargets @@ -657,7 +652,7 @@ Rule 4-6. Schema claims extension conformance target * 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. This meaning 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. + * NIEM's use of the RDF model provides a basis for inferring 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 this section, 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. @@ -705,7 +700,7 @@ Rule 4-6. Schema claims extension conformance target 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 defines NIEM data in XML terminology, complex types and elements, rather than using RDF terms, resources and properties. NIEM objects and associations coincide with RDF resources; both objects and associations correspond to RDF resources with additional constraints: + This NDR discusses NIEM data in XML terminology, complex types and elements, rather than using RDF terms, resources and properties. NIEM objects and associations coincide with RDF resources; both objects and associations correspond to RDF resources with additional constraints: NIEM associations are defined as n-ary properties, as described in [N-ary], "Use Case 3: N-ary relation with no distinguished participant". NIEM associations are defined in Section 10.3, Associations, below. Assertions are made via NIEM-conformant XML data, described by Section 12, XML instance document rules, below. @@ -731,11 +726,13 @@ Rule 4-6. Schema claims extension conformance target The values of URIs and IDs within NIEM XML documents are not presumed to have any particular significance. XML requires every ID to be unique within its XML document, and for every IDREF to refer to an ID within the same document. The mapping of IDs and IDREFs to URIs does not mean that the identifiers are persistent or significant. - These attributes provide the identifiers of objects. The properties of an object may be spread across several XML elements that have the same identifer. These properties must be merged together to provide all the properties of a single object, as described by [JSON LD] Section 8.2, Node Objects: + These attributes provide the identifiers of objects. The properties of an object may be spread across several XML elements that have the same identifier. These properties must be merged together to provide all the properties of a single object, as described by [JSON LD] Section 8.2, Node Objects: The properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node. - Mapping of NIEM data to RDF frequently involves the use of blank nodes, not universally-meaningful resource IRIS. + Mapping of NIEM data to RDF frequently involves the use of blank nodes, instead of universally-meaningful resource IRIs. + + The identifier of an object is constructed using the above attributes; if the above attributes do not appear on an object, then an object may be treated as a blank node, and assigned a blank node identifier. 5.5. NIEM data is explicit, not implicit @@ -745,8 +742,6 @@ Rule 4-6. Schema claims extension conformance target 5.6. Mapping of NIEM concepts to RDF concepts - This section has not yet been updated to accommodate attribute structures:uri, and the updated mappings for structures:id and structures:ref. - This section provides RDF implementations for many aspects of NIEM-conformant schemas and instance documents. 5.6.1. Resource IRIs for XML Schema components and information items @@ -755,7 +750,7 @@ Rule 4-6. Schema claims extension conformance target A qualified name is a name subject to namespace interpretation. - A Qname is used to represent a qualified name, as described by [XML Schema Datatypes] Section 3.2.18, QName, which states: + A QName is used to represent a qualified name, as described by [XML Schema Datatypes] Section 3.2.18, QName, which states: The value space of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName. @@ -773,17 +768,7 @@ Rule 4-6. Schema claims extension conformance target * schema component: the resource IRI is built from the qualified name constructed from its {target namespace} and {name} properties. -5.6.2. Blank nodes for instances and schemas - - A blank node may correspond to an occurrence of an element information item, which represents the relationship established by the element. - - A blank node may correspond to the content of an element, which represents an instance of a type. This is distinct from the occurrence of the element itself. This includes resolution of structures:ref to structures:id attributes, in which case the content of the referred-to element is considered the content of the element. - - A blank node may correspond to a combination of factors. For example, a blank node is used for each application of an element to a base object via an augmentation, as a single augmentation may be applied to multiple base objects. - - A blank node may also correspond to the above, but for attributes. - -5.6.3. RDF Literals +5.6.2. RDF Literals A simple value may be incorporated into a [conformant instance XML document] as the value of an attribute information item, or as a child of an element information item. This section describes how a simple value is mapped to an RDF literal. Note that there is no mapping for the simple content of an element that is not a [conformant element information item], nor for attributes defined by non-conformant schema documents, so there is no accommodation of mixed content, untyped values, or other cases outside of what conformant schema documents define. @@ -797,7 +782,7 @@ Rule 4-6. Schema claims extension conformance target The literal for a simple value $value is: - * If $value has a base type definition that is derived from type xs:string (and not a XML Schema-defined type derived from xs:string), and a non-empty language specification is applied to $value using xml:lang, as described by [XML] Section 2.12, Language Identification, then the literal is a language-tagged string, as described by [RDF Concepts] Section 3.3, Literals: + * If $value has a base type definition that is derived from type xs:string (and not an XML Schema-defined type derived from xs:string), and a non-empty language specification is applied to $value using xml:lang, as described by [XML] Section 2.12, Language Identification, then the literal is a language-tagged string, as described by [RDF Concepts] Section 3.3, Literals: "$lexical-form"@$language-tag @@ -823,75 +808,45 @@ Rule 4-6. Schema claims extension conformance target Where: $lexical-form is a Unicode string for $value. -5.6.4. Resolved element - - This document defines two attributes, structures:id and structures:ref that, together, define a reference mechanism for conformant elements. This enables the use of references to date in place of directly-contained data, which loops in data graphs, as well as for multiple relationships to be defined to a single object. This mechanism uses XML IDs and IDREFs as provided by the XML Schema language. As this document defines the mechanism, a structures:ref attribute may refer to a structures:id; this reference means that the element that has the structures:ref attribute refers to the element that has the structures:id attribute. - - This section defines an operation, resolving an element information item to obtain whatever element is referred to by it. This is put in terms of taking an element and finding the resolved element to which it refers. In a case where there is no reference, the resolved element is the same as the original element. - - [Definition: resolved element information item] - - Within an XML document $document, for any element information item $element there is a resolved element information item, which is: - - * If all of the following are true: - - * $document is a [conformant instance XML document]. - - * $element and $referent are [conformant element information items] within $document. - - * $element owns attribute information item structures:ref with a value $ref. - - * $referent owns attribute information item structures:id with a value $id. - - * $ref is equal to $id. - - Then the resolved element information item for $element is $referent. - - * Otherwise, the resolved element information item for $element is $element. - -5.6.5. NIEM instance mappings to RDF +5.6.3. NIEM instance mappings to RDF This section has the following subsections: - * Section 5.6.5.1, XML document mapping - * Section 5.6.5.2, Content of an element - * Section 5.6.5.3, Element as a property with unknown context - * Section 5.6.5.4, Element as a simple property of an object or association - * Section 5.6.5.5, Attribute as a simple property of an object or association - * Section 5.6.5.6, Elements via an augmentation type - * Section 5.6.5.7, Attributes via an augmentation type - * Section 5.6.5.8, Elements applied to an object via a metadata type - * Section 5.6.5.9, Attributes applied to an object via a metadata type - * Section 5.6.5.10, Elements applied to a relationship via a metadata type - * Section 5.6.5.11, Attributes applied to a relationship via a metadata type + * Section 5.6.3.1, XML document mapping + * Section 5.6.3.2, Element instance + * Section 5.6.3.3, Element as a property with unknown context + * Section 5.6.3.4, Element as a simple property of an object or association + * Section 5.6.3.5, Attribute as a simple property of an object or association + * Section 5.6.3.6, Elements via an augmentation type + * Section 5.6.3.7, Attributes via an augmentation type -5.6.5.1. XML document mapping +5.6.3.1. XML document mapping A [conformant instance XML document] entails a corresponding RDF graph, which is a set of triples, which are entailed by the mapping of the contents of the XML document to RDF. -5.6.5.2. Content of an element +5.6.3.2. Element instance A [conformant element information item] $element that has property [type definition] that is an [object type] or an [association type], entails the RDF: - $content rdf:type $type . + $object rdf:type $type . Where: - * $content is a blank node corresponding to the content of $element. + * $object is a node identifier for the object held by $element. * $type is resource IRI for the value of the [type definition] property of $element. If $element has a non-empty simple value, then it also entails the RDF: - $content rdf:value $literal . + $object rdf:value $literal . Where: - * $content is as above. + * $object is as above. - * $literal is the literal value for $element, as described in Section 5.6.3, RDF Literals, above. + * $literal is the literal value for $element, as described in Section 5.6.2, RDF Literals, above. -5.6.5.3. Element as a property with unknown context +5.6.3.3. Element as a property with unknown context A [conformant element information item] $element that @@ -901,66 +856,51 @@ Rule 4-6. Schema claims extension conformance target entails the RDF: - $element-node rdf:type rdf:Statement . - $element-node rdf:subject $blank-node . - $element-node rdf:predicate $predicate . - $element-node rdf:object $element-content-blank-node . + $context $predicate $object . Where: - * $element-node is a blank node corresponding to $element, to represent the relationship being established. - - * $blank-node is a blank node, to represent the unknown context in which $element occurs. + * $context is a blank node, to represent the unknown context in which $element occurs. * $predicate is the IRI for element information item $element, to represent the semantics of the relationship. - * $element-content-blank-node is a blank node corresponding to the content of the resolved element information item for $element. + * $object is a node identifier for the object held by $element. -5.6.5.4. Element as a simple property of an object or association +5.6.3.4. Element as a simple property of an object or association A [conformant element information item] $context that is an instance of an [object type] or [association type], and that has a child [conformant element information item] $element that is an instance of an [object type] or an [association type], entails the RDF: - $element-node rdf:type rdf:Statement . - $element-node rdf:subject $subject . - $element-node rdf:predicate $predicate . - $element-node rdf:object $object . + $subject $predicate $object . Where: - * $element-node is a blank node corresponding to $element. - - * $subject is a blank node corresponding to the content of $context. + * $subject is a node identifier for the object held by $context. * $predicate is the IRI for $element. - * $object is a blank node corresponding to the content of the [resolved element information item] for $child. + * $object is a node identifier for the object held by $element. -5.6.5.5. Attribute as a simple property of an object or association +5.6.3.5. Attribute as a simple property of an object or association An attribute information item $attribute where: * $attribute is owned by a [conformant element information item] $context that has property [type definition] that is an [object type] or an [association type], and - * $attribute has property [attribute declaration] $attribute-declaration that is defined by a [reference schema document] or an [extension schema document] + * $attribute has property [attribute declaration] that is defined by a [reference schema document] or an [extension schema document] entails the RDF: - $attribute-node rdf:type rdf:Statement . - $attribute-node rdf:subject $subject . - $attribute-node rdf:predicate $predicate . - $attribute-node rdf:object $literal . + $subject $predicate $literal . Where: - * $attribute-node is a blank node corresponding to $attribute. + * $subject is a node identifier for the object held by $context. - * $subject is a blank node corresponding to the content of $context. + * $predicate is the resource IRI for $attribute. - * $predicate is the resource IRI for $attribute-declaration. + * $literal is the literal value for $attribute, as described in Section 5.6.2, RDF Literals, above. - * $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above. - -5.6.5.6. Elements via an augmentation type +5.6.3.6. Elements via an augmentation type An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association. @@ -970,30 +910,23 @@ Rule 4-6. Schema claims extension conformance target * Element information item $augmentation that is a child of $base that has [type definition] that is an [augmentation type], - * Element information item $resolved-augmentation that is the [resolved element information item] for $augmentation, - - * Element information item $element that is a child of $resolved-augmentation, that has [type definition] that is an [object type] or an [association type], and + * Element information item $resolved-augmentation is any augmentation element with an object that has the the same node identifier as the object held by $augmentation, and - * Element information item $resolved-element that is the [resolved element information item] for $element + * Element information item $element that is a child of $resolved-augmentation, that has [type definition] that is an [object type] or an [association type]. entails the RDF: - $element-node rdf:type rdf:Statement . - $element-node rdf:subject $subject . - $element-node rdf:predicate $predicate . - $element-node rdf:object $object . + $subject $predicate $object . Where: - * $element-node is a blank node corresponding to $element applied to $base via $augmentation. - - * $subject is a blank node corresponding to the content of $base. + * $subject is the node identifier for the object held by $base. * $predicate is the resource IRI for [element declaration] of $element. - * $object is a blank node corresponding to the content of $resolved-element + * $object is the node identifier for the object held by $element -5.6.5.7. Attributes via an augmentation type +5.6.3.7. Attributes via an augmentation type An element of an augmentation type contains a set of elements and attributes that are applied to some base object or association. @@ -1003,156 +936,23 @@ Rule 4-6. Schema claims extension conformance target * Element information item $augmentation that is a child of $base that has [type definition] that is an [augmentation type], - * Element information item $resolved-augmentation that is the [resolved element information item] for $augmentation, + * Element information item $resolved-augmentation that is any augmentation element with an object that has the same node identifier as the object held by $augmentation, * Attribute information item $attribute that is owned by $resolved-augmentation, that has an [attribute declaration] that is defined by a [reference schema document] or an [extension schema document] entails the RDF: - $attribute-node rdf:type rdf:Statement . - $attribute-node rdf:subject $subject . - $attribute-node rdf:predicate $predicate . - $attribute-node rdf:object $literal . - - Where: - - * $attribute-node is a blank node corresponding to $attribute applied to $base via $augmentation. - - * $subject is a blank node corresponding to the content of $base. - - * $predicate is the resource IRI for [attribute declaration] of $attribute. - - * $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above. - -5.6.5.8. Elements applied to an object via a metadata type - - An element of a metadata type contains a set of elements and attributes that are applied to some base object or association. - - For each element applied to a type via a metadata type: - - * Element information item $base that is an instance of an [object type] or [association type], - - * Each value $metadata-idref that is a value in attribute structures:metadata owned by $base. - - * Each element information item $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metadata-idref. - - * Element information item $element that is a child of $metadata, that has [type definition] that is an [object type] or an [association type], and - - * Element information item $resolved-element that is the [resolved element information item] for $element - - entails the RDF: - - $element-node rdf:type rdf:Statement . - $element-node rdf:subject $subject . - $element-node rdf:predicate $predicate . - $element-node rdf:object $object . - - Where: - - * $element-node is a blank node corresponding to $element applied to $base via $metadata. - - * $subject is a blank node corresponding to the content of $base. - - * $predicate is the resource IRI for [element declaration] of $element. - - * $object is a blank node corresponding to the content of $resolved-element - -5.6.5.9. Attributes applied to an object via a metadata type - - An element of a metadata type contains a set of elements and attributes that are applied to some base object or association. - - For each element applied to a type via a metadata type: - - * Element information item $base that is an instance of an [object type] or [association type], - - * Each value $metadata-idref that is a value in attribute structures:metadata owned by $base. - - * Each element information item $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metadata-idref. - - * Attribute information item $attribute that is owned by $metadata, that has [attribute declaration] that is defined by a [reference schema document] or an [extension schema document] - - entails the RDF: - - $attribute-node rdf:type rdf:Statement . - $attribute-node rdf:subject $subject . - $attribute-node rdf:predicate $predicate . - $attribute-node rdf:object $literal . - - Where: - - * $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata. - - * $subject is a blank node corresponding to the content of $base. - - * $predicate is the resource IRI for [element declaration] of $element. - - * $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above. - -5.6.5.10. Elements applied to a relationship via a metadata type - - An element of a metadata type contains a set of elements and attributes that are applied to a relationship. - - For each element applied to a type via a metadata type: - - * Element information item $base that is an instance of an [object type] or [association type], - - * Each value $metadata-idref that is a value in attribute structures:relationshipMetadata owned by $base. - - * Each element information item $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metadata-idref. - - * Element information item $element that is a child of $metadata, that has [type definition] that is an [object type] or an [association type], and - - * Element information item $resolved-element that is the [resolved element information item] for $element - - entails the RDF: - - $element-node rdf:type rdf:Statement . - $element-node rdf:subject $subject . - $element-node rdf:predicate $predicate . - $element-node rdf:object $object . - - Where: - - * $element-node is a blank node corresponding to $element applied to $base via $metadata. - - * $subject is a blank node corresponding to $base. - - * $predicate is the resource IRI for [element declaration] of $element. - - * $object is a blank node corresponding to the content of $resolved-element - -5.6.5.11. Attributes applied to a relationship via a metadata type - - An element of a metadata type contains a set of elements and attributes that are applied to a relationship. - - For each element applied to a type via a metadata type: - - * Element information item $base that is an instance of an [object type] or [association type], - - * Each value $metadata-idref that is a value in attribute structures:metadata owned by $base. - - * Each element information item $metadata that has [type definition] that is a [metadata type], and has attribute structures:id with a value of $metadata-idref. - - * Attribute information item $attribute that is owned by $metadata, that has [attribute declaration] that is defined by a [reference schema document] or an [extension schema document] - - entails the RDF: - - $attribute-node rdf:type rdf:Statement . - $attribute-node rdf:subject $subject . - $attribute-node rdf:predicate $predicate . - $attribute-node rdf:object $literal . + $subject $predicate $literal . Where: - * $attribute-node is a blank node corresponding to $attribute applied to $base via $metadata. + * $subject is a node identifier for the object held by $base. - * $subject is a blank node corresponding to $base. - - * $predicate is the resource IRI for [element declaration] of $element. + * $predicate is the resource IRI for $attribute. - * $literal is the literal value for $attribute, as described in Section 5.6.3, RDF Literals, above. + * $literal is the literal value for $attribute, as described in Section 5.6.2, RDF Literals, above. -5.6.6. NIEM complex type definitions to RDF +5.6.4. NIEM complex type definitions to RDF The following RDF mappings apply to the content of a [reference schema document] or [extension schema document]. @@ -1162,17 +962,13 @@ Rule 4-6. Schema claims extension conformance target Where $resource is the resource IRI for $type. - An [object type] or [association type] $type that has property {base type definition} $base entails the RDF: + An [object type] or [association type] $type that has property {base type definition} $base also entails the RDF: - $type-resource rdfs:subClassOf $base-resource + $resource rdfs:subClassOf $base-resource - Where: - - * $type-resource is the resource IRI for $type. - - * $base-resource is the resource IRI for $base. + Where $base-resource is the resource IRI for $base. -5.6.7. NIEM element declaration mappings to RDF +5.6.5. NIEM element declaration mappings to RDF The following RDF mappings apply to the content of a [reference schema document] or [extension schema document]. @@ -1210,7 +1006,7 @@ Rule 4-6. Schema claims extension conformance target * $type-resource is the resource IRI for $type. -5.6.8. NIEM attribute declarations to RDF +5.6.6. NIEM attribute declarations to RDF The following RDF mappings apply to the content of a [reference schema document] or [extension schema document]. @@ -1282,15 +1078,15 @@ Rule 4-6. Schema claims extension conformance target 4. development of implementations supported by tools that use XML Schemas. -6.2.2. Disallow content modification with XML processors +6.2.2. Prohibit XML parsing from constructing values - XML Schema has constructs that can make the data provided by XML processors different before and after schema processing. An example 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. + XML Schema has features that can make the data provided by an XML Schema validating parser differ from that provided by a non-validating XML parser. For example, if an XML Schema attribute declaration has a default value, and if an XML document omits the attribute where it might appear, an XML Schema validating parser will construct the attribute with the default value in the infoset that it provides to its caller. Without schema validation, there would be no attribute value, but after processing, the attribute value exists in the parsed data provided to the caller. Section 8.4, Ensure XML parsing does not construct values, below, provides more detail. - Within NIEM, the purpose of processing instances against schemas is primarily validation: testing that data instances match desired constraints and guidelines. It should not be used to change the content of data instances. + Within NIEM, the purpose of processing instances against schemas is primarily validation: testing that data instances match desired constraints and guidelines. It should not be used to alter the content of data passing through the parser. [Principle 5] - The content of a NIEM-conformant data instance SHOULD NOT be modified by processing against XML Schema documents. + The data of a NIEM-conformant XML document provided by an XML parser SHOULD NOT be modified by the process of validating the data against an XML Schema. 6.2.3. Use XML validating parsers for content validation @@ -1560,11 +1356,7 @@ Rule 7-1. Document is an XML document [Rule 7-1] (REF, EXT, INS) - - - The document MUST be an XML document. - - + The document MUST be an XML document. The term [XML document] is defined by this document. @@ -1574,11 +1366,7 @@ Rule 7-2. Document uses XML namespaces properly [Rule 7-2] (REF, EXT, INS) - - - The document MUST be namespace-well-formed and namespace-valid. - - + The document MUST be namespace-well-formed and namespace-valid. The terms namespace-well-formed and namespace-valid are normatively defined by [XML Namespaces] and [XML Namespaces Errata]. @@ -1588,11 +1376,7 @@ Rule 7-3. Document is a schema document [Rule 7-3] (REF, EXT) - - - The document MUST be a schema document. - - + The document MUST be a schema document. This document defines the term [schema document]. @@ -1677,7 +1461,7 @@ Rule 7-4. Document element is xs:schema - See Rule 11-29, Data definition follows 11179-4 requirements and Rule 11-30, Data definition follows 11179-4 recommendations for application of [ISO 11179-4] to constrain NIEM [data definitions]. + See Rule 11-27, Data definition follows 11179-4 requirements and Rule 11-28, Data definition follows 11179-4 recommendations for application of [ISO 11179-4] to constrain NIEM [data definitions]. 7.5. ISO 11179 Part 5 @@ -1689,7 +1473,7 @@ Rule 7-5. Component name follows ISO 11179 Part 5 Annex A [Rule 7-5] (REF, EXT) - A NIEM component name MUST be formed by applying the informative guidelines and examples detailed in Annex A of [ISO 11179-5], with exceptions as specified in this document. + A NIEM component name SHOULD be formed by applying the informative guidelines and examples detailed in Annex A of [ISO 11179-5], with exceptions as specified in this document. The guidelines and examples of [ISO 11179-5] provide a simple, consistent syntax for data names that captures context and thereby imparts a reasonable degree of semantic precision. @@ -1717,7 +1501,7 @@ Rule 7-5. Component name follows ISO 11179 Part 5 Annex A * NIEM base types defined by the [structures namespace] incorporate xs:anyAttribute declarations, which allow the use of attributes from the ISM and NTK namespaces. See Appendix B, Structures namespace, below, for the reference schema. - * Rule 11-24, Schema uses only known attribute groups allows conformant data types to reference attribute groups defined in the ISM and NTK namespaces. + * Rule 11-22, Schema uses only known attribute groups allows conformant data types to reference attribute groups defined in the ISM and NTK namespaces. * Complex types may be constructed that use external attributes, including attributes from the ISM and NTK namespaces. Each such attribute use must be a [documented component], as specified by Rule 10-14, External attribute use has data definition. @@ -1727,7 +1511,7 @@ Rule 7-5. Component name follows ISO 11179 Part 5 Annex A 8.1. Wildcards - 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 12], above, 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. + There are many constructs within XML Schema that act as wildcards. That is, they introduce buckets that may carry arbitrary or otherwise not-validated content. Such constructs violate [Principle 12], above, 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. The following restrictions help to ban wildcards and arbitrary data: @@ -1747,37 +1531,45 @@ Rule 7-5. Component name follows ISO 11179 Part 5 Annex A * Rule 9-10, Simple type definition is top-level - * Rule 9-24, Complex type definitions is top-level + * Rule 9-25, Complex type definitions is top-level - * Rule 9-35, Element declaration is top-level + * Rule 9-36, Element declaration is top-level - * Rule 9-47, Attribute declaration is top-level + * Rule 9-48, Attribute declaration is top-level Additional restrictions ensure that NIEM components are also defined such that new components may be derived from them and substituted for them. Reference schemas are defined to maximize reuse, while extension schemas are defined to enable a developer to customize schema definitions to match her exchange needs. In reference schemas, the following restrictions help enforce reusability through extension and substitution: - * A [reference schema document] or [extension schema document] may not use blockDefault (per Rule 9-85, No disallowed substitutions) or finalDefault (per Rule 9-86, No disallowed derivations). + * A [reference schema document] or [extension schema document] may not use blockDefault (per Rule 9-86, No disallowed substitutions) or finalDefault (per Rule 9-87, No disallowed derivations). * Element declarations and type definitions in a [reference schema document] may not use block or final, per the rules: - * Rule 9-33, No complex type disallowed substitutions + * Rule 9-34, No complex type disallowed substitutions - * Rule 9-34, No complex type disallowed derivation + * Rule 9-35, No complex type disallowed derivation - * Rule 9-42, No element disallowed substitutions + * Rule 9-43, No element disallowed substitutions - * Rule 9-43, No element disallowed derivation + * Rule 9-44, No element disallowed derivation 8.3. Avoid recursive model groups 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. The rules in this document restrict the use of nested model groups, in order 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. -8.4. Ensure schema processing does not alter processed data +8.4. Ensure XML parsing does not construct values + + An XML document expresses an infoset (see [XML Infoset]); the infoset is the data carried by the XML document, and is expressed as a set of information items (e.g., element information items, attribute information items, etc.). [XML Schema Structures] Section 2.1, Overview of XML Schema describes the process followed by an XML Schema validating parser. Beyond the actions of a plain XML parser, which provides the data from an XML document to its caller in a structured way, an XML Schema validating parser does the following: + + 1. Determining local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema; + + 2. Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome. - XML Schema provides the capability for element and attribute declarations to provide default values when XML instances using those components do not provide values. This is done through the use of the attributes default and fixed, both of which provide default values to attributes and element content. + In short, not only does an XML Schema validating parser yield data from an XML document to its caller, it determines whether the XML document is valid against an XML Schema, and also provides an augmented infoset to the caller, constructed to reflect information implied by the schema, which may not appear in the original XML document. - 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 described by Section 6.2.2, Disallow content modification with XML processors, above. + XML Schema provides for element and attribute declarations to provide default values. When an XML document does not contain a value for a component that has a default, the XML Schema validating parser will construct a value for the component. This is done through the use of the attributes default and fixed, both of which provide default values to attributes and element content. An XML Schema validating parser that validates an XML document against a schema that uses default or fixed may yield an infoset that is augmented, constructing values in the provided XML infoset where none existed in the original XML document. - The transparency of validation to data content is ensured through a prohibition on the use of default and fixed attributes in NIEM-conformant schema documents. + NIEM schemas should not be constructed to yield constructed values in the infoset. The process of XML Schema validation against NIEM schemas should provide for marking data as valid or invalid, but should not modify original infoset data with constructed values. The XML infoset yielded by a non-validating XML parser should be the same as that yielded by an XML Schema validating parser. Turning on schema validation should not alter the data received by the caller of the parser. + + The prohibition of constructed values is supported by Section 6.2.2, Prohibit XML parsing from constructing values, above. It is also supported through a prohibition on all uses of default, and most uses of fixed on attributes and elements defined by NIEM-conformant schema documents. 8.5. Use namespaces rigorously @@ -1987,15 +1779,32 @@ Rule 9-12. Simple type has data definition This document defines the term [data definition]. +Rule 9-13. No use of "fixed" on simple type facets + + An attribute fixed on a constraining facet (e.g., xs:maxInclusive) of a simple type $base prevents a simple type derived from $base from further restricting that facet. For example, if simpleType nc:LatitudeDegreeSimpleType uses an xs:maxInclusive facet that limits the maximum value to 90, a simple type derived from that type could not further restrict the type to limit the maximum value to 45. + + The use of fixed on simple type facets violates [Principle 17], above, since it prevents an extension schema from constraining a base type. As a result, the fixed on simple type facets in reference schemas is prohibited. + + [Rule 9-13] (REF) + + + + A simple type constraining facet MUST NOT have an attribute {}fixed. + + + 9.1.2.1. Simple types prohibited as list item types There is no explicit prohibition on the use of xs:NOTATION as list item type, because it is prohibited by [XML Schema Datatypes]. There is no prohibition on xs:anyType as a list item type, because xs:anyType is not a simple type. -Rule 9-13. No list item type of xs:ID +Rule 9-14. No list item type of xs:ID - [Rule 9-13] (REF, EXT) + [Rule 9-14] (REF, EXT) @@ -2004,9 +1813,9 @@ Rule 9-13. No list item type of xs:ID -Rule 9-14. No list item type of xs:IDREF +Rule 9-15. No list item type of xs:IDREF - [Rule 9-14] (REF, EXT) + [Rule 9-15] (REF, EXT) @@ -2015,9 +1824,9 @@ Rule 9-14. No list item type of xs:IDREF -Rule 9-15. No list item type of xs:anySimpleType +Rule 9-16. No list item type of xs:anySimpleType - [Rule 9-15] (REF, EXT) + [Rule 9-16] (REF, EXT) @@ -2026,9 +1835,9 @@ Rule 9-15. No list item type of xs:anySimpleType -Rule 9-16. No list item type of xs:ENTITY +Rule 9-17. No list item type of xs:ENTITY - [Rule 9-16] (REF, EXT) + [Rule 9-17] (REF, EXT) @@ -2043,9 +1852,9 @@ Rule 9-16. No list item type of xs:ENTITY There is no prohibition on xs:anyType as a union member type, because xs:anyType is not a simple type. -Rule 9-17. No union member types of xs:ID +Rule 9-18. No union member types of xs:ID - [Rule 9-17] (REF, EXT) + [Rule 9-18] (REF, EXT) @@ -2056,9 +1865,9 @@ Rule 9-17. No union member types of xs:ID -Rule 9-18. No union member types of xs:IDREF +Rule 9-19. No union member types of xs:IDREF - [Rule 9-18] (REF, EXT) + [Rule 9-19] (REF, EXT) @@ -2069,9 +1878,9 @@ Rule 9-18. No union member types of xs:IDREF -Rule 9-19. No union member types of xs:IDREFS +Rule 9-20. No union member types of xs:IDREFS - [Rule 9-19] (REF, EXT) + [Rule 9-20] (REF, EXT) @@ -2082,9 +1891,9 @@ Rule 9-19. No union member types of xs:IDREFS -Rule 9-20. No union member types of xs:anySimpleType +Rule 9-21. No union member types of xs:anySimpleType - [Rule 9-20] (REF, EXT) + [Rule 9-21] (REF, EXT) @@ -2095,9 +1904,9 @@ Rule 9-20. No union member types of xs:anySimpleType -Rule 9-21. No union member types of xs:ENTITY +Rule 9-22. No union member types of xs:ENTITY - [Rule 9-21] (REF, EXT) + [Rule 9-22] (REF, EXT) @@ -2108,9 +1917,9 @@ Rule 9-21. No union member types of xs:ENTITY -Rule 9-22. No union member types of xs:ENTITIES +Rule 9-23. No union member types of xs:ENTITIES - [Rule 9-22] (REF, EXT) + [Rule 9-23] (REF, EXT) @@ -2121,9 +1930,9 @@ Rule 9-22. No union member types of xs:ENTITIES -Rule 9-23. Enumeration has data definition +Rule 9-24. Enumeration has data definition - [Rule 9-23] (REF, EXT) + [Rule 9-24] (REF, EXT) @@ -2137,9 +1946,9 @@ Rule 9-23. Enumeration has data definition 9.1.3. Complex type definition -Rule 9-24. Complex type definitions is top-level +Rule 9-25. Complex type definitions is top-level - [Rule 9-24] (REF, EXT) + [Rule 9-25] (REF, EXT) @@ -2150,9 +1959,9 @@ Rule 9-24. Complex type definitions is top-level Note that this implies that every xs:complexType element has a name attribute. -Rule 9-25. Complex type has data definition +Rule 9-26. Complex type has data definition - [Rule 9-25] (REF, EXT) + [Rule 9-26] (REF, EXT) @@ -2166,9 +1975,9 @@ Rule 9-25. Complex type has data definition 9.1.3.1. No mixed content -Rule 9-26. No mixed content on complex type +Rule 9-27. No mixed content on complex type - [Rule 9-26] (REF, EXT) + [Rule 9-27] (REF, EXT) @@ -2181,9 +1990,9 @@ Rule 9-26. No mixed content on complex type Well-defined markup languages exist outside NIEM and may be used with NIEM data. External schema documents 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 10], above. -Rule 9-27. No mixed content on complex content +Rule 9-28. No mixed content on complex content - [Rule 9-27] (REF, EXT) + [Rule 9-28] (REF, EXT) @@ -2192,11 +2001,11 @@ Rule 9-27. No mixed content on complex content - See Rule 9-26, No mixed content on complex type for the rationale for this rule. + See Rule 9-27, No mixed content on complex type for the rationale for this rule. -Rule 9-28. Complex type content is explicitly simple or complex +Rule 9-29. Complex type content is explicitly simple or complex - [Rule 9-28] (REF, EXT) + [Rule 9-29] (REF, EXT) @@ -2209,9 +2018,9 @@ Rule 9-28. Complex type content is explicitly simple or complex 9.1.3.2. Complex content -Rule 9-29. Complex content uses extension +Rule 9-30. Complex content uses extension - [Rule 9-29] (REF) + [Rule 9-30] (REF) @@ -2239,9 +2048,9 @@ Rule 9-29. Complex content uses extension The first rule handles cases that can be determined within a single schema document, while the SET version handles cases that require cross-schema resolution. -Rule 9-30. Base type of complex type with complex content must have complex content +Rule 9-31. Base type of complex type with complex content must have complex content - [Rule 9-30] (REF, EXT) + [Rule 9-31] (REF, EXT) @@ -2286,9 +2095,9 @@ Rule 9-32. Simple content uses extension This rule ensures that the definition of a complex type with simple content will use XML Schema extension. This allows for the above cases while disallowing more complicated syntactic options available in XML Schema. The above rule allows for use of xs:restriction within xs:simpleContent in extension schemas. -Rule 9-33. No complex type disallowed substitutions +Rule 9-34. No complex type disallowed substitutions - [Rule 9-33] (REF) + [Rule 9-34] (REF) @@ -2297,9 +2106,9 @@ Rule 9-33. No complex type disallowed substitutions -Rule 9-34. No complex type disallowed derivation +Rule 9-35. No complex type disallowed derivation - [Rule 9-34] (REF) + [Rule 9-35] (REF) @@ -2314,13 +2123,13 @@ Rule 9-34. No complex type disallowed derivation Every element declaration in a NIEM-conformant schema document is a top-level element; rules prohibit the declaration of local elements. - Within a NIEM-conformant schema document, an element may be declared as abstract. Elements may be defined without a type, but any element declaration that has no type must be declared abstract, as specified by Rule 9-37, Untyped element is abstract. + Within a NIEM-conformant schema document, an element may be declared as abstract. Elements may be defined without a type, but any element declaration that has no type must be declared abstract, as specified by Rule 9-38, Untyped element is abstract. - Within an element declaration, the attributes fixed, nillable, and substitutionGroup may be used as per the XML Schema specification. The attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local element declarations, as specified by Rule 9-35, Element declaration is top-level. + Within an element declaration, the attributes fixed, nillable, and substitutionGroup may be used as per the XML Schema specification. The attribute form is irrelevant to NIEM, as NIEM-conformant schemas may not contain local element declarations, as specified by Rule 9-36, Element declaration is top-level. -Rule 9-35. Element declaration is top-level +Rule 9-36. Element declaration is top-level - [Rule 9-35] (REF, EXT) + [Rule 9-36] (REF, EXT) @@ -2331,9 +2140,9 @@ Rule 9-35. Element declaration is top-level All schema components defined by NIEM-conformant schemas must be named, accessible from outside the defining schema, and reusable across schemas. Local element declarations 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. -Rule 9-36. Element declaration has data definition +Rule 9-37. Element declaration has data definition - [Rule 9-36] (REF, EXT) + [Rule 9-37] (REF, EXT) @@ -2345,9 +2154,9 @@ Rule 9-36. Element declaration has data definition This document defines the term [data definition]. -Rule 9-37. Untyped element is abstract +Rule 9-38. Untyped element is abstract - [Rule 9-37] (REF, EXT) + [Rule 9-38] (REF, EXT) @@ -2359,11 +2168,11 @@ Rule 9-37. Untyped element is abstract 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. -Rule 9-38. Element of type xs:anySimpleType is abstract +Rule 9-39. Element of type xs:anySimpleType is abstract The type xs:anySimpleType does not have any concrete semantics; The use of xs:anySimpleType is limited to the case where an abstract element is of type xs:anySimpleType, to act as a base for concrete implementations of the element. - [Rule 9-38] (REF, EXT) + [Rule 9-39] (REF, EXT) @@ -2389,11 +2198,11 @@ Rule 9-39. Element type not in the XML Schema namespace The prohibition of element types having the XML Schema namespace subsumes a prohibition of the type xs:anyType. -Rule 9-40. Element type not in the XML namespace +Rule 9-41. Element type not in the XML namespace The XML namespace may be imported into a conformant schema document as if it were conformant. This specification does not enable a reference to any types that may be defined by any implementation of a schema for that namespace. - [Rule 9-40] (REF, EXT) + [Rule 9-41] (REF, EXT) @@ -2402,9 +2211,9 @@ Rule 9-40. Element type not in the XML namespace -Rule 9-41. Element type is not simple type +Rule 9-42. Element type is not simple type - [Rule 9-41] (REF, EXT) + [Rule 9-42] (REF, EXT) @@ -2421,9 +2230,9 @@ Rule 9-41. Element type is not simple type -Rule 9-42. No element disallowed substitutions +Rule 9-43. No element disallowed substitutions - [Rule 9-42] (REF) + [Rule 9-43] (REF) @@ -2432,9 +2241,9 @@ Rule 9-42. No element disallowed substitutions -Rule 9-43. No element disallowed derivation +Rule 9-44. No element disallowed derivation - [Rule 9-43] (REF) + [Rule 9-44] (REF) @@ -2445,9 +2254,9 @@ Rule 9-43. No element disallowed derivation 9.2.1.1. No element value constraints -Rule 9-44. No element default value +Rule 9-45. No element default value - [Rule 9-44] (REF, EXT) + [Rule 9-45] (REF, EXT) @@ -2456,9 +2265,9 @@ Rule 9-44. No element default value -Rule 9-45. No element fixed value +Rule 9-46. No element fixed value - [Rule 9-45] (REF, EXT) + [Rule 9-46] (REF, EXT) @@ -2467,13 +2276,13 @@ Rule 9-45. No element fixed value -Rule 9-46. Element declaration is nillable +Rule 9-47. Element declaration is nillable - All elements declared by reference schemas allow a nil value. This enables the ID/IDREF mechanism linking structures:ref and structures:id, as described by Section 12.2, Reference elements, below. + All elements declared by reference schemas allow a nil value. This enables the ID/IDREF mechanism linking structures:ref and structures:id, as described by Section 12.2, Identifiers and references, below. A developer may constrain the use of nil in an instance by setting nillable to false in subset schemas, or by use of non-XML Schema mechanisms, such as Schematron. - [Rule 9-46] (REF) + [Rule 9-47] (REF) @@ -2507,9 +2316,9 @@ Rule 9-47. Attribute declaration is top-level All schema components defined by NIEM-conformant schemas are named, accessible from outside the defining schema, and reusable across schemas. Local attribute declarations 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. -Rule 9-48. Attribute declaration has data definition +Rule 9-49. Attribute declaration has data definition - [Rule 9-48] (REF, EXT) + [Rule 9-49] (REF, EXT) @@ -2521,9 +2330,9 @@ Rule 9-48. Attribute declaration has data definition This document defines the term [data definition]. -Rule 9-49. Attribute declaration has type +Rule 9-50. Attribute declaration has type - [Rule 9-49] (REF, EXT) + [Rule 9-50] (REF, EXT) @@ -2540,9 +2349,9 @@ Rule 9-49. Attribute declaration has type These types are only explicitly prohibited from attributes, not elements, because the case is covered by a general prohibition against elements having simple types. -Rule 9-50. No attribute type of xs:ID +Rule 9-51. No attribute type of xs:ID - [Rule 9-50] (REF, EXT) + [Rule 9-51] (REF, EXT) @@ -2551,9 +2360,9 @@ Rule 9-50. No attribute type of xs:ID -Rule 9-51. No attribute type of xs:IDREF +Rule 9-52. No attribute type of xs:IDREF - [Rule 9-51] (REF, EXT) + [Rule 9-52] (REF, EXT) @@ -2562,9 +2371,9 @@ Rule 9-51. No attribute type of xs:IDREF -Rule 9-52. No attribute type of xs:IDREFS +Rule 9-53. No attribute type of xs:IDREFS - [Rule 9-52] (REF, EXT) + [Rule 9-53] (REF, EXT) @@ -2573,9 +2382,9 @@ Rule 9-52. No attribute type of xs:IDREFS -Rule 9-53. No attribute type of xs:ENTITY +Rule 9-54. No attribute type of xs:ENTITY - [Rule 9-53] (REF, EXT) + [Rule 9-54] (REF, EXT) @@ -2584,9 +2393,9 @@ Rule 9-53. No attribute type of xs:ENTITY -Rule 9-54. No attribute type of xs:ENTITIES +Rule 9-55. No attribute type of xs:ENTITIES - [Rule 9-54] (REF, EXT) + [Rule 9-55] (REF, EXT) @@ -2595,9 +2404,9 @@ Rule 9-54. No attribute type of xs:ENTITIES -Rule 9-55. No attribute type of xs:anySimpleType +Rule 9-56. No attribute type of xs:anySimpleType - [Rule 9-55] (REF, EXT) + [Rule 9-56] (REF, EXT) @@ -2608,9 +2417,9 @@ Rule 9-55. No attribute type of xs:anySimpleType 9.2.3.2. No attribute value constraints -Rule 9-56. No attribute default values +Rule 9-57. No attribute default values - [Rule 9-56] (REF, EXT) + [Rule 9-57] (REF, EXT) @@ -2619,26 +2428,35 @@ Rule 9-56. No attribute default values - This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above. + This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure XML parsing does not construct values, above. -Rule 9-57. No attribute fixed values +Rule 9-58. No attribute fixed values - [Rule 9-57] (REF, EXT) + The fixed attribute is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component: + + default specifies that the attribute is to appear unconditionally in the post-schema-validation infoset, with the supplied value used whenever the attribute is not actually present; fixed indicates that the attribute value if present must equal the supplied constraint value, and if absent receives the supplied value as for default. + + + + [Rule 9-58] (REF, EXT) + + This rule does not constrain attribute uses that are required + An element xs:attribute MUST NOT have an attribute {}fixed. + >An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed. - This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure schema processing does not alter processed data, above. The use of the fixed attribute may result in alteration of the post-schema-validation infoset, like the use of default does. This behavior is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component. + This rule helps to ensure that schema processing does not alter processed data, as described in Section 8.4, Ensure XML parsing does not construct values, above. The use of the fixed attribute may result in alteration of the post-schema-validation infoset, like the use of default does. This behavior is described by [XML Schema Structures] Section 3.2.1, The Attribute Declaration Schema Component. 9.2.4. Notation declaration -Rule 9-58. No use of element xs:notation +Rule 9-59. No use of element xs:notation - [Rule 9-58] (REF, EXT) + [Rule 9-59] (REF, EXT) @@ -2657,15 +2475,15 @@ Rule 9-58. No use of element xs:notation XML Schema defines a particle as an occurrence of xs:element, xs:sequence, xs:choice, xs:any (wildcard) and xs:group (model group) within a content model. For example, an xs:sequence within an XML Schema complex type is a particle. An xs:element occurring within an xs:sequence is also a particle. -Rule 9-59. Model group does not affect meaning +Rule 9-60. Model group does not affect meaning - [Rule 9-59] (EXT) + [Rule 9-60] (EXT) The use of model groups xs:all, xs:sequence, and xs:choice MUST NOT define the semantics of an instance. The meaning of an element occurrence within an element occurrence MUST be identical, regardless of the model group used to define a [schema component]. -Rule 9-60. No xs:all +Rule 9-61. No xs:all - [Rule 9-60] (REF, EXT) + [Rule 9-61] (REF, EXT) @@ -2678,9 +2496,9 @@ Rule 9-60. No xs:all 9.3.1.1. Sequence -Rule 9-61. xs:sequence must be child of xs:extension +Rule 9-62. xs:sequence must be child of xs:extension - [Rule 9-61] (REF) + [Rule 9-62] (REF) @@ -2689,9 +2507,9 @@ Rule 9-61. xs:sequence must be child of xs:extension -Rule 9-62. xs:sequence must be child of xs:extension or xs:restriction +Rule 9-63. xs:sequence must be child of xs:extension or xs:restriction - [Rule 9-62] (EXT) + [Rule 9-63] (EXT) @@ -2702,9 +2520,9 @@ Rule 9-62. xs:sequence must be child of xs:extension or xs:restriction 9.3.1.2. Choice -Rule 9-63. No xs:choice +Rule 9-64. No xs:choice - [Rule 9-63] (REF) + [Rule 9-64] (REF) @@ -2717,9 +2535,9 @@ Rule 9-63. No xs:choice The element xs:choice may be used in extension schemas, as it presents a simple way for a schema writer to represent a set of optional content. -Rule 9-64. xs:choice must be child of xs:sequence +Rule 9-65. xs:choice must be child of xs:sequence - [Rule 9-64] (EXT) + [Rule 9-65] (EXT) @@ -2740,9 +2558,9 @@ Rule 9-64. xs:choice must be child of xs:sequence A schema developer who requires the instance syntax that would be obtained from the use of specific cardinality on sequences should define cardinality on individual element uses. -Rule 9-65. Sequence has minimum cardinality 1 +Rule 9-66. Sequence has minimum cardinality 1 - [Rule 9-65] (REF, EXT) + [Rule 9-66] (REF, EXT) @@ -2751,9 +2569,9 @@ Rule 9-65. Sequence has minimum cardinality 1 -Rule 9-66. Sequence has maximum cardinality 1 +Rule 9-67. Sequence has maximum cardinality 1 - [Rule 9-66] (REF, EXT) + [Rule 9-67] (REF, EXT) @@ -2765,9 +2583,9 @@ Rule 9-66. Sequence has maximum cardinality 1 9.3.2.2. Choice cardinality -Rule 9-67. Choice has minimum cardinality 1 +Rule 9-68. Choice has minimum cardinality 1 - [Rule 9-67] (EXT) + [Rule 9-68] (EXT) @@ -2776,9 +2594,9 @@ Rule 9-67. Choice has minimum cardinality 1 -Rule 9-68. Choice has maximum cardinality 1 +Rule 9-69. Choice has maximum cardinality 1 - [Rule 9-68] (EXT) + [Rule 9-69] (EXT) @@ -2794,9 +2612,9 @@ Rule 9-68. Choice has maximum cardinality 1 9.3.4. Wildcard -Rule 9-69. No use of xs:any +Rule 9-70. No use of xs:any - [Rule 9-69] (REF) + [Rule 9-70] (REF) @@ -2807,9 +2625,9 @@ Rule 9-69. No use of xs:any The xs:any particle (see Model Group Restrictions for an informative definition of particle) provides a wildcard that may carry arbitrary content. The particle xs:any may appear within an [extension schema document]. -Rule 9-70. No use of xs:anyAttribute +Rule 9-71. No use of xs:anyAttribute - [Rule 9-70] (REF) + [Rule 9-71] (REF) @@ -2826,9 +2644,9 @@ Rule 9-70. No use of xs:anyAttribute Note that there is no prohibition on the use of xs:selector and xs:field, since according to the rules of the [XML Schema definition language], they can only appear within xs:key, xs:keyref, and xs:unique, which are themselves prohibited. -Rule 9-71. No use of xs:unique +Rule 9-72. No use of xs:unique - [Rule 9-71] (REF, EXT) + [Rule 9-72] (REF, EXT) @@ -2837,9 +2655,9 @@ Rule 9-71. No use of xs:unique -Rule 9-72. No use of xs:key +Rule 9-73. No use of xs:key - [Rule 9-72] (REF, EXT) + [Rule 9-73] (REF, EXT) @@ -2848,9 +2666,9 @@ Rule 9-72. No use of xs:key -Rule 9-73. No use of xs:keyref +Rule 9-74. No use of xs:keyref - [Rule 9-73] (REF, EXT) + [Rule 9-74] (REF, EXT) @@ -2863,9 +2681,9 @@ Rule 9-73. No use of xs:keyref 9.5.1. Model group definition -Rule 9-74. No use of xs:group +Rule 9-75. No use of xs:group - [Rule 9-74] (REF, EXT) + [Rule 9-75] (REF, EXT) @@ -2878,11 +2696,11 @@ Rule 9-74. No use of xs:group 9.5.2. Attribute group definition -Rule 9-75. No definition of attribute groups +Rule 9-76. No definition of attribute groups - Per Rule 11-24, Schema uses only known attribute groups, the only attribute groups used in NIEM-conformant schemas are structures:SimpleObjectAttributeGroup and attribute groups defined by the IC-ISM and IC-NTK schemas. Therefore, NIEM-conformant schemas do not define additional attribute groups. + Per Rule 11-22, Schema uses only known attribute groups, the only attribute groups used in NIEM-conformant schemas are structures:SimpleObjectAttributeGroup and attribute groups defined by the IC-ISM and IC-NTK schemas. Therefore, NIEM-conformant schemas do not define additional attribute groups. - [Rule 9-75] (REF, EXT) + [Rule 9-76] (REF, EXT) @@ -2893,11 +2711,11 @@ Rule 9-75. No definition of attribute groups 9.6. Annotation components -Rule 9-76. Comment is not recommended +Rule 9-77. Comment is not recommended Note that this rule is written with a context that is not as precise as it could be. Its context is the parent node of the comment node, in order to avoid error messages when executed with common Schematron implementations. - [Rule 9-76] (REF, EXT) + [Rule 9-77] (REF, EXT) @@ -2908,9 +2726,9 @@ Rule 9-76. Comment is not recommended Since XML comments are not associated with any specific XML Schema construct, there is no standard way to interpret comments. XML Schema annotations should be preferred for meaningful information about components. NIEM specifically defines how information should be encapsulated in NIEM-conformant schemas via xs:annotation elements. -Rule 9-77. Documentation element has no element children +Rule 9-78. Documentation element has no element children - [Rule 9-77] (REF, EXT) + [Rule 9-78] (REF, EXT) @@ -2923,9 +2741,9 @@ Rule 9-77. Documentation element has no element children XML Schema provides special annotations for support of automatic processing. The XML Schema specification provides the element xs:appinfo to carry such content and does not specify what style of content they should carry. In NIEM, xs:appinfo elements carry structured XML content. -Rule 9-78. xs:appinfo children are comments, elements, or whitespace +Rule 9-79. xs:appinfo children are comments, elements, or whitespace - [Rule 9-78] (REF, EXT) + [Rule 9-79] (REF, EXT) @@ -2938,9 +2756,9 @@ Rule 9-78. xs:appinfo children are comments, elements, or whitespace Application information elements are intended for automatic processing; the meaning of an appinfo annotation is provided via elements. -Rule 9-79. Appinfo child elements have namespaces +Rule 9-80. Appinfo child elements have namespaces - [Rule 9-79] (REF, EXT) + [Rule 9-80] (REF, EXT) @@ -2951,9 +2769,9 @@ Rule 9-79. Appinfo child elements have namespaces The XML namespaces specification includes the concept of content not in a namespace. Use of elements without namespaces can lead to conflicting data definitions, and makes it difficult to identify relevant data definitions. -Rule 9-80. Appinfo descendants are not XML Schema elements +Rule 9-81. Appinfo descendants are not XML Schema elements - [Rule 9-80] (REF, EXT) + [Rule 9-81] (REF, EXT) @@ -2968,9 +2786,9 @@ Rule 9-80. Appinfo descendants are not XML Schema elements The XML Schema language defines that the document element xs:schema may contain the optional attributes attributeFormDefault and elementFormDefault. The values of these attributes are not material to a conformant schema, as each attribute and element defined by a conformant schema is defined as a top-level component, and so each is qualified by its target namespace. -Rule 9-81. Schema has data definition +Rule 9-82. Schema has data definition - [Rule 9-81] (REF, EXT) + [Rule 9-82] (REF, EXT) @@ -2980,9 +2798,9 @@ Rule 9-81. Schema has data definition -Rule 9-82. Schema document defines target namespace +Rule 9-83. Schema document defines target namespace - [Rule 9-82] (REF, EXT) + [Rule 9-83] (REF, EXT) @@ -2993,20 +2811,15 @@ Rule 9-82. Schema document defines target namespace Schemas without defined namespaces provide definitions that are ambiguous, in that they are not universally identifiable. -Rule 9-83. Target namespace is absolute URI +Rule 9-84. Target namespace is absolute URI - [Rule 9-83] (REF, EXT) + [Rule 9-84] (REF, EXT) - - - as defined by RFC 3986.]]> - - + The value of the attribute targetNamespace MUST match the production as defined by RFC 3986. 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. is a grammar production defined by [RFC 3986] Section 4.3, Absolute URI. -Rule 9-84. Schema has version +Rule 9-85. Schema has version 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: @@ -3022,7 +2835,7 @@ Rule 9-84. Schema has version An author of an application schema or exchange may use the version attribute for these purposes within their schemas. - [Rule 9-84] (REF, EXT) + [Rule 9-85] (REF, EXT) @@ -3032,9 +2845,9 @@ Rule 9-84. Schema has version -Rule 9-85. No disallowed substitutions +Rule 9-86. No disallowed substitutions - [Rule 9-85] (REF) + [Rule 9-86] (REF) @@ -3043,9 +2856,9 @@ Rule 9-85. No disallowed substitutions -Rule 9-86. No disallowed derivations +Rule 9-87. No disallowed derivations - [Rule 9-86] (REF) + [Rule 9-87] (REF) @@ -3056,9 +2869,9 @@ Rule 9-86. No disallowed derivations 9.8. Schema assembly -Rule 9-87. No use of xs:redefine +Rule 9-88. No use of xs:redefine - [Rule 9-87] (REF, EXT) + [Rule 9-88] (REF, EXT) @@ -3069,9 +2882,9 @@ Rule 9-87. No use of xs:redefine The xs:redefine element allows an XML Schema document to restrict and extend components from a namespace, in a separate schema document from the one that initially defined that namespace. Such redefinition introduces duplication of definitions, allowing multiple definitions to exist for components from a single namespace. This violates [Principle 9], above, that a single reference schema defines a NIEM-conformant namespace. -Rule 9-88. No use of xs:include +Rule 9-89. No use of xs:include - [Rule 9-88] (REF, EXT) + [Rule 9-89] (REF, EXT) @@ -3084,9 +2897,9 @@ Rule 9-88. No use of xs:include 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 9], above, as it uses multiple schemas to construct a namespace. -Rule 9-89. xs:import must have namespace +Rule 9-90. xs:import must have namespace - [Rule 9-89] (REF, EXT) + [Rule 9-90] (REF, EXT) @@ -3095,13 +2908,13 @@ Rule 9-89. xs:import must have namespace - An import that does not specify a namespace is enabling references 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. + An import that does not specify a namespace is enabling references to components without namespaces. NIEM requires that all components have a defined namespace. It is important that the namespace declared by a schema be universally defined and unambiguous. -Rule 9-90. XML Schema document set must be complete +Rule 9-91. XML Schema document set must be complete An [XML Schema document set] defines an [XML Schema] that may be used to validate an [XML document]. This rule ensures that a schema document set under consideration contains definitions for everything that it references; it has everything necessary to do a complete validation of XML documents, without any unresolved references. Note that some tools may allow validation of documents using partial schemas, when components that are not present are not exercised by the XML document under validation. Such a schema does not meet qualify as a [conformant schema document set]. - [Rule 9-90] (SET) + [Rule 9-91] (SET) The schema document set must constitute a complete XML Schema; it must contain the definition of every schema component referenced by any component defined by the schema set. @@ -3111,9 +2924,9 @@ Rule 9-90. XML Schema document set must be complete Some tools do not enforce this constraint; one such tool carries imports from a [schema document] into [schema documents] that it imports. This has the potential to introduce incompatibility into schema documents and schema document sets that exercise this bug. To maintain compatibility across tool sets, this requirement is an explicit rule for NIEM-conformant schemas. -Rule 9-91. Namespace referenced by attribute type is imported +Rule 9-92. Namespace referenced by attribute type is imported - [Rule 9-91] (REF, EXT) + [Rule 9-92] (REF, EXT) @@ -3125,9 +2938,9 @@ Rule 9-91. Namespace referenced by attribute type is imported -Rule 9-92. Namespace referenced by attribute base is imported +Rule 9-93. Namespace referenced by attribute base is imported - [Rule 9-92] (REF, EXT) + [Rule 9-93] (REF, EXT) @@ -3139,9 +2952,9 @@ Rule 9-92. Namespace referenced by attribute base is imported -Rule 9-93. Namespace referenced by attribute itemType is imported +Rule 9-94. Namespace referenced by attribute itemType is imported - [Rule 9-93] (REF, EXT) + [Rule 9-94] (REF, EXT) @@ -3153,9 +2966,9 @@ Rule 9-93. Namespace referenced by attribute itemType is imported -Rule 9-94. Namespaces referenced by attribute memberTypes is imported +Rule 9-95. Namespaces referenced by attribute memberTypes is imported - [Rule 9-94] (REF, EXT) + [Rule 9-95] (REF, EXT) @@ -3168,9 +2981,9 @@ Rule 9-94. Namespaces referenced by attribute memberTypes is imported -Rule 9-95. Namespace referenced by attribute ref is imported +Rule 9-96. Namespace referenced by attribute ref is imported - [Rule 9-95] (REF, EXT) + [Rule 9-96] (REF, EXT) @@ -3181,9 +2994,9 @@ Rule 9-95. Namespace referenced by attribute ref is imported -Rule 9-96. Namespace referenced by attribute substitutionGroup is imported +Rule 9-97. Namespace referenced by attribute substitutionGroup is imported - [Rule 9-96] (REF, EXT) + [Rule 9-97] (REF, EXT) @@ -3295,7 +3108,7 @@ Rule 10-2. Object type with complex content is derived from object type - A [base type definition] with a {target namespace} that is the XML namespace is prohibited by Rule 9-1, No base type in the XML namespace. A [base type definition] with a {target namespace} that is not imported as conformant is prohibited by Rule 11-3, Base type definition defined by conformant schema. + A [base type definition] with a {target namespace} that is the XML namespace is prohibited by Rule 9-1, No base type in the XML namespace. A [base type definition] with a {target namespace} that is not imported as conformant is prohibited by Rule 11-2, Base type definition defined by conformant schema. 10.2.2. Role types and roles @@ -3413,7 +3226,7 @@ Rule 10-3. RoleOf element type is an object type - Note that by Rule 11-14, Element type is from conformant namespace, the element's type must be from a conformant namespace. + Note that by Rule 11-12, Element type is from conformant namespace, the element's type must be from a conformant namespace. Rule 10-4. Only object type has RoleOf element @@ -3488,7 +3301,7 @@ Rule 10-6. Instance of RoleOf element indicates a role object To construct such a component, a NIEM-conformant schema must import the namespace defined by the [external schema document]. - Rule 11-36, Reference schema imports reference schema and Rule 11-37, Extension schema document imports reference or extension schema require that xs:import elements be consistent with an importing [schema document]. + Rule 11-48, Reference schema imports reference schema and Rule 11-49, Extension schema document imports reference or extension schema require that xs:import elements be consistent with an importing [schema document]. A NIEM-conformant schema has well-known documentation points. Therefore, a schema that imports a NIEM-conformant namespace need not provide additional documentation. However, when an external schema document is imported, appropriate documentation must be provided at the point of import because documentation associated with external schema documents is undefined and variable. In this particular case, documentation of external schema documents is required at their point of use in NIEM. @@ -3659,38 +3472,56 @@ Rule 10-16. External element use has data definition [Definition: code type] - A code type is a NIEM object type with a content model that is constrained by one or more enumeration facets. + A code type is a NIEM object type for which each simple value carried by the type corresponds to an entry in a list of distinct conceptual entities. These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals. + Many code types have simple content composed of xs:enumeration values. Code types may also be constructed using the NIEM Code Lists Specification [Code Lists], which supports code lists defined using a variety of methods, including CSV spreadsheets. + Rule 10-17. Name of code type ends in "CodeType" [Rule 10-17] (REF, EXT) - - - - A complex type definition MUST have a {name} that ends in 'CodeType' if and only if it has a {base type definition} of a code type or code simple type. + + A complex type definition with a {base type definition} of a code type or code simple type SHOULD have a {name} that ends in 'CodeType'. - Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values. + See Section 11.1.2.3, Code simple types, below, for the definition of [code simple type]. + +Rule 10-18. Code type corresponds to a code list + + [Rule 10-18] (REF, EXT) + + A complex type SHOULD have a name ending in "CodeType" if and only if it has a correspondence to a list of distinct conceptual entities. + +Rule 10-19. Element of code type has code representation term + + [Rule 10-19] (REF, EXT) + + + + An element with a type that is a code type SHOULD have a name with representation term "Code" + + + + Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies that a data component may carry values from a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values. 10.2.5. Proxy types - The NIEM 3.0 release schema niem/proxy/xsd/3.0/xs.xsd provides complex type bases for some of the simple types in the XML Schema namespace. The complex types in this schema reuse the local names of the XML Schema simple types they extend, even though those names don't follow the naming structure of most conformant complex types. There is a special exception to naming rules to allow the reuse of the XML Schema simple type names in conformant schemas. This is done to make conformant schemas more understandable to people that are familiar with the names of the XML Schema namespace simple types. + The NIEM 4.0 release schema niem/proxy/xsd/4.0/xs.xsd provides complex type bases for some of the simple types in the XML Schema namespace. The complex types in this schema reuse the local names of the XML Schema simple types they extend, even though those names don't follow the naming structure of most conformant complex types. There is a special exception to naming rules to allow the reuse of the XML Schema simple type names in conformant schemas. This is done to make conformant schemas more understandable to people that are familiar with the names of the XML Schema namespace simple types. A complex type that is a direct extension of a simple type from the XML Schema namespace (e.g., xs:string, xs:integer, xs:boolean) is allowed to have the same local name as the XML Schema simple type, if and only if the extension adds no content other than the attribute group structures:SimpleObjectAttributeGroup. This allows for an intuitive name when using an XML Schema simple type in a conformant schema. -Rule 10-18. Proxy type has designated structure +Rule 10-20. Proxy type has designated structure - [Rule 10-18] (REF, EXT) + [Rule 10-20] (REF, EXT) @@ -3787,9 +3618,9 @@ Rule 10-19. Association type is derived from association type 10.3.2. Association element declarations -Rule 10-20. Association element type is an association type +Rule 10-22. Association element type is an association type - [Rule 10-20] (REF, EXT) + [Rule 10-22] (REF, EXT) @@ -3817,11 +3648,9 @@ Rule 10-20. Association element type is an association type * It results in numerous, domain-specific specializations of nc:PersonType, each with common content and extension-specific content. - * There is no method for the developer of an information exchange specification (IES) to bring these types back together into a single type that carries the attributes desired for the IES. XML Schema does not support multiple inheritance, so there is no way to join together j:PersonType, im:PersonType, and cyfs:PersonType. - - * There is no standard or easy way for the developer to express that the various element instances of the various person types represent the same person, or which parts of those instances are required to be populated; does each person restate the name and birthdate, or is that handled by just one instance? + * There is no method for the developer of an information exchange package description (IEPD) to bring these types back together into a single type that carries the attributes desired for the IEPD. XML Schema does not support multiple inheritance, so there would be no way to join together nc:PersonType, j:PersonType, and im:PersonType. - * A domain, having created its own j:PersonType that extends nc:PersonType, is, of course, going to create elements of that type. These elements will not be easily reused by other domains, as the Immigration namespace will want to use im:PersonType instead of j:PersonType. + * There is no standard or easy way for the developer to express that the various element instances of the various person types represent the same person, or which parts of those instances are required to be populated; does each person restate the name and birth-date, or is that handled by just one instance? This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community. @@ -3835,7 +3664,7 @@ Rule 10-20. Association element type is an association type * A developer of a domain or other schema that extends common types may define elements that are substitutable for an augmentation point. Each of these elements expresses an additional characteristic or relationship of the base type. - * A developer may also define an augmentation type, and a corresponding augmentation element of that type, which acts as a bucket of elements that apply to the base type. An augmentation element is defined to be substitutable for an augmentation point, which enables it to appear in instances of that base type. + * A developer may also define an augmentation type, and a corresponding augmentation element of that type, which acts as a container of elements that apply to the base type. An augmentation element is defined to be substitutable for an augmentation point, which enables it to appear in instances of that base type. * A developer of an information exchange may choose, through selection and subsetting reference schemas: @@ -3849,6 +3678,8 @@ Rule 10-20. Association element type is an association type In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange. + The term [augmentation] describes any element in a NIEM-conformant instance XML document that appears as a result of being substituted for an augmentation point element. Such an element may have a type that is an [augmentation type], or it may be a direct element that represents a property. + [Definition: augmentation] An augmentation is an [element] that @@ -3915,10 +3746,11 @@ Rule 10-20. Association element type is an association type The augmentation type is derived from structures:AugmentationType and has a name ending in "AugmentationType". The augmentation element uses the type, and has a name ending in "Augmentation". Note that the thing that binds the augmentation type to the augmentation point is the augmentation element's use of the augmentation point element as its substitution group. This means that an augmentation type can be reused for multiple types, by creating more augmentation elements that have that type, each with its own substitution group for a different augmentation point. - In addition to defining elements that use an augmentation type, a schema document may define an element that substitutes for an augmentation point element, but does not use an augmentation type. For example, the CBRN namespace defines an augmentation to nc:ScheduleType: + In addition to defining elements that use an augmentation type, a schema document may define an element that substitutes for an augmentation point element, but does not use an augmentation type. For example, the following CBRN namespace defines an augmentation to nc:ScheduleType. While an element of an augmentation type acts as a container, holding elements that apply to an augmented object, this element is a direct property of a schedule, providing a meaningful characteristic (hours of operation) for a schedule. The resulting syntax is briefer than it would be using an augmentation type; the resulting instance looks similar to how it might look if the schedule type had been extended, rather than augmented. Figure 10-12: An augmentation that is not an augmentation type + A schedule providing the beginning and ending hours of operation by weekday, for a designated time period. @@ -3946,7 +3778,7 @@ Rule 10-20. Association element type is an association type This method can be used by an information exchange developer to define individual attributes that can be applied to any augmentable type. - Note that the augmentation method can introduce an additional element into every [object type] or [association type] in an exchange, which provides opportunity for some errors in schema development. It is important that developers of exchanges not introduce elements substitutable for an augmentation point into complex types multiple ways, as it can introduce XML Schema's Unique Particle Attribution errors. A single complex type should not introduce an element via both element substitution and element reference. This constraint is also supported by Rule 11-21, Element or attribute declaration introduced only once into a type. + Note that the augmentation method can introduce an additional element into every [object type] or [association type] in an exchange, which provides opportunity for some errors in schema development. It is important that developers of exchanges not introduce elements substitutable for an augmentation point into complex types multiple ways, as it can introduce XML Schema's Unique Particle Attribution errors. A single complex type should not introduce an element via both element substitution and element reference. This constraint is also supported by Rule 11-19, Element or attribute declaration introduced only once into a type. 10.4.1. Augmentable types @@ -3962,9 +3794,9 @@ Rule 10-20. Association element type is an association type * an [object type] that has complex content and is not an external adapter type. -Rule 10-21. Augmentable type has augmentation point element +Rule 10-23. Augmentable type has augmentation point element - [Rule 10-21] (REF) + [Rule 10-23] (REF) An augmentable type MUST contain no more than one element use of its augmentation point element. 10.4.2. Augmentation point element declarations -Rule 10-23. Augmentation point corresponds to augmentable type +Rule 10-25. Augmentation point corresponds to augmentable type - [Rule 10-23] (REF, EXT) + [Rule 10-25] (REF, EXT) - Because an augmentation point element has no type, it will be abstract, per Rule 9-37, Untyped element is abstract + Because an augmentation point element has no type, it will be abstract, per Rule 9-38, Untyped element is abstract -Rule 10-25. An augmentation point has no substitution group +Rule 10-27. An augmentation point has no substitution group - [Rule 10-25] (REF, EXT) + [Rule 10-27] (REF, EXT) -Rule 10-27. Augmentation point reference is optional +Rule 10-29. Augmentation point reference is optional - [Rule 10-27] (REF) + [Rule 10-29] (REF) -Rule 10-29. Augmentation point reference must be last particle +Rule 10-31. Augmentation point reference must be last particle - [Rule 10-29] (REF, EXT) + [Rule 10-31] (REF, EXT) @@ -4164,11 +3998,11 @@ Rule 10-32. Schema component with name ending in "AugmentationType" is an augmen - The [base type definition] of an augmentation type is required to be from a conformant namespace by Rule 11-3, Base type definition defined by conformant schema. + The [base type definition] of an augmentation type is required to be from a conformant namespace by Rule 11-2, Base type definition defined by conformant schema. -Rule 10-33. Type derived from augmentation type is an augmentation type +Rule 10-35. Type derived from augmentation type is an augmentation type - [Rule 10-33] (REF, EXT) + [Rule 10-35] (REF, EXT) @@ -4194,9 +4028,9 @@ Rule 10-34. Augmentation element type is an augmentation type Using the qualifier Augmentation immediately identifies an element as representing an augmentation. -Rule 10-35. Augmentation elements are not used directly +Rule 10-37. Augmentation elements are not used directly - [Rule 10-35] (REF, SET) + [Rule 10-37] (REF, SET) Within a [reference schema document], a complex type definition MUST NOT have an element use of @@ -4216,23 +4050,23 @@ Rule 10-35. Augmentation elements are not used directly A metadata type describes data about data, that is, information that is not descriptive of objects and their relationships, but is descriptive of the data itself. It is useful to provide a general mechanism for data about data. This provides required flexibility to precisely represent information. -Rule 10-36. Metadata type has data about data +Rule 10-38. Metadata type has data about data - [Rule 10-36] (REF, EXT) + [Rule 10-38] (REF, EXT) Within the schema, a metadata type MUST contain elements appropriate for a specific class of data about data. -Rule 10-37. Metadata type derived from structures:MetadataType +Rule 10-39. Metadata type derived from structures:MetadataType - [Rule 10-37] (REF, EXT) + [Rule 10-39] (REF, EXT) Within the schema, a metadata type and only a metadata type MUST be derived directly from structures:MetadataType. A metadata type establishes a specific, named aggregation of data about data. Any type derived from structures:MetadataType is a metadata type. Metadata types should not be derived from other metadata types. Such metadata types should be used as is and additional metadata types defined for additional content. -Rule 10-38. Metadata types are derived from metadata types +Rule 10-40. Metadata types are derived from metadata types - [Rule 10-38] (REF, EXT) + [Rule 10-40] (REF, EXT) @@ -4256,9 +4090,9 @@ Rule 10-38. Metadata types are derived from metadata types There are limitations on the meaning of a metadata element in an instance; it does not establish existence of an object, nor is it a property of its containing object. -Rule 10-39. Metadata element declaration type is a metadata type +Rule 10-41. Metadata element declaration type is a metadata type - [Rule 10-39] (REF, EXT) + [Rule 10-41] (REF, EXT) @@ -4270,11 +4104,11 @@ Rule 10-39. Metadata element declaration type is a metadata type Using the qualifier Metadata immediately identifies an element as representing metadata. This document defines the term [metadata type]. -Rule 10-40. Metadata element has applicable elements +Rule 10-42. Metadata element has applicable elements Each metadata element declaration may be applied to a set of elements. Any element to which a metadata element may be validly applied is called an "applicable element" for the metadata element. - [Rule 10-40] (REF, EXT, SET) + [Rule 10-42] (REF, EXT, SET) The set of applicable elements for a metadata element declaration are as follows: @@ -4380,9 +4214,9 @@ Rule 10-40. Metadata element has applicable elements * It is highly extensible. Any domain or exchange specification may define additional representations for any concept, by defining new elements substitutable for the representation element. -Rule 10-41. Name of element that ends in "Representation" is abstract +Rule 10-43. Name of element that ends in "Representation" is abstract - [Rule 10-41] (REF, EXT) + [Rule 10-43] (REF, EXT) @@ -4395,9 +4229,9 @@ Rule 10-41. Name of element that ends in "Representation" is abstract A representation element declaration is an [element declaration] that is abstract, and that has a {name} that ends in "Representation". -Rule 10-42. A substitution for a representation element declaration is a value for a type +Rule 10-44. A substitution for a representation element declaration is a value for a type - [Rule 10-42] (REF, EXT) + [Rule 10-44] (REF, EXT) Any element declaration that is substitutable for a representation element declaration represents an optional representation of a value of a type that carries the representation element. @@ -4405,35 +4239,46 @@ Rule 10-42. A substitution for a representation element declaration is a value f This section outlines the rules used to create names for NIEM data components previously discussed in this document. Data component names must be understood easily both by humans and by machine processes. These rules improve name consistency by restricting characters, terms, and syntax that could otherwise allow too much variety and potential ambiguity. These rules also improve readability of names for humans, facilitate parsing of individual terms that compose names, and support various automated tasks associated with dictionary and controlled vocabulary maintenance. -Rule 10-43. Schema component name composed of English words +Rule 10-45. Schema component name composed of English words - [Rule 10-43] (REF, EXT) + [Rule 10-45] (REF, EXT) The name of any XML Schema component defined by the schema MUST be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED]. The English language has many spelling variations for the same word. For example, American English "program" has a corresponding British spelling "programme." This variation has the potential to cause interoperability problems when XML components are exchanged because of the different names used by the same elements. Providing users with a dictionary standard for spelling will mitigate this potential interoperability issue. -Rule 10-44. Schema component names have only specific characters +Rule 10-46. Schema component names have only specific characters - [Rule 10-44] (REF, EXT) + [Rule 10-46] (REF, EXT) - The name of any XML Schema component defined by the schema MUST contain only the following characters: + + + The name of an XML Schema component defined by the schema must be composed of only the characters uppercase 'A' through 'Z', lowercase 'a' through 'z', numbers '0' through '9', underscore, hyphen, and period. + + - * Upper-case letters ("A"-"Z"). + Only the following characters are allowed in the name of an XML Schema component defined by the schema: - * Lower-case letters ("a"-"z"). + * Upper-case letters ("A"-"Z"). - * Digits ("0"-"9"). + * Lower-case letters ("a"-"z"). - * Hyphen ("-"). + * Digits ("0"-"9"). - Other characters, such as the underscore ("_") character and the period (".") character MUST NOT appear in component names in NIEM-conformant schemas. + * Underscore ("_"). -Rule 10-45. Hyphen in component name is a separator + * Hyphen ("-"). - [Rule 10-45] (REF, EXT) + * Period ("."). + + Other characters, such as unicode characters outside the ASCII character set, are explicitly prohibited from the name of an XML Schema component defined by the schema. + +Rule 10-47. Punctuation in component name is a separator - The hyphen character ("-") MAY appear in component names only when used as a separator between parts of a single word, phrase, or value, which would otherwise be incomprehensible without the use of a separator. + [Rule 10-47] (REF, EXT) + + The characters hyphen ("-"), underscore ("_") MAY appear in a component name only when used as a separator between parts of a word, phrase, or value, which would otherwise be incomprehensible without the use of a separator. The period character (".") MAY appear in component names only when appearing as a separator (as above) or as a decimal within a numeric value. A punctuation character MUST NOT be used as a substitute for camel case in component names, or as a method to avoid camel case in component names. Names of standards and specifications, in particular, tend to consist of series of discrete numbers. Such names require some explicit separator to keep the values from running together. The separator used within NIEM is the hyphen. @@ -4443,35 +4288,55 @@ Rule 10-45. Hyphen in component name is a separator Names of conformant components use camel case formatting. Camel case is the convention of writing compound words or phrases with no spaces and an initial lowercase or uppercase letter, with each remaining word element beginning with an uppercase letter. UpperCamelCase is written with an initial uppercase letter, and lowerCamelCase is written with an initial lowercase letter. -Rule 10-46. Names use camel case +Rule 10-48. Names use camel case - [Rule 10-46] (REF, EXT) + [Rule 10-48] (REF, EXT) The name of any XML Schema component defined by the schema MUST use the camel case formatting convention. -Rule 10-47. Attribute name begins with lower case letter +Rule 10-49. Attribute name begins with lower case letter - [Rule 10-47] (REF, EXT) + [Rule 10-49] (REF, EXT) - Within the schema, any attribute declaration MUST have a name that begins with a lower-case letter ("a"-"z"). + + + Within the schema, any attribute declaration MUST have a name that begins with a lowercase letter + ('a'-'z'). + + -Rule 10-48. Name of schema component other than attribute begins with upper case letter +Rule 10-50. Name of schema component other than attribute and proxy type begins with upper case letter - [Rule 10-48] (REF, EXT) + [Rule 10-50] (REF, EXT) - Within the schema, any XML Schema component other than an attribute declaration MUST have a name that begins with an upper-case letter ("A"-"Z"). + + + This rule does not apply to an attribute. + + + This rule does not apply to a proxy types. + + + Within the schema, an XML Schema component that is not an attribute declaration or proxy type MUST have a name that begins with an upper-case letter ('A'-'Z'). + + - The foregoing rules establish lowerCamelCase for all NIEM components that are XML attributes and UpperCamelCase for all NIEM components that are types, elements, or groups. + The preceding rules establish lowerCamelCase for NIEM attributes, and UpperCamelCase for all other NIEM components, except proxy types, defined by Section 10.2.5, Proxy types, above. 10.8.2. Use of acronyms and abbreviations Acronyms and abbreviations have the ability to improve readability and comprehensibility of large, complex, or frequently used terms. They also obscure meaning and impair understanding when their definitions are not clear or when they are used injudiciously. They should be used with great care. Acronyms and abbreviations that are used must be documented and used consistently. -Rule 10-49. Names use common abbreviations +Rule 10-51. Names use common abbreviations - [Rule 10-49] (REF, EXT) + [Rule 10-51] (REF, EXT) - The schema MUST use, in defined names, the abbreviations identified by Table Table 10-1, Abbreviations used in schema component names, rather than their full meanings. + The schema SHOULD use, in defined names, the abbreviations identified by Table Table 10-1, Abbreviations used in schema component names, rather than their full meanings. Table 10-1: Abbreviations used in schema component names @@ -4501,15 +4366,15 @@ Rule 10-49. Names use common abbreviations See additional rules constraining the use of local terminology in Section 10.9.2, Local terminology, below. -Rule 10-50. Local term declaration is local to its schema document +Rule 10-52. Local term declaration is local to its schema document - [Rule 10-50] (REF, EXT) + [Rule 10-52] (REF, EXT) An element appinfo:LocalTerm MUST establish the meaning of a [local term] only within the XML Schema document in which it occurs. There MUST NOT be any transitive inheritance of local terminology within schema documents that import the containing schema document. -Rule 10-51. Local terminology interpretation +Rule 10-53. Local terminology interpretation - [Rule 10-51] (REF, EXT) + [Rule 10-53] (REF, EXT) An element information item appinfo:LocalTerm MUST establish a term as follows: @@ -4525,33 +4390,33 @@ Rule 10-51. Local terminology interpretation 10.8.3. Word forms -Rule 10-52. Singular form is preferred in name +Rule 10-54. Singular form is preferred in name - [Rule 10-52] (REF, EXT) + [Rule 10-54] (REF, EXT) A noun used as a term in the name of an XML Schema component MUST be in singular form unless the concept itself is plural. -Rule 10-53. Present tense is preferred in name +Rule 10-55. Present tense is preferred in name - [Rule 10-53] (REF, EXT) + [Rule 10-55] (REF, EXT) A verb used as a term in the name of an XML Schema component MUST be used in the present tense unless the concept itself is past tense. -Rule 10-54. Name does not have nonessential words +Rule 10-56. Name does not have nonessential words - [Rule 10-54] (REF, EXT) + [Rule 10-56] (REF, EXT) Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention. Articles (e.g., a, an, the), conjunctions (e.g., and, or, but), and prepositions (e.g., at, by, for, from, in, of, to) are all disallowed in NIEM component names, unless they are required. For example, PowerOfAttorneyCode requires the preposition. These rules constrain slight variations in word forms and types to improve consistency and reduce potentially ambiguous or confusing component names. -Rule 10-55. Component name follows pattern +Rule 10-57. Component name follows pattern Elements in NIEM-conformant schemas are given names that follow a specific pattern. This pattern comes from [ISO 11179-5]. - [Rule 10-55] (REF, EXT) + [Rule 10-57] (REF, EXT) - Except as specified elsewhere in this document, any element or attribute defined within the schema MUST have a name that takes the form: + Except as specified elsewhere in this document, any element or attribute defined within the schema SHOULD have a name that takes the form: * Object-class qualifier terms (0 or more). @@ -4571,9 +4436,9 @@ Rule 10-55. Component name follows pattern NIEM adopts an object-oriented approach to representation of data. Object classes represent what [ISO 11179-5] refers to as "things of interest in a universe of discourse that may be found in a model of that universe." An object class or object term is a word that represents a class of real-world entities or concepts. An object-class term describes the applicable context for a NIEM component. -Rule 10-56. Object-class term identifies concrete category +Rule 10-58. Object-class term identifies concrete category - [Rule 10-56] (REF, EXT) + [Rule 10-58] (REF, EXT) The object-class term of a NIEM component MUST consist of a term identifying a category of concrete concepts or entities. @@ -4589,9 +4454,9 @@ Rule 10-56. Object-class term identifies concrete category Objects or concepts are usually described in terms of their characteristic properties, data attributes, or constituent subparts. Most objects can be described by several characteristics. Therefore, a property term in the name of a data component represents a characteristic or subpart of an object class and generally describes the essence of that data component. -Rule 10-57. Property term describes characteristic or subpart +Rule 10-59. Property term describes characteristic or subpart - [Rule 10-57] (REF, EXT) + [Rule 10-59] (REF, EXT) A property term MUST describe or represent a characteristic or subpart of an entity or concept. @@ -4601,21 +4466,21 @@ Rule 10-57. Property term describes characteristic or subpart Qualifier terms modify object, property, representation, or other qualifier terms to increase semantic precision and reduce ambiguity. Qualifier terms may precede or succeed the terms they modify. The goal for the placement of qualifier terms is to generally follow the rules of ordinary English while maintaining clarity. -Rule 10-58. Name may have multiple qualifier terms +Rule 10-60. Name may have multiple qualifier terms - [Rule 10-58] (REF, EXT) + [Rule 10-60] (REF, EXT) Multiple qualifier terms MAY be used within a component name as necessary to ensure clarity and uniqueness within its namespace and usage context. -Rule 10-59. Name has minimum necessary number of qualifier terms +Rule 10-61. Name has minimum necessary number of qualifier terms - [Rule 10-59] (REF, EXT) + [Rule 10-61] (REF, EXT) The number of qualifier terms SHOULD be limited to the absolute minimum required to make the component name unique and understandable. -Rule 10-60. Order of qualifies is not significant +Rule 10-62. Order of qualifies is not significant - [Rule 10-60] (REF, EXT) + [Rule 10-62] (REF, EXT) The order of qualifiers MUST NOT be used to differentiate names. @@ -4631,9 +4496,9 @@ Rule 10-60. Order of qualifies is not significant 3. It indicates the nature of the value carried by element. Labeling elements and attributes with a notional indicator of the content eases discovery and comprehension. -Rule 10-61. Redundant term in name is omitted +Rule 10-63. Redundant term in name is omitted - [Rule 10-61] (REF, EXT) + [Rule 10-63] (REF, EXT) If any word in the representation term is redundant with any word in the property term, one occurrence SHOULD be deleted. @@ -4683,7 +4548,7 @@ Rule 10-61. Redundant term in name is omitted |Percent|A representation of a ratio in which the two units are the same. - Quantity||A counted number of nonmonetary units possibly including fractions. + Quantity||A counted number of non-monetary units possibly including fractions. Text|-|A character string (i.e., a finite sequence of characters) generally in the form of words of a language. @@ -4693,27 +4558,27 @@ Rule 10-61. Redundant term in name is omitted Abstract||An element that may represent a concept, rather than a concrete property. This representation term may be used in tandem with another of the listed representation terms. -Rule 10-62. Element with simple content has representation term +Rule 10-64. Element with simple content has representation term - [Rule 10-62] (REF, EXT) + [Rule 10-64] (REF, EXT) - Within the schema, the name of an element declaration that is of simple content MUST use an appropriate representation term as found in Table Table 10-2, Representation terms. + Within the schema, the name of an element declaration that is of simple content SHOULD use an appropriate representation term as found in Table Table 10-2, Representation terms. - This rule is also supported by Rule 11-16, Name of element declaration with simple content has representation term and Rule 11-17, Name of element declaration with simple content has representation term, which provide tests that a top-level declaration has a representation term. + This rule is also supported by Rule 11-14, Name of element declaration with simple content has representation term and Rule 11-15, Name of element declaration with simple content has representation term, which provide tests that a top-level declaration has a representation term. -Rule 10-63. Name has representation term when appropriate +Rule 10-65. Name has representation term when appropriate - [Rule 10-63] (REF, EXT) + [Rule 10-65] (REF, EXT) - Within the schema, the name of an element declaration that is of complex content, and that corresponds to a concept listed in Table Table 10-2, Representation terms, MUST use a representation term from that table. + Within the schema, the name of an element declaration that is of complex content, and that corresponds to a concept listed in Table Table 10-2, Representation terms, SHOULD use a representation term from that table. An element that represents a value listed in the table should have a representation term. It should do so even if its type is complex with multiple parts. For example, a type with multiple fields may represent an audio binary, a date, or a name. -Rule 10-64. Name has representation term only when appropriate +Rule 10-66. Name has representation term only when appropriate - [Rule 10-64] (REF, EXT) + [Rule 10-66] (REF, EXT) - Within the schema, the name of an element declaration that is of complex content and that does not correspond to a concept listed in Table Table 10-2, Representation terms MUST NOT use a representation term. + Within the schema, the name of an element declaration that is of complex content and that does not correspond to a concept listed in Table Table 10-2, Representation terms SHOULD NOT use a representation term. 10.9. Machine-readable annotations @@ -4749,9 +4614,9 @@ Rule 10-64. Name has representation term only when appropriate The majority of uses of [application information] from the [appinfo namespace] are described in the modeling rules for the specific component. -Rule 10-65. Machine-readable annotations are valid +Rule 10-67. Machine-readable annotations are valid - [Rule 10-65] (REF, EXT) + [Rule 10-67] (REF, EXT) Every element information item or attribute information item that appears as a machine-readable annotation in a schema MUST be a valid instance, according to its specification. @@ -4777,17 +4642,17 @@ Rule 10-65. Machine-readable annotations are valid The definition for [deprecated component] is adapted from [JLS] Section 9.6.4.6, @Deprecated. -Rule 10-66. Component marked as deprecated is deprecated component +Rule 10-68. Component marked as deprecated is deprecated component - [Rule 10-66] (REF, EXT) + [Rule 10-68] (REF, EXT) A [schema component] that has an attribute appinfo:deprecated with a value of "true" MUST be a [deprecated component]. Deprecation can allow version management to be more consistent; versions of schema may be incrementally improved without introducing validation problems and incompatibility. As XML Schema lacks a deprecation mechanism, NIEM defines such a mechanism. -Rule 10-67. Deprecated annotates schema component +Rule 10-69. Deprecated annotates schema component - [Rule 10-67] (REF, EXT) + [Rule 10-69] (REF, EXT) @@ -4796,9 +4661,9 @@ Rule 10-67. Deprecated annotates schema component -Rule 10-68. External import indicator annotates import +Rule 10-70. External import indicator annotates import - [Rule 10-68] (REF, EXT) + [Rule 10-70] (REF, EXT) @@ -4807,9 +4672,9 @@ Rule 10-68. External import indicator annotates import -Rule 10-69. External adapter type indicator annotates complex type +Rule 10-71. External adapter type indicator annotates complex type - [Rule 10-69] (REF) + [Rule 10-71] (REF, EXT) @@ -4820,9 +4685,9 @@ Rule 10-69. External adapter type indicator annotates complex type 10.9.1.2. appinfo:appliesToTypes annotation -Rule 10-70. appinfo:appliesToTypes annotates metadata element +Rule 10-72. appinfo:appliesToTypes annotates metadata element - [Rule 10-70] (REF, EXT) + [Rule 10-72] (REF, EXT) @@ -4832,9 +4697,9 @@ Rule 10-70. appinfo:appliesToTypes annotates metadata element -Rule 10-71. appinfo:appliesToTypes references types +Rule 10-73. appinfo:appliesToTypes references types - [Rule 10-71] (SET) + [Rule 10-73] (SET) @@ -4846,9 +4711,9 @@ Rule 10-71. appinfo:appliesToTypes references types 10.9.1.3. appinfo:appliesToElements annotation -Rule 10-72. appinfo:appliesToElements annotates metadata element +Rule 10-74. appinfo:appliesToElements annotates metadata element - [Rule 10-72] (REF, EXT) + [Rule 10-74] (REF, EXT) @@ -4859,9 +4724,9 @@ Rule 10-72. appinfo:appliesToElements annotates metadata element -Rule 10-73. appinfo:appliesToElements references elements +Rule 10-75. appinfo:appliesToElements references elements - [Rule 10-73] (SET) + [Rule 10-75] (SET) @@ -4873,9 +4738,9 @@ Rule 10-73. appinfo:appliesToElements references elements 10.9.2. Local terminology -Rule 10-74. appinfo:LocalTerm annotates schema +Rule 10-76. appinfo:LocalTerm annotates schema - [Rule 10-74] (REF, EXT) + [Rule 10-76] (REF, EXT) @@ -4886,9 +4751,9 @@ Rule 10-74. appinfo:LocalTerm annotates schema This document defines the term [application information]. -Rule 10-75. appinfo:LocalTerm has literal or definition +Rule 10-77. appinfo:LocalTerm has literal or definition - [Rule 10-75] (REF, EXT) + [Rule 10-77] (REF, EXT) @@ -4907,9 +4772,9 @@ Rule 10-75. appinfo:LocalTerm has literal or definition The structures namespace is a single namespace, separate from namespaces that define NIEM-conformant data. This document refers to this content via the prefix structures. -Rule 10-76. Use structures as specified +Rule 10-78. Use structures as specified - [Rule 10-76] (REF, EXT, INS) + [Rule 10-78] (REF, EXT, INS) The schema or instance MUST use content within the NIEM structures namespace as specified in this document and ONLY as specified by this document. @@ -4942,30 +4807,11 @@ Rule 11-1. Name of type ends in "Type" Note that the first sch:rule and subsequent sch:report serve to provide an exception to the rule for proxy types. It does not establish a constraint on the data. -Rule 11-2. Name of type other than proxy type is in upper camel case - - [Rule 11-2] (REF, EXT) - - - - The name of a proxy type is not upper camel case. - - - A type definition schema component that does not define a proxy type MUST be in upper camel case. - - - - Note that the first sch:rule and q subsequent sch:report (with @test-="false()") serve to provide an exception to this rule for proxy types. It does not establish a constraint on the data. - 11.1.1. Type definition hierarchy -Rule 11-3. Base type definition defined by conformant schema +Rule 11-2. Base type definition defined by conformant schema - [Rule 11-3] (REF, EXT) + [Rule 11-2] (REF, EXT) @@ -4980,9 +4826,9 @@ Rule 11-3. Base type definition defined by conformant schema 11.1.2. Simple type definition -Rule 11-4. Name of simple type ends in "SimpleType" +Rule 11-3. Name of simple type ends in "SimpleType" - [Rule 11-4] (REF, EXT) + [Rule 11-3] (REF, EXT) @@ -4993,32 +4839,21 @@ Rule 11-4. Name of simple type ends in "SimpleType" Specific uses of type definitions have similar syntax but very different effects on data definitions. Schemas that clearly identify complex and simple type definitions are easier to understand without tool support. This rule ensures that names of simple types end in SimpleType. -Rule 11-5. Name of simple type is upper camel case - - [Rule 11-5] (REF, EXT) - - - - The name of a simple type definition schema component MUST be upper camel case. - - - 11.1.2.1. Derivation by list -Rule 11-6. Use lists only when data is uniform +Rule 11-4. Use lists only when data is uniform - [Rule 11-6] (REF, EXT) + [Rule 11-4] (REF, EXT) Within the schema, a simple type definition that uses xs:list SHOULD NOT be defined if any member of the list requires a property or metadata that is different than other members of the list. All members of the list SHOULD have the same metadata, and should be related via the same properties. The use of lists should be reserved for cases where the data is fairly uniform. - Items in a list are not individually addressable by NIEM metadata techniques. The items are also not individually referencable by elements or attributes; one will have a value of the entire list, including all the items in the list. NIEM provides no method for individually addressing an item in a list. If an individual item in a list needs to be marked up in a manner different than other items in the list, the use of individual elements may be preferred to the definition of a list simple type. + Items in a list are not individually addressable by NIEM metadata techniques. The items may not be individually referenced by elements or attributes; one will have a value of the entire list, including all the items in the list. NIEM provides no method for individually addressing an item in a list. If an individual item in a list needs to be marked up in a manner different than other items in the list, the use of individual elements may be preferred to the definition of a list simple type. -Rule 11-7. List item type defined by conformant schemas +Rule 11-5. List item type defined by conformant schemas - [Rule 11-7] (REF, EXT) + [Rule 11-5] (REF, EXT) @@ -5033,9 +4868,9 @@ Rule 11-7. List item type defined by conformant schemas 11.1.2.2. Derivation by union -Rule 11-8. Union member types defined by conformant schemas +Rule 11-6. Union member types defined by conformant schemas - [Rule 11-8] (REF, EXT) + [Rule 11-6] (REF, EXT) @@ -5053,44 +4888,47 @@ Rule 11-8. Union member types defined by conformant schemas [Definition: code simple type] - A code simple type is a simple type definition schema component that is constrained by one or more enumeration facets. + A code simple type is a simple type definition schema component for which each value carried by the type corresponds to an entry in a list of distinct conceptual entities. These types represent lists of values, each of which has a known meaning beyond the text representation. These values may be meaningful text or may be a string of alphanumeric identifiers that represent abbreviations for literals. -Rule 11-9. Name of a code simple type has standard suffix + Many code simple types are composed of xs:enumeration values. Code simple types may also be constructed using the NIEM Code Lists Specification [Code Lists], which supports code lists defined using a variety of methods, including CSV spreadsheets. - [Rule 11-9] (REF, EXT) +Rule 11-7. Name of a code simple type has standard suffix + + [Rule 11-7] (REF, EXT) - A simple type definition schema component that has an enumeration facet or that is derived from a code type MUST have a name that ends in "CodeSimpleType". + A simple type definition schema component that has an enumeration facet or that is derived from a code simple type SHOULD have a name that ends in "CodeSimpleType". -Rule 11-10. Code simple type has enumerations +Rule 11-8. Code simple type corresponds to a code list - [Rule 11-10] (REF, EXT) + [Rule 11-8] (REF, EXT) + + A simple type SHOULD have a name ending in "CodeSimpleType" if and only if it has a correspondence to a list of distinct conceptual entities. + +Rule 11-9. Attribute of code simple type has code representation term + + [Rule 11-9] (REF, EXT) - - A code simple type MUST be derived from a code simple type or have an enumeration facet. + + An attribute with a type that is a code simple type SHOULD have a name with representation term "Code" - Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies a type as representing a fixed list of codes. These types may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values. + Using the qualifier Code (e.g. CodeType, CodeSimpleType) immediately identifies that a data component may carry values from a fixed list of codes. Such a component may be handled in specific ways, as lists of codes are expected to have their own lifecycles, including versions and periodic updates. Codes may also have responsible authorities behind them who provide concrete semantic bindings for the code values. 11.1.3. Complex type definition -Rule 11-11. Complex type with simple content has structures:SimpleObjectAttributeGroup +Rule 11-10. Complex type with simple content has structures:SimpleObjectAttributeGroup Within a [reference schema document], a complex type with simple content can be created in one of two ways: @@ -5100,7 +4938,7 @@ Rule 11-11. Complex type with simple content has structures:SimpleObjectAttribut Both of these methods use the element xs:extension. Although these two methods have similar syntax, there are subtle differences. NIEM's conformance rules ensure that any complex type has the necessary attributes for representing IDs, references, metadata, and relationship metadata. Case 1 does not require adding these attributes, as they are guaranteed to occur in the base type. However, in case 2, in which a new complex type is created from a simple type, the attributes for complex types must be added. This is done by reference to the attribute group structures:SimpleObjectAttributeGroup. - [Rule 11-11] (REF, EXT) + [Rule 11-10] (REF, EXT) - The name of an element declaration MUST be upper camel case. - - - - This document defines the term [element declaration]. - -Rule 11-13. Element type does not have a simple type name +Rule 11-11. Element type does not have a simple type name - [Rule 11-13] (REF, EXT) + [Rule 11-11] (REF, EXT) @@ -5160,9 +4985,9 @@ Rule 11-13. Element type does not have a simple type name This document defines the term [element declaration]. -Rule 11-14. Element type is from conformant namespace +Rule 11-12. Element type is from conformant namespace - [Rule 11-14] (REF, EXT) + [Rule 11-12] (REF, EXT) @@ -5178,16 +5003,18 @@ Rule 11-14. Element type is from conformant namespace This document defines the term [element declaration]. - Additional prohibitions on element types are defined by Rule 9-40, Element type not in the XML namespace and Rule 9-41, Element type is not simple type. + Additional prohibitions on element types are defined by Rule 9-41, Element type not in the XML namespace and Rule 9-42, Element type is not simple type. -Rule 11-15. Name of element that ends in "Abstract" is abstract +Rule 11-13. Name of element that ends in "Abstract" is abstract - [Rule 11-15] (REF, EXT) + [Rule 11-13] (REF, EXT) - - An element declaration with a name that ends in 'Abstract' MUST have the {abstract} property with a value of "true". + + An element declaration SHOULD have a name that ends in 'Abstract', 'AugmentationPoint', or 'Representation' if and only if it has the {abstract} property with a value of "true". @@ -5195,28 +5022,28 @@ Rule 11-15. Name of element that ends in "Abstract" is abstract This rule checks all cases that are testable in a single schema document. -Rule 11-16. Name of element declaration with simple content has representation term +Rule 11-14. Name of element declaration with simple content has representation term - [Rule 11-16] (REF, EXT) + [Rule 11-14] (REF, EXT) - The name of an element declaration that is of simple content MUST use a representation term. + The name of an element declaration that is of simple content SHOULD use a representation term. - Representation terms are defined by Table Table 10-2, Representation terms, above. This Schematron rule supports Rule 10-62, Element with simple content has representation term. + Representation terms are defined by Table Table 10-2, Representation terms, above. This Schematron rule supports Rule 10-64, Element with simple content has representation term. -Rule 11-17. Name of element declaration with simple content has representation term +Rule 11-15. Name of element declaration with simple content has representation term This rule only checks the cases not testable in the (REF, EXT) version. - [Rule 11-17] (SET) + [Rule 11-15] (SET) - the name of an element declaration that is of simple content MUST use a representation term. + the name of an element declaration that is of simple content SHOULD use a representation term. - Representation terms are defined by Table Table 10-2, Representation terms, above. This rule supports Rule 10-62, Element with simple content has representation term. + Representation terms are defined by Table Table 10-2, Representation terms, above. This rule supports Rule 10-64, Element with simple content has representation term. 11.2.2. Element substitution group -Rule 11-18. Element substitution group defined by conformant schema +Rule 11-16. Element substitution group defined by conformant schema - [Rule 11-18] (REF, EXT) + [Rule 11-16] (REF, EXT) @@ -5252,9 +5079,9 @@ Rule 11-18. Element substitution group defined by conformant schema 11.2.3. Attribute declaration -Rule 11-19. Attribute type defined by conformant schema +Rule 11-17. Attribute type defined by conformant schema - [Rule 11-19] (REF, EXT) + [Rule 11-17] (REF, EXT) @@ -5267,15 +5094,15 @@ Rule 11-19. Attribute type defined by conformant schema -Rule 11-20. Attribute name uses representation term +Rule 11-18. Attribute name uses representation term - [Rule 11-20] (REF, EXT) + [Rule 11-18] (REF, EXT) - An attribute name MUST end with a representation term. + An attribute name SHOULD end with a representation term. @@ -5289,9 +5116,9 @@ Rule 11-20. Attribute name uses representation term 11.3.2.1. Element use -Rule 11-21. Element or attribute declaration introduced only once into a type +Rule 11-19. Element or attribute declaration introduced only once into a type - [Rule 11-21] (REF, EXT) + [Rule 11-19] (REF, EXT) Within the schema, an element declaration or attribute declaration MUST NOT be introduced more than once into a type definition. This applies to content acquired by a type by any means, including from a base type definition, via element substitution groups, or through the use of attribute groups. @@ -5301,9 +5128,9 @@ Rule 11-21. Element or attribute declaration introduced only once into a type This rule is also intended to prevent developers from creating complicated sequences of recurring elements. Such definitions are difficult for developers to satisfy in code, and can cause havoc with XML Schema language binding tools. If an element is needed more than once, or if a particular sequence of elements is needed, a developer should consider the use of flexible content models (via substitution groups) along with additional rules. -Rule 11-22. Element reference defined by conformant schema +Rule 11-20. Element reference defined by conformant schema - [Rule 11-22] (REF, EXT) + [Rule 11-20] (REF, EXT) @@ -5320,9 +5147,9 @@ Rule 11-22. Element reference defined by conformant schema 11.3.3. Attribute use -Rule 11-23. Referenced attribute defined by conformant schemas +Rule 11-21. Referenced attribute defined by conformant schemas - [Rule 11-23] (REF, EXT) + [Rule 11-21] (REF, EXT) @@ -5339,11 +5166,11 @@ Rule 11-23. Referenced attribute defined by conformant schemas 11.3.3.1. Attribute group use -Rule 11-24. Schema uses only known attribute groups +Rule 11-22. Schema uses only known attribute groups In conformant schemas, use of attribute groups is restricted. The only attribute group defined by NIEM for use in conformant schemas is structures:SimpleObjectAttributeGroup. This attribute group provides the attributes necessary for IDs, references, metadata, and relationship metadata. In addition, there are attributes defined by ISM and NTK namespaces, which may be used in conformant schemas. Rationale for this use is provided in Section 7.6, IC-ISM and IC-NTK, above. - [Rule 11-24] (REF, EXT) + [Rule 11-22] (REF, EXT) @@ -5373,146 +5200,260 @@ Rule 11-24. Schema uses only known attribute groups 2. The structural definition of each component. This is made up of XML Schema component definitions, along with certain [application information] (via xs:appinfo). - When possible, meaning is expressed via XML Schema mechanisms: type derivation, element substitution, specific types and structures, as well as names that are trivially parseable. Beyond that, NIEM-specific syntax must be used, as discussed in this section. + When possible, meaning is expressed via XML Schema mechanisms: type derivation, element substitution, specific types and structures, as well as names that may be easily parsed. Beyond that, NIEM-specific syntax must be used, as discussed in this section. 11.6.1. Human-readable documentation - Note that Rule 11-29, Data definition follows 11179-4 requirements and Rule 11-30, Data definition follows 11179-4 recommendations apply [ISO 11179-4] definition rules to documented components. + Note that Rule 11-27, Data definition follows 11179-4 requirements and Rule 11-28, Data definition follows 11179-4 recommendations apply [ISO 11179-4] definition rules to documented components. -Rule 11-25. Data definition does not introduce ambiguity +Rule 11-23. Data definition does not introduce ambiguity - [Rule 11-25] (REF, EXT) + [Rule 11-23] (REF, EXT) Words or synonyms for the words within a data definition MUST NOT be reused as terms in the corresponding component name if those words dilute the semantics and understanding of, or impart ambiguity to, the entity or concept that the component represents. This document defines the term [data definition]. -Rule 11-26. Object class has only one meaning +Rule 11-24. Object class has only one meaning - [Rule 11-26] (REF, EXT) + [Rule 11-24] (REF, EXT) An object class MUST have one and only one associated semantic meaning (i.e., a single word sense) as described in the definition of the component that represents that object class. -Rule 11-27. Data definition of a part does not redefine the whole +Rule 11-25. Data definition of a part does not redefine the whole - [Rule 11-27] (REF, EXT) + [Rule 11-25] (REF, EXT) An object class MUST NOT be redefined within the definitions of the components that represent properties or subparts of that entity or class. Data definitions should be concise, precise, and unambiguous without embedding additional definitions of data elements that have already been defined once elsewhere (such as object classes). [ISO 11179-4] says that definitions should not be nested inside other definitions. Furthermore, a data dictionary is not a language dictionary. It is acceptable to reuse terms (object class, property term, and qualifier terms) from a component name within its corresponding definition to enhance clarity, as long as the requirements and recommendations of [ISO 11179-4] are not violated. This further enhances brevity and precision. -Rule 11-28. Do not leak representation into data definition +Rule 11-26. Do not leak representation into data definition - [Rule 11-28] (REF, EXT) + [Rule 11-26] (REF, EXT) A data definition MUST NOT contain explicit representational or data typing information such as number of characters, classes of characters, range of mathematical values, etc., unless the very nature of the component can be described only by such information. A component definition is intended to describe semantic meaning only, not representation or structure. How a component with simple content is represented is indicated through the representation term, but the primary source of representational information should come from the XML Schema definition of the types themselves. A developer should try to keep a component's data definition decoupled from its representation. -Rule 11-29. Data definition follows 11179-4 requirements +Rule 11-27. Data definition follows 11179-4 requirements - [Rule 11-29] (REF, EXT) + [Rule 11-27] (REF, EXT) Each [data definition] MUST conform to the requirements for data definitions provided by [ISO 11179-4] Section 5.2, Requirements. -Rule 11-30. Data definition follows 11179-4 recommendations +Rule 11-28. Data definition follows 11179-4 recommendations - [Rule 11-30] (REF, EXT) + [Rule 11-28] (REF, EXT) Each [data definition] SHOULD conform to the recommendations for data definitions provided by [ISO 11179-4] Section 5.3, Recommendations. 11.6.1.1. Data definition opening phrases -Rule 11-31. Standard opening phrase for element +11.6.1.1.1. Element opening phrases - [Rule 11-31] (REF, EXT) +Rule 11-29. Standard opening phrase for augmentation point element + + [Rule 11-29] (REF, EXT) The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". + + +Rule 11-30. Standard opening phrase for augmentation element + + [Rule 11-30] (REF, EXT) + + - The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". - + + +Rule 11-31. Standard opening phrase for metadata element + + [Rule 11-31] (REF, EXT) + + + The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". - + + +Rule 11-32. Standard opening phrase for association element + + [Rule 11-32] (REF, EXT) + + + The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". + + +Rule 11-33. Standard opening phrase for abstract element + + [Rule 11-33] (REF, EXT) + + + and not(ends-with(@name, 'AugmentationPoint'))]/xs:annotation/xs:documentation[1]"> The data definition for an abstract element SHOULD begin with the standard opening phrase "a data concept...". - + + +Rule 11-34. Standard opening phrase for date element + + [Rule 11-34] (REF, EXT) + + + The data definition for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". - + + +Rule 11-35. Standard opening phrase for quantity element + + [Rule 11-35] (REF, EXT) + + + The data definition for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". - + + +Rule 11-36. Standard opening phrase for picture element + + [Rule 11-36] (REF, EXT) + + + The data definition for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". - + + +Rule 11-37. Standard opening phrase for indicator element + + [Rule 11-37] (REF, EXT) + + + The data definition for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". - + + +Rule 11-38. Standard opening phrase for identification element + + [Rule 11-38] (REF, EXT) + + + The data definition for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". - + + +Rule 11-39. Standard opening phrase for name element + + [Rule 11-39] (REF, EXT) + + + The data definition for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". - + + +Rule 11-40. Standard opening phrase for element + + [Rule 11-40] (REF, EXT) + + + The data definition for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)". + >The data definition for an element declaration SHOULD begin with the standard opening phrase "(a|an)". -Rule 11-32. Standard opening phrase for complex type +11.6.1.1.2. Complex type opening phrases - [Rule 11-32] (REF, EXT) +Rule 11-41. Standard opening phrase for association type + + [Rule 11-41] (REF, EXT) The data definition for an association type SHOULD begin with the standard opening phrase "a datatype for (a relationship|an association)...". + >The data definition for an association type SHOULD begin with the standard opening phrase "a data type for (a relationship|an association)...". + + +Rule 11-42. Standard opening phrase for augmentation type + + [Rule 11-42] (REF, EXT) + + The data definition for an augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". + + +Rule 11-43. Standard opening phrase for metadata type + + [Rule 11-43] (REF, EXT) + + The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metadata about|information that further qualifies)...". + + +Rule 11-44. Standard opening phrase for complex type + + [Rule 11-44] (REF, EXT) + + The data definition for a type SHOULD begin with the standard opening phrase "a data type...". + >The data definition for a complex type SHOULD begin with the standard opening phrase "a data type...". -Rule 11-33. Standard opening phrase for simple type +Rule 11-45. Standard opening phrase for simple type - [Rule 11-33] (REF, EXT) + [Rule 11-45] (REF, EXT) The data definition for a type SHOULD begin with a standard opening phrase "a data type...". + >The data definition for a simple type SHOULD begin with a standard opening phrase "a data type...". @@ -5520,25 +5461,25 @@ Rule 11-33. Standard opening phrase for simple type 11.7.1. xs:schema document element restrictions -Rule 11-34. Same namespace means same components +Rule 11-46. Same namespace means same components - [Rule 11-34] (REF, EXT) + [Rule 11-46] (REF, EXT) Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, if and only if they represent the same set of components. -Rule 11-35. Different version means different view +Rule 11-47. Different version means different view - [Rule 11-35] (REF, EXT) + [Rule 11-47] (REF, EXT) Two XML Schema documents MUST have the same value for attribute targetNamespace carried by the element xs:schema, and different values for attribute version carried by the element xs:schema if and only if they are different views of the same set of components. - These rules embody the basic philosophy behind NIEM's use of namespaced components: A component is uniquely identified by its class (e.g. element, attribute, type), its namespace (a URI), and its local name (an unqualified string). Any two matching component identifiers refer to the same component, even if the versions of the schemas containing each are different. + These rules embody the basic philosophy behind NIEM's use of components with namespaces: A component is uniquely identified by its class (e.g. element, attribute, type), its namespace (a URI), and its local name (an unqualified string). Any two matching component identifiers refer to the same component, even if the versions of the schemas containing each are different. 11.8. Schema assembly -Rule 11-36. Reference schema imports reference schema +Rule 11-48. Reference schema imports reference schema - [Rule 11-36] (SET) + [Rule 11-48] (SET) -Rule 11-40. Each namespace may have only a single root schema in a schema set +Rule 11-52. Each namespace may have only a single root schema in a schema set - [Rule 11-40] (SET) + [Rule 11-52] (SET) @@ -5652,74 +5593,113 @@ Rule 12-1. Instance must be schema-valid NIEM embraces the use of XML Schema instance attributes, including xsi:type, xsi:nil, and xsi:schemaLocation, as specified by [XML Schema Structures]. -12.1. Content elements +12.1. The meaning of NIEM data - In XML instances, relationships between data objects are expressed as XML elements: + The main way that NIEM XML data represents relationships and values is via the hierarchy of XML elements in an XML document. For example, the following fragment of an XML document: - 1. Data objects are expressed as XML elements. + Figure 12-1: Example of content elements - 2. XML elements contain attributes and other elements. + + + John Doe + + - In this way, there is a relationship between the outer element (the containing element, also called the parent element) and the inner elements (the contained elements, also called as the child elements). An element that contains its content in this way is called a [content element]. + In this instance, the XML elements describe relationships between data objects: - [Definition: content element] + Table 12-1: Meaning of NIEM XML - A content element is an element information item that does not contain an attribute structures:ref. A content element expresses its value as text and element content of the element information item. + XML description|The Meaning of the data - The most common NIEM patterns use content elements to represent most data. The following is an example of a content element in use. All elements in this example are content elements. + The top element occurs within some context, about which we do not know anything.|There is some object, representing whatever is outside the outer element. - Figure 12-1: Example of content elements + The top element is nc:Person. The NIEM reference schema defines the type of the element as nc:PersonType.|There is a relationship, called nc:Person, between the unknown context object and an object of type nc:PersonType. - - - - - John Doe - - - - + The next element is nc:PersonName. The schema indicates that element is of type nc:PersonNameType.|There is a relationship called nc:PersonName between the object of type nc:PersonType and an object of type nc:PersonNameType. -12.2. Reference elements + The next element is nc:PersonFullName. The schema shows that the element is of type nc:PersonNameTextType.|There is a relationship, called nc:PersonFullName from the object of type nc:PersonNameType and an object of type nc:PersonNameTextType. - Content elements are sufficient to represent data that takes the form of a tree. However, use of content elements has limitations; expression of all relationships via element containment is not always possible. Situations that cause problems include: + Within that element is the simple value "John Doe". The schema tells us the content of that element is of simple type xs:string.|The object of type nc:PersonNameTextType has a value that is the literal "John Doe". - * Cycles: the relationships transitively held by an object include a relationship to itself. + To summarize: - For example, suppose that object 1 has a relationship to object 2 and object 2 has a relationship to object 1. This is not a tree, and so needs some representation other than a simple tree. + 1. Data objects and literal values are expressed in XML as the values of elements and attributes. - * Reuse: multiple objects have a relationship to a common object. + 2. The names of the XML elements and attributes identify and describe the relationships between the objects and literals. - For example, suppose object 1 has a relationship to object 2 and object 3 has a relationship to object 2. Expressed via containment, this would result in a duplicate of object 2. + 3. The names of the XML Schema complex types and simple types describe the data objects. - A method that solves this problem is the use of references. In a C or assembler, you could use a pointer. In C++, a reference might be used. In Java, a reference value might be used. The method defined by the XML standard is the use of ID and IDREF. An IDREF refers to an ID. NIEM uses this method and assigns to it specific semantics. + NIEM is designed so that NIEM XML data is a form of RDF data. This is described in some detail by Section 5, The NIEM conceptual model, above, in particular Section 5.6.3, NIEM instance mappings to RDF, above. The XML data, above, corresponds to the following graph. Here, the circles are data objects, and the arrows show relationships, between the objects, and between the objects and their types: - Naive solutions to these problems that use only content elements require techniques such as repeating data and identifying and excluding duplicate data; these operation entail the use of excess storage and processing time. + Figure 12-2: Diagram showing the meaning of XML data - It is good to avoid these problems; in order to avoid them, NIEM allows [reference elements]. A reference element expresses a relationship to another object by using a reference attribute, structures:ref. In Figure 12-2, Example of reference element, below, the outer object is the content of nc:Item, which is an object of type nc:ItemType. It has a relationship nc:ItemOwner to the object that is the content of the nc:Entity element. + Images are omitted from this edition. - Figure 12-2: Example of reference element +Rule 12-2. Empty content has no meaning - - - - - - - John Doe - - - + [Rule 12-2] (INS) - NIEM XML instances use IDREF attributes to establish links between XML elements. + Within the instance, the meaning of an element with no content is that additional properties are not asserted. There MUST NOT be additional meaning interpreted for an element with no content. - [Definition: reference element] + Elements without content only show a lack of asserted information. That is, all that is asserted is what is explicitly stated, through a combination of XML instance data and its schema. Data that is not present makes no claims. It may be absent due to lack of availability, lack of knowledge, or deliberate withholding of information. These cases should be modeled explicitly, if they are required. - A reference element is an element information item that has an attribute structures:ref. A reference element refers to its value by reference, instead of carrying it as content. +12.2. Identifiers and references -Rule 12-2. Attribute structures:ref must reference structures:id + Nested elements, shown above, are sufficient to represent simple data that takes the form of a tree. However, the use of nested elements has limitations; expression of all relationships via nested elements is not always possible. Situations that cause problems include: - [Rule 12-2] (INS) + * Cycles: some object has a relationship that, when followed, eventually circles back to itself. For example, suppose that Bob has a sister relationship to Sue, who has a brother relationship back to Bob. This is not a tree, and so needs some representation other than just nested elements. + + * Reuse: multiple objects have a relationship to a common object. For example, suppose Bob and Sue both have a mother relationship to Sally. Expressed via nested elements, this would result in a duplicate representation of Sally. + + NIEM provides two different ways to solve this problem: the use of local references pointing to local identifiers, and the use of uniform resource identifiers (URIs). These two methods are similar, and can interoperate, but have distinctions, as described by Section 12.2.3, Differentiating reference-to-identifier links and use of URIs, below. + +Rule 12-3. Element has only one resource identifying attribute + + [Rule 12-3] (INS) + + + + An element MUST NOT have more than one attribute that is structures:id, structures:ref, or structures:uri. + + + +12.2.1. Local identifiers and references + + The XML specifications define ID and IDREF attributes, which act as references in XML data. This is supported by XML Schema, and NIEM uses ID and IDREF as one way to reference data across data objects. Under this framework: + + * Within an XML document, each value of any attribute of type xs:ID must be unique. For example, if an element has an attribute of type xs:ID with the value of "Bob", then there may not be any other attribute in the document that is of type xs:ID that also has the value "Bob". NIEM provides attribute structures:id of type xs:ID to act as a standard local identifier. + + * Within an XML document, the value of any attribute of type xs:IDREF must appear somewhere within the document as the value of some attribute of type xs:ID. For example, if an attribute of type xs:IDREF has the value "Bob", then somewhere within that XML document there must be an attribute of type xs:ID with the value "Bob". NIEM provides attribute structures:ref as a standard local reference. + + * These constraints, that IDs must be unique, and that IDREFs must refer to IDs, are XML constraints, not unique to NIEM. + + * There are additional constraints placed on XML documents and XML schemas regarding the use of ID and IDREF attributes. For example, an element may not have two attributes of type ID. + + In short, within a NIEM-conformant XML document, an attribute structures:ref refers to an attribute structures:id. These attributes may appear in an XML document to express that an object that is the value of an element is the same as some other object within the document. For example, in the following example, the user of the weapon (Bart) is the same person that is the subject of the arrest: + + Figure 12-3: Example of structures:id and structures:ref + + + + + + Bart + + + + + + + + + Note that rules below establish that relationships established using structures:id and structures:ref have the exact same meaning as relationships established using nested elements. An information exchange specification may constrain them differently, or prefer one over the other, but from a NIEM perspective, they have the same meaning. + +Rule 12-4. Attribute structures:ref must reference structures:id + + Although many attributes with ID and IDREF semantics are defined by many vocabularies, for consistency, within a NIEM XML document any attribute structures:ref must refer to an attribute structures:id, and not any other attribute. + + [Rule 12-4] (INS) @@ -5731,9 +5711,11 @@ Rule 12-2. Attribute structures:ref must reference structures:id This mirrors the terminology in [XML] subsection Validity constraint: IDREF within Section 3.3.1, Attribute Types, except it requires the target attribute to be structures:id, rather than any attribute of type ID. -Rule 12-3. Linked elements have same validation root +Rule 12-5. Linked elements have same validation root - [Rule 12-3] (INS) + NIEM supports type-safe references: references using structures:ref and structures:id must preserve the type constraints that would apply if nested elements were used instead of a reference. For example, an element of type nc:PersonType must always refer to another element of type nc:PersonType, or a type derived from nc:PersonType, when using structures:ref to establish the relationship. + + [Rule 12-5] (INS) Given that: @@ -5753,9 +5735,9 @@ Rule 12-3. Linked elements have same validation root The term "validation root" is defined by [XML Schema Structures] Section 5.2, Assessing Schema-Validity. It is established as a part of validity assessment of an XML document. It is required because relationships between the types of elements cannot be established if those elements were not assessed together. -Rule 12-4. Attribute structures:ref references element of correct type +Rule 12-6. Attribute structures:ref references element of correct type - [Rule 12-4] (INS) + [Rule 12-6] (INS) Given that: @@ -5777,25 +5759,81 @@ Rule 12-4. Attribute structures:ref references element of correct type This rule requires that the type of the element pointed to by a structures:ref attribute must be of (or derived from) the type of the reference element. -12.2.1. Reference and content elements have same meaning +12.2.2. Uniform resource identifiers in NIEM data - An important aspect of the use of NIEM reference and content elements is that they have the same meaning. The use of a content element versus a reference element is merely for convenience and ease of serialization. There is no change in meaning or semantics between content and reference elements. + NIEM supports the linked data methodology through the use of uniform resource identifiers (URIs), expressed through the attribute structures:uri in XML documents . This attribute works much like structures:ref and structures:id, and overlaps somewhat. Linked data introduces key terminology: - Any claim that content elements represent composition while reference elements represent aggregation is incorrect. Any life cycle dependency is not expressed through the use of content and reference elements, and is not an explicit part of the NIEM model. + * Anything modeled or addressed by an information system may be called a resource: people, vehicles, reports, documents, relationships, ideas: anything that is talked about and modeled in an information system is a resource. -Rule 12-5. Reference and content elements have the same meaning + * Every resource may have a name, called a uniform resource identifier (URI). - [Rule 12-5] (INS) + As described in Section 5.4, Unique identification of data objects, above, structures:uri, structures:id, and structures:ref each denote a resource identifier. Although a structures:ref must always refer to a structures:id, and a value of structures:id must be unique within its document, a structures:uri may refer to any of structures:uri, structures:ref, or structures:id. + +Rule 12-7. structures:uri denotes resource identifier + + [Rule 12-7] (INS) + + The value of an attribute structures:uri is a URI-reference, as defined by [RFC 3986], which denotes a resource identifier on the element holding the attribute, in accordance with evaluation consistent with [RFC 3986] and [XML Base]. + + The attributes structures:id and structures:ref each have a mapping to equivalent values of structures:uri. + +Rule 12-8. structures:id denotes resource identifier + + [Rule 12-8] (INS) + + The value of the structures:id with a value of $value denotes a resource identifier on the element holding the attribute, as would be denoted by an attribute structures:uri with a value of "#$value". + +Rule 12-9. structures:ref denotes resource identifier + + [Rule 12-9] (INS) + + The value of the structures:ref with a value of $value denotes a resource identifier on the element holding the attribute, as would be denoted by an attribute structures:uri with a value of "#$value". + + For example, structures:id="hello" and structures:ref="hello" each denote the same resource identifier for an element as if it held an attribute structures:uri="#hello". + + Consistent with Section 5.4, Unique identification of data objects, above, a set of elements that each have the same resource identifier denote the same object, which has that given identifier. This means that, in an XML representation, the properties of an object may be spread across a set of elements that share an identifier. + +12.2.3. Differentiating reference-to-identifier links and use of URIs + + These two methods are similar, and can interoperate, but have distinctions: + + * With ref-to-id links, both structures:ref and structures:id are required to be within the same document. + + * With ref-to-id links, both structures:id and structures:ref are required to be validated against the same schema. + + * Ref-to-id links provide and require type safety, in that the type of an object pointed to by structures:ref must be consistent with the referencing element's type declaration. + + * The value of structures:id must be unique for IDs within the document. + + * The value of structures:ref must appear within the document as the value of an attribute structures:id. + + * An attribute structures:uri is a URI-reference that can reference any resource, inside or outside the document. + + * A structures:uri can reference any structures:id within the same document, or in another conformant document. + + * A structures:uri can reference any structures:ref within the same document, or in another conformant document. + + * Any structures:uri may reference any other structures:uri, within the same document, or in another conformant document. - There MUST NOT be any difference in meaning between a relationship established via an element declaration instantiated as a content element and that element declaration instantiated as a reference element. +12.2.4. Reference and content elements have same meaning - There is no difference in meaning between relationships established by content elements and those established by reference elements. They are simply two mechanisms for expressing connections between objects. Neither mechanism implies that properties are intrinsic or extrinsic; such characteristics must be explicitly stated in property definitions. + An important aspect of the use of nested elements, ref-to-id references, and URI references, is that they all have the same meaning. Expressing a relationship via a nested element, versus an ref-to-id reference is merely for convenience and ease of serialization. There is no change in meaning or semantics between relationships expressed by sub-elements versus relationships expressed by structures:ref or structures:uri. + + Any claim that nested elements represent composition while references represent aggregation is incorrect. No life cycle dependency is implied by either method. + +Rule 12-10. Nested elements and references have the same meaning. + + [Rule 12-10] (INS) + + There MUST NOT be any difference in meaning between a relationship established via an element declaration instantiated by a nested element, and that element declaration instantiated via reference. + + There is no difference in meaning between relationships established by sub-elements and those established by references. They are simply two mechanisms for expressing connections between objects. Neither mechanism implies that properties are intrinsic or extrinsic; such characteristics must be explicitly stated in property definitions. Being of type xs:ID and xs:IDREF, validating schema parsers will perform certain checks on the values of structures:id and structures:ref. Specifically, no two IDs may have the same value. This includes structures:id and other IDs that may be used within an XML document. Also, any value of structures:ref must also appear as the value of an ID. - By this rule, the following two XML fragments have the same meaning. First, Figure 12-3, Example with a backward reference, below, shows a person object being expressed, followed by a backwards reference to it. Second, Figure 12-4, Example with a forward reference, below, shows a person as a forward reference to the person object that is expressed later, within the definition of a witness. Both of these XML fragments have the same semantics. + By this rule, the following two XML fragments have the same meaning. First, Figure 12-4, Example with a backward reference, below, shows a person object being expressed, followed by a backwards reference to it. Second, Figure 12-5, Example with a forward reference, below, shows a person as a forward reference to the person object that is expressed later, within the definition of a witness. Both of these XML fragments have the same semantics. - Figure 12-3: Example with a backward reference + Figure 12-4: Example with a backward reference @@ -5806,7 +5844,7 @@ Rule 12-5. Reference and content elements have the same meaning - Figure 12-4: Example with a forward reference + Figure 12-5: Example with a forward reference @@ -5817,23 +5855,15 @@ Rule 12-5. Reference and content elements have the same meaning - NIEM-conformant data instances may use content elements and reference elements as needed, to represent the meaning of the fundamental data. There is no difference in meaning between reference and content data representations. The two different methods are available for ease of representation. No difference in meaning should be implied by the use of one method or the other. + NIEM-conformant data instances may use either representation as needed, to represent the meaning of the fundamental data. There is no difference in meaning between reference and content data representations. The two different methods are available for ease of representation. No difference in meaning should be implied by the use of one method or the other. Assertions that indicate "included" data is intrinsic, while referenced data is extrinsic, are not valid and are not applicable to NIEM-conformant data instances and data definitions. -Rule 12-6. Empty content has no meaning - - [Rule 12-6] (INS) - - Within the instance, the meaning of an element with no content is that additional properties are not asserted. There MUST NOT be additional meaning interpreted for an element with no content. - - Elements without content only show a lack of asserted information. That is, all that is asserted is what is explicitly stated, through a combination of XML instance data and its schema. Data that is not present makes no claims. It may be absent due to lack of availability, lack of knowledge, or deliberate withholding of information. These cases should be modeled explicitly, if they are required. - 12.3. Instance metadata NIEM provides the metadata mechanism for giving information about object assertions. An object may have an attribute that refers to one or more metadata objects. A structures:metadata attribute indicates that a data item has the given metadata. A structures:relationshipMetadata attribute asserts that the link (or relationship) established by an element has the given metadata. - Figure 12-5: Example of metadata used in an instance + Figure 12-6: Example of metadata used in an instance @@ -5877,45 +5907,45 @@ Rule 12-6. Empty content has no meaning Application of metadata to a type or element to which it is not applicable is not NIEM-conformant. A metadata element may be labeled as applicable to multiple elements via attribute appinfo:appliesToElements, or to multiple types via attribute appinfo:appliesToTypes. In either case it may apply to an instance of any of the listed elements or types. A metadata element with neither attribute appinfo:appliesToElements nor attribute appinfo:appliesToTypes may be applied to any element of any type. -Rule 12-7. Metadata applies to referring entity +Rule 12-11. Metadata applies to referring entity - [Rule 12-7] (INS) + [Rule 12-11] (INS) Within an element instance, when an object $O links to a metadata object via an attribute structures:metadata, the information in the metadata object MUST be applied to the object $O. structures:metadata applies metadata to an object. -Rule 12-8. Referent of structures:relationshipMetadata annotates relationship +Rule 12-12. Referent of structures:relationshipMetadata annotates relationship - [Rule 12-8] (INS) + [Rule 12-12] (INS) Within an element instance, when an object $O1 contains an element $E, with content object $O2 or with a reference to object $O2, and $O2 links to a metadata object via an attribute structures:relationshipMetadata, the information in the metadata object MUST be applied to the relationship $E between $O1 and $O2. structures:relationshipMetadata applies metadata to a relationship between two objects. -Rule 12-9. Values of structures:metadata refer to values of structures:id +Rule 12-13. Values of structures:metadata refer to values of structures:id - [Rule 12-9] (INS) + [Rule 12-13] (INS) Given that each IDREF in the value of an attribute structures:metadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id. -Rule 12-10. Value of structures:relationshipMetadata refers to value of structures:id +Rule 12-14. Value of structures:relationshipMetadata refers to value of structures:id - [Rule 12-10] (INS) + [Rule 12-14] (INS) Given that each IDREF in the value of an attribute structures:relationshipMetadata must match the value of an ID attribute on some element in the XML document, that ID attribute MUST be an occurrence of the attribute structures:id. -Rule 12-11. structures:metadata and structures:relationshipMetadata refer to metadata elements +Rule 12-15. structures:metadata and structures:relationshipMetadata refer to metadata elements - [Rule 12-11] (INS) + [Rule 12-15] (INS) Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a [metadata element declaration]. - Although not implemented in Schematron, this rule covers the cases not covered by Rule 12-12, Attribute structures:metadata references metadata element. + Although not implemented in Schematron, this rule covers the cases not covered by Rule 12-16, Attribute structures:metadata references metadata element. -Rule 12-12. Attribute structures:metadata references metadata element +Rule 12-16. Attribute structures:metadata references metadata element - [Rule 12-12] (INS) + [Rule 12-16] (INS) @@ -5928,9 +5958,9 @@ Rule 12-12. Attribute structures:metadata references metadata element Note that this will NOT diagnose a scenario in which the element with a name ending in "Metadata" is an external element; additional tests would be required to catch that. -Rule 12-13. Attribute structures:relationshipMetadata references metadata element +Rule 12-17. Attribute structures:relationshipMetadata references metadata element - [Rule 12-13] (INS) + [Rule 12-17] (INS) @@ -5943,13 +5973,13 @@ Rule 12-13. Attribute structures:relationshipMetadata references metadata elemen Note that this will NOT diagnose a scenario in which the element with a name ending in "Metadata" is an external element; additional tests would be required to catch that. -Rule 12-14. Metadata is applicable to element +Rule 12-18. Metadata is applicable to element - [Rule 12-14] (INS) + [Rule 12-18] (INS) Given that an element $SUBJECT-ELEMENT uses a metadata element $METADATA-ELEMENT through a value in either an attribute structures:metadata or an attribute structures:relationshipMetadata, the element $SUBJECT-ELEMENT MUST be an applicable element for $METADATA-ELEMENT. - The applicable elements for a metadata element are identified by Rule 10-40, Metadata element has applicable elements. + The applicable elements for a metadata element are identified by Rule 10-42, Metadata element has applicable elements. Appendix A. References @@ -5969,6 +5999,8 @@ Appendix A. References [N-ary]: "Defining N-ary Relations on the Semantic Web", W3C Working Group Note, 12 April 2006. Available from http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412//. + [Code Lists]: Webb Roberts. "NIEM Code Lists Specification." NIEM Technical Architecture Committee (NTAC), June 20, 2016. Available from https://reference.niem.gov/niem/specification/code-lists/1.0/niem-code-lists-1.0-2016-06-20.html. + [OED]: "Oxford English Dictionary, Third Edition", Oxford University Press, November 2010. http://dictionary.oed.com/. [RDF Concepts]: Richard Cyganiak, David Wood, and Markus Lanthaler, eds. "RDF 1.1 Concepts and Abstract Syntax." The World Wide Web Consortium (W3C), February 25, 2014. http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/. @@ -6000,7 +6032,7 @@ Appendix B. Structures namespace @@ -6013,6 +6045,7 @@ Appendix B. Structures namespace + @@ -6024,6 +6057,7 @@ Appendix B. Structures namespace + @@ -6041,6 +6075,7 @@ Appendix B. Structures namespace + @@ -6055,12 +6090,14 @@ Appendix B. Structures namespace + + @@ -6073,7 +6110,7 @@ Appendix C. Appinfo namespace @@ -6192,90 +6229,91 @@ Appendix E. Index of rules Rule 9-10, Simple type definition is top-level: Section 9.1.2, Simple type definition Rule 9-11, No simple type disallowed derivation: Section 9.1.2, Simple type definition Rule 9-12, Simple type has data definition: Section 9.1.2, Simple type definition - Rule 9-13, No list item type of xs:ID: Section 9.1.2.1, Simple types prohibited as list item types - Rule 9-14, No list item type of xs:IDREF: Section 9.1.2.1, Simple types prohibited as list item types - Rule 9-15, No list item type of xs:anySimpleType: Section 9.1.2.1, Simple types prohibited as list item types - Rule 9-16, No list item type of xs:ENTITY: Section 9.1.2.1, Simple types prohibited as list item types - Rule 9-17, No union member types of xs:ID: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-18, No union member types of xs:IDREF: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-19, No union member types of xs:IDREFS: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-20, No union member types of xs:anySimpleType: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-21, No union member types of xs:ENTITY: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-22, No union member types of xs:ENTITIES: Section 9.1.2.2, Simple types prohibited as union member types - Rule 9-23, Enumeration has data definition: Section 9.1.2, Simple type definition - Rule 9-24, Complex type definitions is top-level: Section 9.1.3, Complex type definition - Rule 9-25, Complex type has data definition: Section 9.1.3, Complex type definition - Rule 9-26, No mixed content on complex type: Section 9.1.3.1, No mixed content - Rule 9-27, No mixed content on complex content: Section 9.1.3.1, No mixed content - Rule 9-28, Complex type content is explicitly simple or complex: Section 9.1.3, Complex type definition - Rule 9-29, Complex content uses extension: Section 9.1.3.2, Complex content - Rule 9-30, Base type of complex type with complex content must have complex content: Section 9.1.3.2.1, Base type of complex type with complex content has complex content + Rule 9-13, No use of "fixed" on simple type facets: Section 9.1.2, Simple type definition + Rule 9-14, No list item type of xs:ID: Section 9.1.2.1, Simple types prohibited as list item types + Rule 9-15, No list item type of xs:IDREF: Section 9.1.2.1, Simple types prohibited as list item types + Rule 9-16, No list item type of xs:anySimpleType: Section 9.1.2.1, Simple types prohibited as list item types + Rule 9-17, No list item type of xs:ENTITY: Section 9.1.2.1, Simple types prohibited as list item types + Rule 9-18, No union member types of xs:ID: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-19, No union member types of xs:IDREF: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-20, No union member types of xs:IDREFS: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-21, No union member types of xs:anySimpleType: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-22, No union member types of xs:ENTITY: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-23, No union member types of xs:ENTITIES: Section 9.1.2.2, Simple types prohibited as union member types + Rule 9-24, Enumeration has data definition: Section 9.1.2, Simple type definition + Rule 9-25, Complex type definitions is top-level: Section 9.1.3, Complex type definition + Rule 9-26, Complex type has data definition: Section 9.1.3, Complex type definition + Rule 9-27, No mixed content on complex type: Section 9.1.3.1, No mixed content + Rule 9-28, No mixed content on complex content: Section 9.1.3.1, No mixed content + Rule 9-29, Complex type content is explicitly simple or complex: Section 9.1.3, Complex type definition + Rule 9-30, Complex content uses extension: Section 9.1.3.2, Complex content Rule 9-31, Base type of complex type with complex content must have complex content: Section 9.1.3.2.1, Base type of complex type with complex content has complex content - Rule 9-32, Simple content uses extension: Section 9.1.3.3, Simple content - Rule 9-33, No complex type disallowed substitutions: Section 9.1.3, Complex type definition - Rule 9-34, No complex type disallowed derivation: Section 9.1.3, Complex type definition - Rule 9-35, Element declaration is top-level: Section 9.2.1, Element declaration - Rule 9-36, Element declaration has data definition: Section 9.2.1, Element declaration - Rule 9-37, Untyped element is abstract: Section 9.2.1, Element declaration - Rule 9-38, Element of type xs:anySimpleType is abstract: Section 9.2.1, Element declaration - Rule 9-39, Element type not in the XML Schema namespace: Section 9.2.1, Element declaration - Rule 9-40, Element type not in the XML namespace: Section 9.2.1, Element declaration - Rule 9-41, Element type is not simple type: Section 9.2.1, Element declaration - Rule 9-42, No element disallowed substitutions : Section 9.2.1, Element declaration - Rule 9-43, No element disallowed derivation: Section 9.2.1, Element declaration - Rule 9-44, No element default value: Section 9.2.1.1, No element value constraints - Rule 9-45, No element fixed value: Section 9.2.1.1, No element value constraints - Rule 9-46, Element declaration is nillable: Section 9.2.1, Element declaration - Rule 9-47, Attribute declaration is top-level: Section 9.2.3, Attribute declaration - Rule 9-48, Attribute declaration has data definition: Section 9.2.3, Attribute declaration - Rule 9-49, Attribute declaration has type: Section 9.2.3, Attribute declaration - Rule 9-50, No attribute type of xs:ID: Section 9.2.3.1, Prohibited attribute types - Rule 9-51, No attribute type of xs:IDREF: Section 9.2.3.1, Prohibited attribute types - Rule 9-52, No attribute type of xs:IDREFS: Section 9.2.3.1, Prohibited attribute types - Rule 9-53, No attribute type of xs:ENTITY: Section 9.2.3.1, Prohibited attribute types - Rule 9-54, No attribute type of xs:ENTITIES: Section 9.2.3.1, Prohibited attribute types - Rule 9-55, No attribute type of xs:anySimpleType: Section 9.2.3.1, Prohibited attribute types - Rule 9-56, No attribute default values: Section 9.2.3.2, No attribute value constraints - Rule 9-57, No attribute fixed values: Section 9.2.3.2, No attribute value constraints - Rule 9-58, No use of element xs:notation: Section 9.2.4, Notation declaration - Rule 9-59, Model group does not affect meaning: Section 9.3.1, Model group - Rule 9-60, No xs:all: Section 9.3.1, Model group - Rule 9-61, xs:sequence must be child of xs:extension: Section 9.3.1.1, Sequence - Rule 9-62, xs:sequence must be child of xs:extension or xs:restriction: Section 9.3.1.1, Sequence - Rule 9-63, No xs:choice: Section 9.3.1.2, Choice - Rule 9-64, xs:choice must be child of xs:sequence: Section 9.3.1.2, Choice - Rule 9-65, Sequence has minimum cardinality 1: Section 9.3.2.1, Sequence cardinality - Rule 9-66, Sequence has maximum cardinality 1: Section 9.3.2.1, Sequence cardinality - Rule 9-67, Choice has minimum cardinality 1: Section 9.3.2.2, Choice cardinality - Rule 9-68, Choice has maximum cardinality 1: Section 9.3.2.2, Choice cardinality - Rule 9-69, No use of xs:any: Section 9.3.4, Wildcard - Rule 9-70, No use of xs:anyAttribute: Section 9.3.4, Wildcard - Rule 9-71, No use of xs:unique: Section 9.4, Identity-constraint definition components - Rule 9-72, No use of xs:key: Section 9.4, Identity-constraint definition components - Rule 9-73, No use of xs:keyref: Section 9.4, Identity-constraint definition components - Rule 9-74, No use of xs:group: Section 9.5.1, Model group definition - Rule 9-75, No definition of attribute groups: Section 9.5.2, Attribute group definition - Rule 9-76, Comment is not recommended: Section 9.6, Annotation components - Rule 9-77, Documentation element has no element children: Section 9.6, Annotation components - Rule 9-78, xs:appinfo children are comments, elements, or whitespace: Section 9.6.1, Application information annotation - Rule 9-79, Appinfo child elements have namespaces: Section 9.6.1, Application information annotation - Rule 9-80, Appinfo descendants are not XML Schema elements: Section 9.6.1, Application information annotation - Rule 9-81, Schema has data definition: Section 9.7, Schema as a whole - Rule 9-82, Schema document defines target namespace: Section 9.7, Schema as a whole - Rule 9-83, Target namespace is absolute URI: Section 9.7, Schema as a whole - Rule 9-84, Schema has version: Section 9.7, Schema as a whole - Rule 9-85, No disallowed substitutions: Section 9.7, Schema as a whole - Rule 9-86, No disallowed derivations: Section 9.7, Schema as a whole - Rule 9-87, No use of xs:redefine: Section 9.8, Schema assembly - Rule 9-88, No use of xs:include: Section 9.8, Schema assembly - Rule 9-89, xs:import must have namespace: Section 9.8, Schema assembly - Rule 9-90, XML Schema document set must be complete: Section 9.8, Schema assembly - Rule 9-91, Namespace referenced by attribute type is imported: Section 9.8.1, Namespaces for referenced components are imported - Rule 9-92, Namespace referenced by attribute base is imported: Section 9.8.1, Namespaces for referenced components are imported - Rule 9-93, Namespace referenced by attribute itemType is imported: Section 9.8.1, Namespaces for referenced components are imported - Rule 9-94, Namespaces referenced by attribute memberTypes is imported: Section 9.8.1, Namespaces for referenced components are imported - Rule 9-95, Namespace referenced by attribute ref is imported: Section 9.8.1, Namespaces for referenced components are imported - Rule 9-96, Namespace referenced by attribute substitutionGroup is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-32, Base type of complex type with complex content must have complex content: Section 9.1.3.2.1, Base type of complex type with complex content has complex content + Rule 9-33, Simple content uses extension: Section 9.1.3.3, Simple content + Rule 9-34, No complex type disallowed substitutions: Section 9.1.3, Complex type definition + Rule 9-35, No complex type disallowed derivation: Section 9.1.3, Complex type definition + Rule 9-36, Element declaration is top-level: Section 9.2.1, Element declaration + Rule 9-37, Element declaration has data definition: Section 9.2.1, Element declaration + Rule 9-38, Untyped element is abstract: Section 9.2.1, Element declaration + Rule 9-39, Element of type xs:anySimpleType is abstract: Section 9.2.1, Element declaration + Rule 9-40, Element type not in the XML Schema namespace: Section 9.2.1, Element declaration + Rule 9-41, Element type not in the XML namespace: Section 9.2.1, Element declaration + Rule 9-42, Element type is not simple type: Section 9.2.1, Element declaration + Rule 9-43, No element disallowed substitutions : Section 9.2.1, Element declaration + Rule 9-44, No element disallowed derivation: Section 9.2.1, Element declaration + Rule 9-45, No element default value: Section 9.2.1.1, No element value constraints + Rule 9-46, No element fixed value: Section 9.2.1.1, No element value constraints + Rule 9-47, Element declaration is nillable: Section 9.2.1, Element declaration + Rule 9-48, Attribute declaration is top-level: Section 9.2.3, Attribute declaration + Rule 9-49, Attribute declaration has data definition: Section 9.2.3, Attribute declaration + Rule 9-50, Attribute declaration has type: Section 9.2.3, Attribute declaration + Rule 9-51, No attribute type of xs:ID: Section 9.2.3.1, Prohibited attribute types + Rule 9-52, No attribute type of xs:IDREF: Section 9.2.3.1, Prohibited attribute types + Rule 9-53, No attribute type of xs:IDREFS: Section 9.2.3.1, Prohibited attribute types + Rule 9-54, No attribute type of xs:ENTITY: Section 9.2.3.1, Prohibited attribute types + Rule 9-55, No attribute type of xs:ENTITIES: Section 9.2.3.1, Prohibited attribute types + Rule 9-56, No attribute type of xs:anySimpleType: Section 9.2.3.1, Prohibited attribute types + Rule 9-57, No attribute default values: Section 9.2.3.2, No attribute value constraints + Rule 9-58, No attribute fixed values: Section 9.2.3.2, No attribute value constraints + Rule 9-59, No use of element xs:notation: Section 9.2.4, Notation declaration + Rule 9-60, Model group does not affect meaning: Section 9.3.1, Model group + Rule 9-61, No xs:all: Section 9.3.1, Model group + Rule 9-62, xs:sequence must be child of xs:extension: Section 9.3.1.1, Sequence + Rule 9-63, xs:sequence must be child of xs:extension or xs:restriction: Section 9.3.1.1, Sequence + Rule 9-64, No xs:choice: Section 9.3.1.2, Choice + Rule 9-65, xs:choice must be child of xs:sequence: Section 9.3.1.2, Choice + Rule 9-66, Sequence has minimum cardinality 1: Section 9.3.2.1, Sequence cardinality + Rule 9-67, Sequence has maximum cardinality 1: Section 9.3.2.1, Sequence cardinality + Rule 9-68, Choice has minimum cardinality 1: Section 9.3.2.2, Choice cardinality + Rule 9-69, Choice has maximum cardinality 1: Section 9.3.2.2, Choice cardinality + Rule 9-70, No use of xs:any: Section 9.3.4, Wildcard + Rule 9-71, No use of xs:anyAttribute: Section 9.3.4, Wildcard + Rule 9-72, No use of xs:unique: Section 9.4, Identity-constraint definition components + Rule 9-73, No use of xs:key: Section 9.4, Identity-constraint definition components + Rule 9-74, No use of xs:keyref: Section 9.4, Identity-constraint definition components + Rule 9-75, No use of xs:group: Section 9.5.1, Model group definition + Rule 9-76, No definition of attribute groups: Section 9.5.2, Attribute group definition + Rule 9-77, Comment is not recommended: Section 9.6, Annotation components + Rule 9-78, Documentation element has no element children: Section 9.6, Annotation components + Rule 9-79, xs:appinfo children are comments, elements, or whitespace: Section 9.6.1, Application information annotation + Rule 9-80, Appinfo child elements have namespaces: Section 9.6.1, Application information annotation + Rule 9-81, Appinfo descendants are not XML Schema elements: Section 9.6.1, Application information annotation + Rule 9-82, Schema has data definition: Section 9.7, Schema as a whole + Rule 9-83, Schema document defines target namespace: Section 9.7, Schema as a whole + Rule 9-84, Target namespace is absolute URI: Section 9.7, Schema as a whole + Rule 9-85, Schema has version: Section 9.7, Schema as a whole + Rule 9-86, No disallowed substitutions: Section 9.7, Schema as a whole + Rule 9-87, No disallowed derivations: Section 9.7, Schema as a whole + Rule 9-88, No use of xs:redefine: Section 9.8, Schema assembly + Rule 9-89, No use of xs:include: Section 9.8, Schema assembly + Rule 9-90, xs:import must have namespace: Section 9.8, Schema assembly + Rule 9-91, XML Schema document set must be complete: Section 9.8, Schema assembly + Rule 9-92, Namespace referenced by attribute type is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-93, Namespace referenced by attribute base is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-94, Namespace referenced by attribute itemType is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-95, Namespaces referenced by attribute memberTypes is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-96, Namespace referenced by attribute ref is imported: Section 9.8.1, Namespaces for referenced components are imported + Rule 9-97, Namespace referenced by attribute substitutionGroup is imported: Section 9.8.1, Namespaces for referenced components are imported Rule 10-1, Complex type has a category: Section 10.1, Categories of NIEM type definitions Rule 10-2, Object type with complex content is derived from object type: Section 10.2.1.1, Object types with complex content Rule 10-3, RoleOf element type is an object type: Section 10.2.2, Role types and roles @@ -6293,120 +6331,138 @@ Appendix E. Index of rules Rule 10-15, External attribute use not an ID: Section 10.2.3.3, External attribute use Rule 10-16, External element use has data definition: Section 10.2.3.4, External element use Rule 10-17, Name of code type ends in "CodeType": Section 10.2.4, Code types - Rule 10-18, Proxy type has designated structure: Section 10.2.5, Proxy types - Rule 10-19, Association type is derived from association type: Section 10.3.1, Association types - Rule 10-20, Association element type is an association type: Section 10.3.2, Association element declarations - Rule 10-21, Augmentable type has augmentation point element: Section 10.4.1, Augmentable types - Rule 10-22, Augmentable type has at most one augmentation point element: Section 10.4.1, Augmentable types - Rule 10-23, Augmentation point corresponds to augmentable type: Section 10.4.2, Augmentation point element declarations - Rule 10-24, An augmentation point has no type: Section 10.4.2, Augmentation point element declarations - Rule 10-25, An augmentation point has no substitution group: Section 10.4.2, Augmentation point element declarations - Rule 10-26, Augmentation point element may only be referenced by its type: Section 10.4.3, Augmentation point element use - Rule 10-27, Augmentation point reference is optional: Section 10.4.3, Augmentation point element use - Rule 10-28, Augmentation point reference is unbounded: Section 10.4.3, Augmentation point element use - Rule 10-29, Augmentation point reference must be last particle: Section 10.4.3, Augmentation point element use - Rule 10-30, Element within instance of augmentation type modifies base: Section 10.4.4, Augmentation types - Rule 10-31, Only an augmentation type name ends in "AugmentationType": Section 10.4.4, Augmentation types - Rule 10-32, Schema component with name ending in "AugmentationType" is an augmentation type: Section 10.4.4, Augmentation types - Rule 10-33, Type derived from augmentation type is an augmentation type: Section 10.4.4, Augmentation types - Rule 10-34, Augmentation element type is an augmentation type: Section 10.4.5, Augmentation element declarations - Rule 10-35, Augmentation elements are not used directly: Section 10.4.5, Augmentation element declarations - Rule 10-36, Metadata type has data about data: Section 10.5.1, Metadata types - Rule 10-37, Metadata type derived from structures:MetadataType: Section 10.5.1, Metadata types - Rule 10-38, Metadata types are derived from metadata types: Section 10.5.1, Metadata types - Rule 10-39, Metadata element declaration type is a metadata type: Section 10.5.2, Metadata element declarations - Rule 10-40, Metadata element has applicable elements: Section 10.5.2, Metadata element declarations - Rule 10-41, Name of element that ends in "Representation" is abstract: Section 10.7, The "Representation" pattern - Rule 10-42, A substitution for a representation element declaration is a value for a type: Section 10, Rules for NIEM modeling, by NIEM concept - Rule 10-43, Schema component name composed of English words: Section 10.8, Naming rules - Rule 10-44, Schema component names have only specific characters: Section 10.8, Naming rules - Rule 10-45, Hyphen in component name is a separator: Section 10.8, Naming rules - Rule 10-46, Names use camel case: Section 10.8.1, Character case - Rule 10-47, Attribute name begins with lower case letter: Section 10.8.1, Character case - Rule 10-48, Name of schema component other than attribute begins with upper case letter: Section 10.8.1, Character case - Rule 10-49, Names use common abbreviations: Section 10.8.2, Use of acronyms and abbreviations - Rule 10-50, Local term declaration is local to its schema document: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon - Rule 10-51, Local terminology interpretation: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon - Rule 10-52, Singular form is preferred in name: Section 10.8.3, Word forms - Rule 10-53, Present tense is preferred in name: Section 10.8.3, Word forms - Rule 10-54, Name does not have nonessential words: Section 10.8.3, Word forms - Rule 10-55, Component name follows pattern: Section 10.8, Naming rules - Rule 10-56, Object-class term identifies concrete category: Section 10.8.4, Object-class term - Rule 10-57, Property term describes characteristic or subpart: Section 10.8.5, Property term - Rule 10-58, Name may have multiple qualifier terms: Section 10.8.6, Qualifier terms - Rule 10-59, Name has minimum necessary number of qualifier terms: Section 10.8.6, Qualifier terms - Rule 10-60, Order of qualifies is not significant: Section 10.8.6, Qualifier terms - Rule 10-61, Redundant term in name is omitted: Section 10.8.7, Representation terms - Rule 10-62, Element with simple content has representation term: Section 10.8.7, Representation terms - Rule 10-63, Name has representation term when appropriate: Section 10.8.7, Representation terms - Rule 10-64, Name has representation term only when appropriate: Section 10.8.7, Representation terms - Rule 10-65, Machine-readable annotations are valid: Section 10.9, Machine-readable annotations - Rule 10-66, Component marked as deprecated is deprecated component: Section 10.9.1.1, Deprecation - Rule 10-67, Deprecated annotates schema component: Section 10.9.1.1, Deprecation - Rule 10-68, External import indicator annotates import: Section 10.9.1, The NIEM appinfo namespace - Rule 10-69, External adapter type indicator annotates complex type: Section 10.9.1, The NIEM appinfo namespace - Rule 10-70, appinfo:appliesToTypes annotates metadata element: Section 10.9.1.2, appinfo:appliesToTypes annotation - Rule 10-71, appinfo:appliesToTypes references types: Section 10.9.1.2, appinfo:appliesToTypes annotation - Rule 10-72, appinfo:appliesToElements annotates metadata element: Section 10.9.1.3, appinfo:appliesToElements annotation - Rule 10-73, appinfo:appliesToElements references elements: Section 10.9.1.3, appinfo:appliesToElements annotation - Rule 10-74, appinfo:LocalTerm annotates schema: Section 10.9.2, Local terminology - Rule 10-75, appinfo:LocalTerm has literal or definition: Section 10.9.2, Local terminology - Rule 10-76, Use structures as specified: Section 10.10, NIEM structural facilities + Rule 10-18, Code type corresponds to a code list: Section 10.2.4, Code types + Rule 10-19, Element of code type has code representation term: Section 10.2.4, Code types + Rule 10-20, Proxy type has designated structure: Section 10.2.5, Proxy types + Rule 10-21, Association type is derived from association type: Section 10.3.1, Association types + Rule 10-22, Association element type is an association type: Section 10.3.2, Association element declarations + Rule 10-23, Augmentable type has augmentation point element: Section 10.4.1, Augmentable types + Rule 10-24, Augmentable type has at most one augmentation point element: Section 10.4.1, Augmentable types + Rule 10-25, Augmentation point corresponds to augmentable type: Section 10.4.2, Augmentation point element declarations + Rule 10-26, An augmentation point has no type: Section 10.4.2, Augmentation point element declarations + Rule 10-27, An augmentation point has no substitution group: Section 10.4.2, Augmentation point element declarations + Rule 10-28, Augmentation point element may only be referenced by its type: Section 10.4.3, Augmentation point element use + Rule 10-29, Augmentation point reference is optional: Section 10.4.3, Augmentation point element use + Rule 10-30, Augmentation point reference is unbounded: Section 10.4.3, Augmentation point element use + Rule 10-31, Augmentation point reference must be last particle: Section 10.4.3, Augmentation point element use + Rule 10-32, Element within instance of augmentation type modifies base: Section 10.4.4, Augmentation types + Rule 10-33, Only an augmentation type name ends in "AugmentationType": Section 10.4.4, Augmentation types + Rule 10-34, Schema component with name ending in "AugmentationType" is an augmentation type: Section 10.4.4, Augmentation types + Rule 10-35, Type derived from augmentation type is an augmentation type: Section 10.4.4, Augmentation types + Rule 10-36, Augmentation element type is an augmentation type: Section 10.4.5, Augmentation element declarations + Rule 10-37, Augmentation elements are not used directly: Section 10.4.5, Augmentation element declarations + Rule 10-38, Metadata type has data about data: Section 10.5.1, Metadata types + Rule 10-39, Metadata type derived from structures:MetadataType: Section 10.5.1, Metadata types + Rule 10-40, Metadata types are derived from metadata types: Section 10.5.1, Metadata types + Rule 10-41, Metadata element declaration type is a metadata type: Section 10.5.2, Metadata element declarations + Rule 10-42, Metadata element has applicable elements: Section 10.5.2, Metadata element declarations + Rule 10-43, Name of element that ends in "Representation" is abstract: Section 10.7, The "Representation" pattern + Rule 10-44, A substitution for a representation element declaration is a value for a type: Section 10, Rules for NIEM modeling, by NIEM concept + Rule 10-45, Schema component name composed of English words: Section 10.8, Naming rules + Rule 10-46, Schema component names have only specific characters: Section 10.8, Naming rules + Rule 10-47, Punctuation in component name is a separator: Section 10.8, Naming rules + Rule 10-48, Names use camel case: Section 10.8.1, Character case + Rule 10-49, Attribute name begins with lower case letter: Section 10.8.1, Character case + Rule 10-50, Name of schema component other than attribute and proxy type begins with upper case letter: Section 10.8.1, Character case + Rule 10-51, Names use common abbreviations: Section 10.8.2, Use of acronyms and abbreviations + Rule 10-52, Local term declaration is local to its schema document: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon + Rule 10-53, Local terminology interpretation: Section 10.8.2.1, Use of Acronyms, Initialisms, Abbreviations, and Jargon + Rule 10-54, Singular form is preferred in name: Section 10.8.3, Word forms + Rule 10-55, Present tense is preferred in name: Section 10.8.3, Word forms + Rule 10-56, Name does not have nonessential words: Section 10.8.3, Word forms + Rule 10-57, Component name follows pattern: Section 10.8, Naming rules + Rule 10-58, Object-class term identifies concrete category: Section 10.8.4, Object-class term + Rule 10-59, Property term describes characteristic or subpart: Section 10.8.5, Property term + Rule 10-60, Name may have multiple qualifier terms: Section 10.8.6, Qualifier terms + Rule 10-61, Name has minimum necessary number of qualifier terms: Section 10.8.6, Qualifier terms + Rule 10-62, Order of qualifies is not significant: Section 10.8.6, Qualifier terms + Rule 10-63, Redundant term in name is omitted: Section 10.8.7, Representation terms + Rule 10-64, Element with simple content has representation term: Section 10.8.7, Representation terms + Rule 10-65, Name has representation term when appropriate: Section 10.8.7, Representation terms + Rule 10-66, Name has representation term only when appropriate: Section 10.8.7, Representation terms + Rule 10-67, Machine-readable annotations are valid: Section 10.9, Machine-readable annotations + Rule 10-68, Component marked as deprecated is deprecated component: Section 10.9.1.1, Deprecation + Rule 10-69, Deprecated annotates schema component: Section 10.9.1.1, Deprecation + Rule 10-70, External import indicator annotates import: Section 10.9.1, The NIEM appinfo namespace + Rule 10-71, External adapter type indicator annotates complex type: Section 10.9.1, The NIEM appinfo namespace + Rule 10-72, appinfo:appliesToTypes annotates metadata element: Section 10.9.1.2, appinfo:appliesToTypes annotation + Rule 10-73, appinfo:appliesToTypes references types: Section 10.9.1.2, appinfo:appliesToTypes annotation + Rule 10-74, appinfo:appliesToElements annotates metadata element: Section 10.9.1.3, appinfo:appliesToElements annotation + Rule 10-75, appinfo:appliesToElements references elements: Section 10.9.1.3, appinfo:appliesToElements annotation + Rule 10-76, appinfo:LocalTerm annotates schema: Section 10.9.2, Local terminology + Rule 10-77, appinfo:LocalTerm has literal or definition: Section 10.9.2, Local terminology + Rule 10-78, Use structures as specified: Section 10.10, NIEM structural facilities Rule 11-1, Name of type ends in "Type": Section 11.1, Type definition components - Rule 11-2, Name of type other than proxy type is in upper camel case: Section 11.1, Type definition components - Rule 11-3, Base type definition defined by conformant schema: Section 11.1.1, Type definition hierarchy - Rule 11-4, Name of simple type ends in "SimpleType": Section 11.1.2, Simple type definition - Rule 11-5, Name of simple type is upper camel case: Section 11.1.2, Simple type definition - Rule 11-6, Use lists only when data is uniform: Section 11.1.2.1, Derivation by list - Rule 11-7, List item type defined by conformant schemas: Section 11.1.2.1, Derivation by list - Rule 11-8, Union member types defined by conformant schemas: Section 11.1.2.2, Derivation by union - Rule 11-9, Name of a code simple type has standard suffix: Section 11.1.2.3, Code simple types - Rule 11-10, Code simple type has enumerations: Section 11.1.2.3, Code simple types - Rule 11-11, Complex type with simple content has structures:SimpleObjectAttributeGroup: Section 11.1.3, Complex type definition - Rule 11-12, Element name is upper camel case: Section 11.2.1, Element declaration - Rule 11-13, Element type does not have a simple type name: Section 11.2.1, Element declaration - Rule 11-14, Element type is from conformant namespace: Section 11.2.1, Element declaration - Rule 11-15, Name of element that ends in "Abstract" is abstract: Section 11.2.1, Element declaration - Rule 11-16, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations - Rule 11-17, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations - Rule 11-18, Element substitution group defined by conformant schema: Section 11.2.2, Element substitution group - Rule 11-19, Attribute type defined by conformant schema: Section 11.2.3, Attribute declaration - Rule 11-20, Attribute name uses representation term: Section 11.2.3, Attribute declaration - Rule 11-21, Element or attribute declaration introduced only once into a type: Section 11.3.2.1, Element use - Rule 11-22, Element reference defined by conformant schema: Section 11.3.2.1, Element use - Rule 11-23, Referenced attribute defined by conformant schemas: Section 11.3.3, Attribute use - Rule 11-24, Schema uses only known attribute groups: Section 11.3.3.1, Attribute group use - Rule 11-25, Data definition does not introduce ambiguity: Section 11.6.1, Human-readable documentation - Rule 11-26, Object class has only one meaning: Section 11.6.1, Human-readable documentation - Rule 11-27, Data definition of a part does not redefine the whole: Section 11.6.1, Human-readable documentation - Rule 11-28, Do not leak representation into data definition: Section 11.6.1, Human-readable documentation - Rule 11-29, Data definition follows 11179-4 requirements: Section 11.6.1, Human-readable documentation - Rule 11-30, Data definition follows 11179-4 recommendations: Section 11.6.1, Human-readable documentation - Rule 11-31, Standard opening phrase for element: Section 11.6.1.1, Data definition opening phrases - Rule 11-32, Standard opening phrase for complex type: Section 11.6.1.1, Data definition opening phrases - Rule 11-33, Standard opening phrase for simple type: Section 11.6.1.1, Data definition opening phrases - Rule 11-34, Same namespace means same components: Section 11.7.1, xs:schema document element restrictions - Rule 11-35, Different version means different view: Section 11.7.1, xs:schema document element restrictions - Rule 11-36, Reference schema imports reference schema: Section 11.8, Schema assembly - Rule 11-37, Extension schema document imports reference or extension schema: Section 11.8, Schema assembly - Rule 11-38, Structures imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant - Rule 11-39, XML namespace imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant - Rule 11-40, Each namespace may have only a single root schema in a schema set: Section 11.8, Schema assembly - Rule 11-41, Consistently marked namespace imports: Section 11.8, Schema assembly + Rule 11-2, Base type definition defined by conformant schema: Section 11.1.1, Type definition hierarchy + Rule 11-3, Name of simple type ends in "SimpleType": Section 11.1.2, Simple type definition + Rule 11-4, Use lists only when data is uniform: Section 11.1.2.1, Derivation by list + Rule 11-5, List item type defined by conformant schemas: Section 11.1.2.1, Derivation by list + Rule 11-6, Union member types defined by conformant schemas: Section 11.1.2.2, Derivation by union + Rule 11-7, Name of a code simple type has standard suffix: Section 11.1.2.3, Code simple types + Rule 11-8, Code simple type corresponds to a code list: Section 11.1.2.3, Code simple types + Rule 11-9, Attribute of code simple type has code representation term: Section 11.1.2.3, Code simple types + Rule 11-10, Complex type with simple content has structures:SimpleObjectAttributeGroup: Section 11.1.3, Complex type definition + Rule 11-11, Element type does not have a simple type name: Section 11.2.1, Element declaration + Rule 11-12, Element type is from conformant namespace: Section 11.2.1, Element declaration + Rule 11-13, Name of element that ends in "Abstract" is abstract: Section 11.2.1, Element declaration + Rule 11-14, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations + Rule 11-15, Name of element declaration with simple content has representation term: Section 11.2.1.1, Object element declarations + Rule 11-16, Element substitution group defined by conformant schema: Section 11.2.2, Element substitution group + Rule 11-17, Attribute type defined by conformant schema: Section 11.2.3, Attribute declaration + Rule 11-18, Attribute name uses representation term: Section 11.2.3, Attribute declaration + Rule 11-19, Element or attribute declaration introduced only once into a type: Section 11.3.2.1, Element use + Rule 11-20, Element reference defined by conformant schema: Section 11.3.2.1, Element use + Rule 11-21, Referenced attribute defined by conformant schemas: Section 11.3.3, Attribute use + Rule 11-22, Schema uses only known attribute groups: Section 11.3.3.1, Attribute group use + Rule 11-23, Data definition does not introduce ambiguity: Section 11.6.1, Human-readable documentation + Rule 11-24, Object class has only one meaning: Section 11.6.1, Human-readable documentation + Rule 11-25, Data definition of a part does not redefine the whole: Section 11.6.1, Human-readable documentation + Rule 11-26, Do not leak representation into data definition: Section 11.6.1, Human-readable documentation + Rule 11-27, Data definition follows 11179-4 requirements: Section 11.6.1, Human-readable documentation + Rule 11-28, Data definition follows 11179-4 recommendations: Section 11.6.1, Human-readable documentation + Rule 11-29, Standard opening phrase for augmentation point element: Section 11.6.1.1.1, Element opening phrases + Rule 11-30, Standard opening phrase for augmentation element: Section 11.6.1.1.1, Element opening phrases + Rule 11-31, Standard opening phrase for metadata element: Section 11.6.1.1.1, Element opening phrases + Rule 11-32, Standard opening phrase for association element: Section 11.6.1.1.1, Element opening phrases + Rule 11-33, Standard opening phrase for abstract element: Section 11.6.1.1.1, Element opening phrases + Rule 11-34, Standard opening phrase for date element: Section 11.6.1.1.1, Element opening phrases + Rule 11-35, Standard opening phrase for quantity element: Section 11.6.1.1.1, Element opening phrases + Rule 11-36, Standard opening phrase for picture element: Section 11.6.1.1.1, Element opening phrases + Rule 11-37, Standard opening phrase for indicator element: Section 11.6.1.1.1, Element opening phrases + Rule 11-38, Standard opening phrase for identification element: Section 11.6.1.1.1, Element opening phrases + Rule 11-39, Standard opening phrase for name element: Section 11.6.1.1.1, Element opening phrases + Rule 11-40, Standard opening phrase for element: Section 11.6.1.1.1, Element opening phrases + Rule 11-41, Standard opening phrase for association type: Section 11.6.1.1.2, Complex type opening phrases + Rule 11-42, Standard opening phrase for augmentation type: Section 11.6.1.1.2, Complex type opening phrases + Rule 11-43, Standard opening phrase for metadata type: Section 11.6.1.1.2, Complex type opening phrases + Rule 11-44, Standard opening phrase for complex type: Section 11.6.1.1.2, Complex type opening phrases + Rule 11-45, Standard opening phrase for simple type: Section 11.6.1.1, Data definition opening phrases + Rule 11-46, Same namespace means same components: Section 11.7.1, xs:schema document element restrictions + Rule 11-47, Different version means different view: Section 11.7.1, xs:schema document element restrictions + Rule 11-48, Reference schema imports reference schema: Section 11.8, Schema assembly + Rule 11-49, Extension schema document imports reference or extension schema: Section 11.8, Schema assembly + Rule 11-50, Structures imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant + Rule 11-51, XML namespace imported as conformant: Section 11.8.1, Supporting namespaces are imported as conformant + Rule 11-52, Each namespace may have only a single root schema in a schema set: Section 11.8, Schema assembly + Rule 11-53, Consistently marked namespace imports: Section 11.8, Schema assembly Rule 12-1, Instance must be schema-valid: Section 12, XML instance document rules - Rule 12-2, Attribute structures:ref must reference structures:id: Section 12.2, Reference elements - Rule 12-3, Linked elements have same validation root: Section 12.2, Reference elements - Rule 12-4, Attribute structures:ref references element of correct type: Section 12.2, Reference elements - Rule 12-5, Reference and content elements have the same meaning: Section 12.2.1, Reference and content elements have same meaning - Rule 12-6, Empty content has no meaning: Section 12, XML instance document rules - Rule 12-7, Metadata applies to referring entity: Section 12.3, Instance metadata - Rule 12-8, Referent of structures:relationshipMetadata annotates relationship: Section 12.3, Instance metadata - Rule 12-9, Values of structures:metadata refer to values of structures:id: Section 12.3, Instance metadata - Rule 12-10, Value of structures:relationshipMetadata refers to value of structures:id: Section 12.3, Instance metadata - Rule 12-11, structures:metadata and structures:relationshipMetadata refer to metadata elements: Section 12.3, Instance metadata - Rule 12-12, Attribute structures:metadata references metadata element: Section 12.3, Instance metadata - Rule 12-13, Attribute structures:relationshipMetadata references metadata element: Section 12.3, Instance metadata - Rule 12-14, Metadata is applicable to element: Section 12.3, Instance metadata + Rule 12-2, Empty content has no meaning: Section 12.1, The meaning of NIEM data + Rule 12-3, Element has only one resource identifying attribute: Section 12.2, Identifiers and references + Rule 12-4, Attribute structures:ref must reference structures:id: Section 12.2.1, Local identifiers and references + Rule 12-5, Linked elements have same validation root: Section 12.2.1, Local identifiers and references + Rule 12-6, Attribute structures:ref references element of correct type: Section 12.2.1, Local identifiers and references + Rule 12-7, structures:uri denotes resource identifier: Section 12.2.2, Uniform resource identifiers in NIEM data + Rule 12-8, structures:id denotes resource identifier: Section 12.2.2, Uniform resource identifiers in NIEM data + Rule 12-9, structures:ref denotes resource identifier: Section 12.2.2, Uniform resource identifiers in NIEM data + Rule 12-10, Nested elements and references have the same meaning.: Section 12.2.4, Reference and content elements have same meaning + Rule 12-11, Metadata applies to referring entity: Section 12.3, Instance metadata + Rule 12-12, Referent of structures:relationshipMetadata annotates relationship: Section 12.3, Instance metadata + Rule 12-13, Values of structures:metadata refer to values of structures:id: Section 12.3, Instance metadata + Rule 12-14, Value of structures:relationshipMetadata refers to value of structures:id: Section 12.3, Instance metadata + Rule 12-15, structures:metadata and structures:relationshipMetadata refer to metadata elements: Section 12.3, Instance metadata + Rule 12-16, Attribute structures:metadata references metadata element: Section 12.3, Instance metadata + Rule 12-17, Attribute structures:relationshipMetadata references metadata element: Section 12.3, Instance metadata + Rule 12-18, Metadata is applicable to element: Section 12.3, Instance metadata Appendix F. General index diff --git a/structures.xsd b/structures.xsd index 89c67b7..54da0c5 100644 --- a/structures.xsd +++ b/structures.xsd @@ -1,7 +1,7 @@ @@ -14,6 +14,7 @@ + @@ -25,6 +26,7 @@ + @@ -42,6 +44,7 @@ + @@ -56,12 +59,14 @@ + + diff --git a/xml-catalog.sch.xsl b/xml-catalog.sch.xsl deleted file mode 100644 index ef285dd..0000000 --- a/xml-catalog.sch.xsl +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - / - - - - - - *[local-name()=' - - ' and namespace-uri()=' - - '] - - - - [ - - ] - - - - / - - @ - - - @*[local-name()=' - - ' and namespace-uri()=' - - '] - - - - - - - - - / - - - [ - - ] - - - - /@ - - - - - - - / - - - [ - - ] - - - - /@ - - - - - - - - - - - - - - - - - - - - - - - - . - - - - - U - - U - - - - U. - - n - - - - U. - - _ - - _ - - - - - - - - - -   -   -   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Assertions about XML Catalog - - - - - - - - - - - - - - - - - Document element must be catalog:catalog. - - - - - - - - - - - - - - - - - - - - - - - - - - catalog:uri must have @name. - - - - - - - - - - - - - catalog:uri must have @uri. - - - - - - - - - - - - - - - - - - - - - - - - - - There should be only one catalog:uri for an @name, but there is a duplicate for @name=" - - ." - - - - - - - - - - - - - - - - - - - - - - - - - - catalog:uri/@uri must resolve to an XML document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Referenced XML document must have document element xs:schema. - - - - - - - - - - - - - Document element xs:schema of referenced XML Schema document must have @targetNamespace. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Document element xs:schema of referenced XML Schema document must have @targetNamespace=@name (which is " - - "). - - - - - - - - - -