A NIEM schema that provides authoritative definitions of broadly reusable schema components and follows a stricter syntax. NIEM release schemas are REFs.
A NIEM schema for special-purpose content with little reuse expected. EXTs may thus follow a slightly more relaxed syntax. IEPD extension schemas are often EXTs.
A NIEM schema that provides authoritative definitions of broadly reusable schema components and follows a stricter syntax. NIEM release schemas are REFs.
A NIEM schema for special-purpose content with little reuse expected. EXTs may thus follow a slightly more relaxed syntax. IEPD extension schemas are often EXTs.
A NIEM schema that provides authoritative definitions of broadly reusable schema components and follows a stricter syntax. NIEM release schemas are REFs.
A NIEM schema for special-purpose content with little reuse expected. EXTs may thus follow a slightly more relaxed syntax. IEPD extension schemas are often EXTs.
A NIEM schema that provides authoritative definitions of broadly reusable schema components and follows a stricter syntax. NIEM release schemas are REFs.
A NIEM schema for special-purpose content with little reuse expected. EXTs may thus follow a slightly more relaxed syntax. IEPD extension schemas are often EXTs.
A set of schemas, corresponding to a set of full reference schemas, that have been reduced and constrained to include only the files and components needed for an information exchange.
A set of artifacts that define the content, structure, and meaning of an information exchange message. The schemas contained by the IEPD must conform to the NIEM Naming and Design Rules (NDR).
An IEPD with a less-strict set of requirements. A well-formed IEPD focuses on the format and structure of the package, includes a valid IEPD catalog with no broken links, and includes and uses other general IEPD artifacts correctly; however, schema conformance to the NIEM Naming and Design Rules (NDR) is not required.
A set of schemas, corresponding to a set of full reference schemas, that have been reduced and constrained to include only the files and components needed for an information exchange.
An abstract concept that brings together the necessary components to define validity of XML documents with respect to code lists, and to identify correspondences between XML data and code list distinct entries.
NIEM JSON document strictly conformant to a schema
A NIEM JSON document strictly conformant to a schema is a JSON-LD document that may be assigned a one-to-one correspondence to a conformant instance XML document valid against a conformant schema document set.
A NIEM JSON document laxly conformant to a schema is a JSON-LD document that may be interpreted using the RDF vocabulary defined by a conformant schema document set.
NIEM JSON document strictly conformant to a schema
A NIEM JSON document strictly conformant to a schema is a JSON-LD document that may be assigned a one-to-one correspondence to a conformant instance XML document valid against a conformant schema document set.
A NIEM JSON document laxly conformant to a schema is a JSON-LD document that may be interpreted using the RDF vocabulary defined by a conformant schema document set.
Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/#ReferenceSchemaDocument MUST be a reference schema document.
Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/#ExtensionSchemaDocument MUST be an extension schema document.
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.
The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/#ReferenceSchemaDocument.
The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/3.0/#ExtensionSchemaDocument.
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 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".
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 within an element occurrence MUST be identical, regardless of the model group used to define a schema component.
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.
Within the schema, a complex type definition MUST be one of the following:
- An object type.
- An association type.
- A metadata type.
- An augmentation type.
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.
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.
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 definition MUST be a complex type definition with complex content that extends structures:ObjectType, and that uses xs:sequence as its top-level compositor.
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 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.
Given:Element $relationship establishes a relationship between $base-value and the value of $relationship.
- Some element has a value $base-value.
- Value $base-value contains element $augmentation.
- Element $augmentation has property [element declaration] with a value that is an augmentation element declaration.
- Element $augmentation has a value, by reference or by content.
- The value of $augmentation contains element $relationship.
- Element $relationship has a value, by reference or by content.
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.
Within a reference schema document, a complex type definition MUST NOT have an element use of
- an augmentation element declaration, or
- an element declration that is in the substitution group of an augmentation point element declaration.
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.
- 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.
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.
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 name of any XML Schema component defined by the schema MUST contain only the following characters:Other characters, such as the underscore (_) character and the period (.) character MUST NOT appear in component names in NIEM-conformant schemas.
- Upper-case letters (A–Z).
- Lower-case letters (a–z).
- Digits (0–9).
- Hyphen (-).
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.
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.
An element term: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.
An element information item term:LocalTerm MUST establish a term as follows:
- 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.
- 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.
- The value of the attribute definition is a dictionary-style description of the meaning of the local term.
- 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.
- Each child element information item term:SourceText is a plain text citation of, reference to, or bibliographic entry for an originating or authoritative document defining the term.
Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.
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).
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.
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.
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.
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 name of a proxy type does not end in "Type". A type definition schema component that does not define a proxy type MUST have a name that ends in "Type".
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.
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 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.
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.
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 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/3.0/}SimpleObjectAttributeGroup. A data type for a kind of passport.
Within the schema, an element declaration or attribute decaration 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.
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.
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.
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.
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.
The data definition for an augmentation point element SHOULD begin with standard opening phrase "an augmentation point...". The data definition for an augmentation element SHOULD begin with the standard opening phrase "supplements..." or "additional information about...". The data definition for a metadata element SHOULD begin with the standard opening phrase "metadata about..." or "information that further qualifies...". The data defintion for an association element that is not abstract SHOULD begin with the standard opening phrase "an (optional adjectives) (relationship|association)...". The data defintion for an abstract element SHOULD begin with the standard opening phrase "a data concept...". The data defintion for an element with a date representation term SHOULD begin with the standard opening phrase "a(n?) (optional adjectives) (date|month|year)...". The data defintion for an element with a quantity representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (count|number)...". The data defintion for an element with a picture representation term SHOULD begin with the standard opening phrase "an (optional adjectives) (image|picture|photograph)". The data defintion for an element with an indicator representation term SHOULD begin with the standard opening phrase "true if ...; false (otherwise|if)...". The data defintion for an element with an identification representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) identification...". The data defintion for an element with a name representation term SHOULD begin with the standard opening phrase "(a|an) (optional adjectives) name...". The data defintion for an element declaration with a name SHOULD begin with the standard opening phrase "(a|an)".
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 augmentation type SHOULD begin with the standard opening phrase "a data type (that supplements|for additional information about)...". The data definition for a metadata type SHOULD begin with the standard opening phrase "a data type for (metdata about|information that further qualifies)...". The data definition for a type SHOULD begin with the standard opening phrase "a data type...".
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.
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.
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.
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.
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.
- $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
Given that:Every element that has an attribute structures:ref MUST have a referencing element type definition that is validly derived from the referenced element type definition.
- $element is an element information item
- $element has attribute structures:ref with value $ref
- $element has property [element declaration] 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
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.
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.
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.
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.
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.
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.
Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a metadata element declaration.
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.
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.
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.
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.
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.
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.
The document MUST have an effective conformance target identifier of 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/#ExtensionSchemaDocument.
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.
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".
This rule does not constrain attribute uses that are required An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed.
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.
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.
Within the schema, a complex type definition MUST be one of the following:
- An object type.
- An association type.
- A metadata type.
- An augmentation type.
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.
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.
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 definition MUST be a complex type definition with complex content that extends structures:ObjectType, and that uses xs:sequence as its top-level compositor.
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.
A schema document containing an element declaration for an augmentation point element MUST also contain a type definition for its base type, a corresponding augmentable type.
Given:Element $relationship establishes a relationship between $base-value and the value of $relationship.
- Some element has a value $base-value.
- Value $base-value contains element $augmentation.
- Element $augmentation has property [element declaration] with a value that is an augmentation element declaration.
- Element $augmentation has a value, by reference or by content.
- The value of $augmentation contains element $relationship.
- Element $relationship has a value, by reference or by content.
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.
Within a reference schema document, a complex type definition MUST NOT have an element use of
- an augmentation element declaration, or
- an element declaration that is in the substitution group of an augmentation point element declaration.
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.
- 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.
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.
The name of any XML Schema component defined by the schema SHOULD be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED].
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.
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.
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 schema SHOULD use, in defined names, the abbreviations identified by Table 10-1, Abbreviations used in schema component names, rather than their full meanings.
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.
An element information item appinfo:LocalTerm MUST establish a term as follows:
- 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.
- 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.
- The value of the attribute definition is a dictionary-style description of the meaning of the local term.
- 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.
- 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.
Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.
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).
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.
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.
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.
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 name of a proxy type does not end in "Type". A type definition schema component that does not define a proxy type MUST have a name that ends in "Type".
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.
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 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.
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.
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".
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. A data type for a kind of passport.
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".
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.
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.
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.
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.
A data definition SHOULD 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.
The data definition for a metadata element SHOULD begin with the standard opening phrase "Metadata about..." or "Information that further qualifies...".
The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "An (optional adjectives) (relationship|association)...".
The data definition for an element or attribute with a date representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) (date|month|year)...".
The data definition for an element or attribute with a quantity representation term SHOULD begin with the standard opening phrase "An (optional adjectives) (count|number)...".
The data definition for an element or attribute with a picture representation term SHOULD begin with the standard opening phrase "An (optional adjectives) (image|picture|photograph)".
The data definition for an element or attribute with an indicator representation term SHOULD begin with the standard opening phrase "True if ...; false (otherwise|if)...".
The data definition for an element or attribute with an identification representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) identification...".
The data definition for an element or attribute with a name representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) name...".
The data definition for an augmentation type SHOULD begin with the standard opening phrase "A data type (that supplements|for additional information about)...".
The data definition for a metadata type SHOULD begin with the standard opening phrase "A data type for (metadata about|information that further qualifies)...".
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.
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 profiles of the same set of components.
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.
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.
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.
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.
- $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
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.
- $element is an element information item
- $element has attribute structures:ref with value $ref
- $element 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
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 value of an attribute structures:id with a value of $value, or an attribute 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.
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.
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.
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.
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.
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.
Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a metadata element declaration.
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.
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.
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.
Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/#ReferenceSchemaDocument MUST be a reference schema document.
Any schema document with an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/#ExtensionSchemaDocument MUST be an extension schema document.
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.
The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/#ReferenceSchemaDocument.
The document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/naming-and-design-rules/5.0/#ExtensionSchemaDocument.
The interpretation of a conformant instance XML document MUST be consistent with an RDFS interpretation of the RDF graph composed of the RDF entailed by the XML document and the RDF entailed by the schema.
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.
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".
This rule does not constrain attribute uses that are required An element xs:attribute that is not a required attribute use MUST NOT have an attribute {}fixed.
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.
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.
Within the schema, a complex type definition MUST be one of the following:
- An object type.
- An association type.
- A metadata type.
- An augmentation type.
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.
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.
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 definition MUST be a complex type definition with complex content that extends structures:ObjectType, and that uses xs:sequence as its top-level compositor.
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.
A schema document containing an element declaration for an augmentation point element MUST also contain a type definition for its base type, a corresponding augmentable type.
Given:Element $relationship establishes a relationship between $base-value and the value of $relationship.
- Some element has a value $base-value.
- Value $base-value contains element $augmentation.
- Element $augmentation has property [element declaration] with a value that is an augmentation element declaration.
- Element $augmentation has a value, by reference or by content.
- The value of $augmentation contains element $relationship.
- Element $relationship has a value, by reference or by content.
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.
Within a reference schema document, a complex type definition MUST NOT have an element use of
- an augmentation element declaration, or
- an element declaration that is in the substitution group of an augmentation point element declaration.
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.
- 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.
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.
The name of any XML Schema component defined by the schema SHOULD be composed of words from the English language, using the prevalent U.S. spelling, as provided by [OED].
The name of an XML Schema component defined by the schema MUST be in the scope of an occurrence of attribute xml:lang that has a value that is not empty.
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.
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.
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 schema SHOULD use, in defined names, the abbreviations identified by Table 10-1, Abbreviations used in schema component names, rather than their full meanings.
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.
An element information item appinfo:LocalTerm MUST establish a term as follows:
- 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.
- 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.
- The value of the attribute definition is a dictionary-style description of the meaning of the local term.
- 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.
- 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.
Articles, conjunctions, and prepositions MUST NOT be used in NIEM component names except where they are required for clarity or by standard convention.
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).
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, Property representation terms.
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, Property representation terms, SHOULD use a representation term from that table.
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, Property representation terms SHOULD NOT use a representation term.
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 name of a proxy type does not end in "Type". A type definition schema component that does not define a proxy type MUST have a name that ends in "Type".
A schema component with a name that ends in 'SimpleType' MUST be a simple type definition. A schema component with a name that ends in 'Type' and does not end in 'SimpleType' MUST be a complex type definition.
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.
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 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.
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.
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".
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/5.0/}SimpleObjectAttributeGroup. A data type for a kind of passport.
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".
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.
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.
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.
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.
A data definition SHOULD 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.
The data definition for a metadata element SHOULD begin with the standard opening phrase "Metadata about..." or "Information that further qualifies...".
The data definition for an association element that is not abstract SHOULD begin with the standard opening phrase "An (optional adjectives) (relationship|association)...".
The data definition for an element or attribute with a date representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) (date|month|year)...".
The data definition for an element or attribute with a quantity representation term SHOULD begin with the standard opening phrase "An (optional adjectives) (count|number)...".
The data definition for an element or attribute with a picture representation term SHOULD begin with the standard opening phrase "An (optional adjectives) (image|picture|photograph)".
The data definition for an element or attribute with an indicator representation term SHOULD begin with the standard opening phrase "True if ...; false (otherwise|if)...".
The data definition for an element or attribute with an identification representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) identification...".
The data definition for an element or attribute with a name representation term SHOULD begin with the standard opening phrase "(A|An) (optional adjectives) name...".
The data definition for an augmentation type SHOULD begin with the standard opening phrase "A data type (that supplements|for additional information about)...".
The data definition for a metadata type SHOULD begin with the standard opening phrase "A data type for (metadata about|information that further qualifies)...".
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.
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 profiles of the same set of components.
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.
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.
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.
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.
- $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
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.
- $element is an element information item
- $element has attribute structures:ref with value $ref
- $element 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
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 value of an attribute structures:id with a value of $value, or an attribute 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.
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.
Given two properties of object $Object,If $Value1 is less than $Value2, then $Property1 MUST be interpreted as occurring before $Property2 within $Object.If $Value2 is less than $Value1, then $Property2 MUST be interpreted as occurring before $Property1 within $Object.The value of an attribute structures:sequenceID MUST be interpreted as an integer value. Comparisons between their values must be interpreted as comparisons between integers.The relative order of two properties, where either does not have attribute structures:sequenceID is unspecified. The relative order of two properties that have the same value for attribute structures:sequenceID is unspecified.
- property $Property1 with attribute structures:sequenceID with value $Value1, and
- property $Property2 with attribute structures:sequenceID with value $Value2
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.
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.
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.
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.
Each element referenced by an attribute structures:metadata or an attribute structures:relationshipMetadata MUST have [element declaration] that is a metadata element declaration.
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.
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.
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.
A model package description with an MPD class of http://reference.niem.gov/niem/specification/model-package-description/3.0/#IEPD MUST be an information exchange package documentation.
An IEPD MUST have the conformance target identifier http://reference.niem.gov/niem/specification/model-package-description/3.0/#IEPD as a value of its c:mpdClassURIList attribute.
A schema document subset ($SUBSET) for a given reference schema document set ($REFERENCE) MUST be defined such that for all instance XML documents ($XML), where $XML is valid to $SUBSET, $XML is valid to $REFERENCE.
An MPD catalog extension XML catalog document MUST reside in the same relative directory as the mpd-catalog.xml artifact (normally in the MPD root directory)
An MPD catalog extension XML catalog document MUST resolve all MPD catalog schema extension document namespaces to the correct corresponding local URIs in the MPD.
Within an MPD, the schema set formed by mpd-catalog-3.0.xsd and all MPD catalog extension schema documents MUST conform to the [NIEM Naming and Design Rules 3.0] schema set conformance target rules.
Subset schema documents provided to support an MPD schema document extension MUST be a superset of the subset schema documents provided with this specification to support the MPD catalog schema document.
An MPD MUST have an MPD class of a conformance target identifier if and only if that conformance target identifier appears in the c:mpdClassURIList attribute within its MPD catalog document.
An MPD MUST be assigned a version number that adheres to the regular expression:The meaning of the status values are as follows:
- alpha indicates early development; changing significantly.
- beta indicates late development; but changing or incomplete.
- rc indicates release candidate; complete but not approved as operational.
- rev indicates very minor revision that does not impact schema validation.
In an MPD catalog document, the value of a c:mpdURI attribute of type xs:anyURI MUST match the production <absolute-URI> as defined by [RFC 3986 URI], §4.3, Absolute URI.
Within an MPD a URI reference to an artifact in another external MPD (i.e., an MPD artifact URI) is the concatenation of:
- The URI of the MPD that contains the artifact.
- A pound-sign character ("#" — also known as a hashtag character).
- An identifier that is the artifact’s locally unique path name relative to the MPD root directory.
Within an MPD catalog document, the value of a c:pathURI attribute owned by a c:BusinessRulesArtifact element MUST resolve to a business rule schema or business rules artifact.
Within an MPD catalog document, the value of a c:pathURI attribute owned by a c:ReferenceSchemaDocument element MUST resolve to a NIEM reference schema document.
Within an MPD catalog document, the value of a c:pathURI attribute owned by a c:ExtensionSchemaDocument element MUST resolve to a NIEM extension schema document.
Within an MPD catalog document, the value of a c:pathURI attribute owned by a c:SubsetSchemaDocument element MUST resolve to a NIEM subset schema document.
Within an MPD catalog document, the value of a c:pathURI attribute owned by a c:ConstraintSchemaDocumentSet element MUST resolve to a NIEM XML schema document set.
Any XML schema document set whose c:pathURI attribute resolves to a constraint schema document set MUST be interpreted to be a constraint schema document set.
Given an absolute MPD URI [RFC 3986 URI], §4.3, Absolute URI with a fragment, resolve this URI as follows:
- Resolve the base URI (per [RFC 3986 URI]) to retrieve the resource MPD. If the resource MPD does not exist, then fail (existence error).
- Apply the fragment (without "#") to the MPD resource: Locate a structures:id attribute value that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then continue. Locate a path name (for a directory or file) that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then fail (existence error).
- Locate a structures:id attribute value that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then continue.
- Locate a path name (for a directory or file) that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then fail (existence error).
- Return the element, directory, or file found.
Within an XML catalog document, given an XML schema document resolved by the value of a uri attribute owned by a er:uri element, the XML schema document target namespace MUST equal the value of the name (a namespace string) attribute owned by the er:uri element.
A readme artifact SHOULD (at a minimum) describe the MPD purpose, scope, business value, exchange information, typical senders/receivers, interactions, and references to other documentation.
A conformance target identifier for an IEP conformance target declared in an MPD is formed by concatenating in sequence:
- the IEPD URI, and
- the pound sign character (#). and
- a locally unique NCName (i.e., a non-colonized name, as defined by [W3C XML Schema Part 2 Datatypes], §3.3.7, NCName).
Given a c:xPathText attribute owned by c:ValidityContext, the validity constraint context for the descendant’s validity constraint SHALL be the value of c:xPathText evaluated against the IEP’s document information item (See [W3-XML-InfoSet], §2.1, The Document Information Item).
Within an MPD catalog document, if an c:IEPConformanceTarget element for an IEP has a c:HasDocumentElement child element owning a c:qualifiedNameList attribute with a value of $LIST, then the document element of the IEP MUST have a QName that is a member of $LIST.
Within an MPD catalog document with a c:xPathText attribute owned by a c:ValidToXPath element, a candidate IEP is a valid IEP, ONLY IF the value of c:ValidToXPath applied to the candidate IEP (an XML document) has an effective Boolean value (EBV) equal to true. EBV is defined by [W3C XPath 2.0], §2.4.3, Effective Boolean Value.
Within an MPD catalog document with a c:pathURI attribute owned by a c:IEPSampleXMLDocument, the artifact resolved by the value of c:pathURI MUST be valid for the validity constraints of the c:IEPConformanceTarget parent of c:IEPSampleXMLDocument.
If present, a NIEM wantlist MUST reside within the root of the MPD subdirectory that groups and defines its corresponding subset schema document set (e.g., niem).
An MPD in ZIP file format represents a sub-tree of a file system. Such an archive MUST preserve and store the logical directory structure intended by its author for respository format.
Within an MPD, each XML schema document (XSD) or instance XML document (XML) artifact that uses a conformance targets attribute (as defined by [NIEM Conformance Targets Attribute Specification 3.0]) MUST satisfy the [NIEM Naming and Design Rules 3.0] rules for the conformance targets it declares.
An element information item with a type definition validly derived from c:SchemaDocumentSetType MUST have a child element with an element declaration that is in the substitution group of c:XMLCatalog or c:XMLSchemaDocument.
The file name of an IEPD ZIP file (iepd-filename) SHOULD adhere to the syntax defined by the regular expression:The status values are as defined in Rule 5-10, MPD Version Number Syntax, above.
An absolute reference to an Internet resource MUST use a well-known URI scheme (e.g., http, https, ftp, ftps) and MUST resolve. If applicable, documentation SHOULD describe how to resolve with security, account, and/or password information.
Within an MPD, a non-NIEM-conformant external schema document reference to another schema document and/or namespace MUST resolve to a local resource. schemaLocation attributes or XML catalogs can be used to ensure resolution.
Within any artifact of an MPD, any direct reference to another resource (i.e., another artifact such as an image, schema, stylesheet, etc.) that is required to process or display an artifact SHOULD exist within the MPD at the location specified by that reference.
An IEPD MUST have an IEPD conformance target identifier of http://reference.niem.gov/niem/specification/iepd/5.0/#IEPD as a value of its c:iepdConformanceTargetIdentifierURIList attribute.
A schema document subset ($SUBSET) for a given reference schema document set ($REFERENCE) MUST be defined such that for all instance XML documents ($XML), where $XML is valid to $SUBSET, $XML is valid to $REFERENCE.
An IEPD catalog extension XML catalog document MUST reside in the same relative directory as the iepd-catalog.xml artifact (normally in the IEPD root directory)
An IEPD catalog extension XML catalog document MUST resolve all IEPD catalog schema extension document namespaces to the correct corresponding local URIs in the IEPD.
Within an IEPD, the schema set formed by iepd-catalog.xsd and all IEPD catalog extension schema documents MUST conform to the [NIEM Naming and Design Rules] schema set conformance target rules.
Subset schema documents provided to support an IEPD schema document extension MUST be a superset of the subset schema documents provided with this specification to support the IEPD catalog schema document.
An IEPD MUST be assigned a version number that adheres to the regular expression:The meaning of the status values are as follows:
- alpha indicates early development; changing significantly.
- beta indicates late development; but changing or incomplete.
- rc indicates release candidate; complete but not approved as operational.
- rev indicates very minor revision that does not impact schema validation.
In an IEPD catalog document, the value of a c:iepdURI attribute of type xs:anyURI MUST match the production <absolute-URI> as defined by [RFC 3986 URI], §4.3, Absolute URI.
Within an IEPD a URI reference to an artifact in another external IEPD (i.e., an IEPD artifact URI) is the concatenation of:
- The URI of the IEPD that contains the artifact.
- A pound-sign character ("#" — also known as a hashtag character).
- An identifier that is the artifact’s locally unique path name relative to the IEPD root directory.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:BusinessRulesArtifact element MUST resolve to a business rule schema or business rules artifact.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ExternalSchemaDocument element MUST resolve to an XML schema document.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ReferenceSchemaDocument element MUST resolve to a NIEM reference schema document.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ExtensionSchemaDocument element MUST resolve to a NIEM extension schema document.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:SubsetSchemaDocument element MUST resolve to a NIEM subset schema document.
Within an IEPD catalog document, the value of a c:pathURI attribute owned by a c:ConstraintSchemaDocumentSet element MUST resolve to a NIEM XML schema document set.
Any XML schema document set whose c:pathURI attribute resolves to a constraint schema document set MUST be interpreted to be a constraint schema document set.
Given an absolute IEPD URI [RFC 3986 URI], §4.3, Absolute URI with a fragment, resolve this URI as follows:
- Resolve the base URI (per [RFC 3986 URI]) to retrieve the resource IEPD. If the resource IEPD does not exist, then fail (existence error).
- Apply the fragment (without "#") to the IEPD resource: Locate a structures:id attribute value that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then continue. Locate a path name (for a directory or file) that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then fail (existence error).
- Locate a structures:id attribute value that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then continue.
- Locate a path name (for a directory or file) that matches the fragment string. If more than one exist, then fail (ambiguity error). If none exists, then fail (existence error).
- Return the element, directory, or file found.
Within an XML catalog document, given an XML schema document resolved by the value of a uri attribute owned by a er:uri element, the XML schema document target namespace MUST equal the value of the name (a namespace string) attribute owned by the er:uri element.
A readme artifact SHOULD (at a minimum) describe the IEPD purpose, scope, business value, exchange information, typical senders/receivers, interactions, and references to other documentation.
A conformance target identifier for an IEP conformance target declared in an IEPD is formed by concatenating in sequence:
- the IEPD URI, and
- the pound sign character (#). and
- a locally unique NCName (i.e., a non-colonized name, as defined by [W3C XML Schema Part 2 Datatypes], §3.3.7, NCName).
Given a c:xPathText attribute owned by c:ValidityContext, the validity constraint context for the descendant’s validity constraint SHALL be the value of c:xPathText evaluated against the IEP’s document information item (See [W3C XML InfoSet], §2.1, The Document Information Item).
Within an IEPD catalog document, if an c:IEPConformanceTarget element for an IEP has a c:HasDocumentElement child element owning a c:qualifiedNameList attribute with a value of $LIST, then the document element of the IEP MUST have a QName that is a member of $LIST.
Within an IEPD catalog document with a c:xPathText attribute owned by a c:ValidToXPath element, a candidate IEP is a valid IEP, ONLY IF the value of c:ValidToXPath applied to the candidate IEP (an XML document) has an effective Boolean value (EBV) equal to true. EBV is defined by [W3C XPath 3.1], §2.4.3, Effective Boolean Value.
Within an IEPD catalog document with a c:pathURI attribute owned by a c:IEPSampleXMLDocument, the artifact resolved by the value of c:pathURI MUST be valid for the validity constraints of the c:IEPConformanceTarget parent of c:IEPSampleXMLDocument.
If present, a NIEM wantlist MUST reside within the root of the IEPD subdirectory that groups and defines its corresponding subset schema document set (e.g., niem).
An IEPD in ZIP file format represents a sub-tree of a file system. Such an archive MUST preserve and store the logical directory structure intended by its author for respository format.
Within an IEPD, each XML schema document (XSD) or instance XML document (XML) artifact that uses a conformance targets attribute (as defined by [NIEM Conformance Targets Attribute Specification]) MUST satisfy the [NIEM Naming and Design Rules] rules for the conformance targets it declares.
An element information item with a type definition validly derived from c:SchemaDocumentSetType MUST have a child element with an element declaration that is in the substitution group of c:XMLCatalog or c:XMLSchemaDocument.
The file name of an IEPD ZIP file (iepd-filename) SHOULD adhere to the syntax defined by the regular expression:The status values are as defined in Rule 5-9, IEPD Version Number Syntax (WF-IEPD), above.
An absolute reference to an Internet resource MUST use a well-known URI scheme (e.g., http, https, ftp, ftps) and MUST resolve. If applicable, documentation SHOULD describe how to resolve with security, account, and/or password information.
Within an IEPD, a non-NIEM-conformant external schema document reference to another schema document and/or namespace MUST resolve to a local resource. schemaLocation attributes or XML catalogs can be used to ensure resolution.
Within any artifact of an IEPD, any direct reference to another resource (i.e., another artifact such as an image, schema, stylesheet, etc.) that is required to process or display an artifact SHOULD exist within the IEPD at the location specified by that reference.
A code list-enabled schema document MUST have an effective conformance target identifier of http://reference.niem.gov/niem/specification/code-lists/4.0/#SchemaDocument
A resource with an effective conformance target identifier of http://reference.niem.gov/niem/specification/code-lists/4.0/#SchemaDocument MUST be a code list-enabled schema document.
Any XML content in the namespace http://reference.niem.gov/niem/specification/code-lists/4.0/code-lists-instance/ MUST be schema-valid to the XML Schema definitions contained in the schema document in Appendix B, XML Schema document for the code lists instance namespace, below.
An element $element with an attribute $attribute cli:codeListURI denotes a code list binding of:
- a code list identifier of the normalized value of the attribute cli:codeListURI
- a single column/value pair, having: a column reference of: if $element has attribute cli:codeListColumnName, then the normalized value of that attribute, else #code. a data value that is the normalized value of $element.
- a column reference of: if $element has attribute cli:codeListColumnName, then the normalized value of that attribute, else #code.
- a data value that is the normalized value of $element.
- A value for constraining that is: if $element has attribute cli:codeListConstrainingIndicator, then its value, otherwise true.
Any XML content in the namespace http://reference.niem.gov/niem/specification/code-lists/4.0/code-lists-schema-appinfo/ MUST be schema-valid to the XML Schema definitions contained in the schema document in Appendix C, XML Schema document for the code list schema appinfo namespace, below.
An attribute codeListURI that has [owner element] of clsa:SimpleCodeListBinding or clsa:ComplexCodeListBinding MUST have a normalized value that is an absolute URI.
Element clsa:SimpleCodeListBinding MUST be application information on one of:
- element xs:attribute that defines a global attribute declaration
- element xs:element that defines a global element declaration
- element xs:simpleType that defines a global simple type definition
- element xs:complexType that defines a global complex type definition
Element clsa:ComplexCodeListBinding MUST be application information on one of:
- element xs:element that defines a global element declaration
- element xs:complexType that defines a global complex type definition
An element xs:attribute defining an attribute declaration $attribute-declaration with application information of an element $binding-element clsa:SimpleCodeListBinding entails:
- Each attribute $attribute in the instance of the code list validation set with [attribute declaration] equal to $attribute-declaration entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $attribute A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $attribute
- A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is the normalized value of $attribute
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
An element xs:element defining an element declaration $element-declaration with application information of an element $binding-element clsa:SimpleCodeListBinding entails:
- Each element $element in the instance of the code list validation set with [element declaration] that is in the substitution group of $element-declaration entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $element A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $element
- A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is the normalized value of $element
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
An element xs:simpleType or xs:complexType defining a type definition $type-definition with application information of an element $binding-element clsa:SimpleCodeListBinding entails:
- Each attribute $attribute in the instance of the code list validation set with [attribute declaration] with {type definition} derived from $type-definition entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $attribute A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $attribute
- A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is the normalized value of $attribute
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- Each element $element in the instance of the code list validation set with [type definition] derived from $type-definition entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $element A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A column/value pair with: A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code. A data value that is the normalized value of $element
- A column reference of: if $binding-element has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is the normalized value of $element
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
An element xs:element defining an element declaration $element-declaration with application information of an element $binding-element clsa:ComplexCodeListBinding entails:
- Each element $element in the instance of the code list validation set with [element declaration] that is in the substitution group of $element-declaration entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A set of column/value pairs, containing: For each clsa:ElementCodeListBinding child $element-binding of $binding-element: A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty. A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A set of column/value pairs, containing: For each clsa:ElementCodeListBinding child $element-binding of $binding-element: A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
An element xs:complexType defining a complex type definition $type-definition with application information of an element $binding-element clsa:ComplexCodeListBinding entails:
- Each element $element in the instance of the code list validation set with [type definition] derived from $type-definition entails a code list binding with: A code list identifier that is the normalized value of the attribute codeListURI of $binding-element. A list of column/value pairs, containing: For each clsa:ElementCodeListBinding child $element-binding of $binding-element: A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty. A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
- A code list identifier that is the normalized value of the attribute codeListURI of $binding-element.
- A list of column/value pairs, containing: For each clsa:ElementCodeListBinding child $element-binding of $binding-element: A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A column/value pair with: A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code. A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A column reference of: if $element-binding has attribute columnName, then the normalized value of that attribute, else #code.
- A data value that is: if it exists, the first element child of $element that is in the substitution group of an element declaration with a name that is equal to the value of attribute elementName of $element-binding, otherwise empty.
- A value for constraining that is: if $binding-element has attribute constrainingIndicator, then its value, otherwise true.
A code list binding matching against against a code list validation set yields a set of distinct entries and a validity value (valid or invalid).The matches for a code list binding $binding against a code list validation set MUST be:
- The code list identifier $identifier is provided by the $binding.
- Using the entity catalog defined for the code list validation set, resolve code list identifier $identifier to a locally-resolved resource $resource.
- If $resource is not a code list document, or if no resource is identified for $identifier, then this specification does not define any matches for $binding. The binding is evaluated to be invalid. In this case, the code list identified by $identifier SHOULD be handled by means other than this specification.
- If $resource is a code list document, then the set of matches for $binding is the list of distinct entries in the code list for which every column referenced by $binding has the corresponding value. A column/value pair in $binding with a column reference of #code matches as specified for the appropriate class of code list document for that column name. A column/value pair in $binding with a column reference of #range matches: If $resource does not contain a column corresponding to the well-known columns minimum-inclusive, minimum-exclusive, maximum-inclusive, or maximum-exclusive, then the binding has no matches. Otherwise, yield all distinct entries for which all of the following are true, given that the value of the column/value pair is $value: Either there is no code value for column minimum-inclusive, or the code value of that column is less than or equal to $value. Either there is no code value for column minimum-exclusive, or the code value of that column is less than $value. Either there is no code value for column maximum-inclusive, or the code value of that column is greater than or equal to $value. Either there is no code value for column maximum-exclusive, or the code value of that column is greater than $value.
- A column/value pair in $binding with a column reference of #code matches as specified for the appropriate class of code list document for that column name.
- A column/value pair in $binding with a column reference of #range matches: If $resource does not contain a column corresponding to the well-known columns minimum-inclusive, minimum-exclusive, maximum-inclusive, or maximum-exclusive, then the binding has no matches. Otherwise, yield all distinct entries for which all of the following are true, given that the value of the column/value pair is $value: Either there is no code value for column minimum-inclusive, or the code value of that column is less than or equal to $value. Either there is no code value for column minimum-exclusive, or the code value of that column is less than $value. Either there is no code value for column maximum-inclusive, or the code value of that column is greater than or equal to $value. Either there is no code value for column maximum-exclusive, or the code value of that column is greater than $value.
- If $resource does not contain a column corresponding to the well-known columns minimum-inclusive, minimum-exclusive, maximum-inclusive, or maximum-exclusive, then the binding has no matches.
- Otherwise, yield all distinct entries for which all of the following are true, given that the value of the column/value pair is $value: Either there is no code value for column minimum-inclusive, or the code value of that column is less than or equal to $value. Either there is no code value for column minimum-exclusive, or the code value of that column is less than $value. Either there is no code value for column maximum-inclusive, or the code value of that column is greater than or equal to $value. Either there is no code value for column maximum-exclusive, or the code value of that column is greater than $value.
- Either there is no code value for column minimum-inclusive, or the code value of that column is less than or equal to $value.
- Either there is no code value for column minimum-exclusive, or the code value of that column is less than $value.
- Either there is no code value for column maximum-inclusive, or the code value of that column is greater than or equal to $value.
- Either there is no code value for column maximum-exclusive, or the code value of that column is greater than $value.
- If the binding has no matches, then: If the binding is constraining, then it is invalid. If the binding is not constraining, then it is valid.
- If the binding is constraining, then it is invalid.
- If the binding is not constraining, then it is valid.
- If the binding has one or more matches, then it is valid.
Comparisons between a value $instance-value of a column/value pair and a code value $code-value MUST be conducted as follows:
- $instance-value has a data type, $instance-data-type, provided by its XML Schema definition.
- $code-value has a data type, $code-data-type, as provided by its code list document as specified for its class of code list document. That data type is either a data type defined by the XML Schema definition language, or is empty.
- A data type, $comparison-data-type, is calculated as: If $code-data-type is empty, then $instance-date-type. If it exists, the lowest common ancestor of the two data types. Otherwise, xs:string.
- If $code-data-type is empty, then $instance-date-type.
- If it exists, the lowest common ancestor of the two data types.
- Otherwise, xs:string.
- $instance-value and $code-value are cast to $comparison-data-type, in accordance with [XPathFunctions] Section 17, Casting.
- Equality comparisons are conducted as appropriate for $comparison-data-type.
- Inequality comparisons (e.g., less than, greater than) for ranges are conducted as appropriate for lowest atomic base type of $comparison-data-type.
When a code list document defines candidate code list identifiers, a code list identifier against which a code list document resource is resolved MUST be a candidate code list identifier for that code list document.
A CSV file may act as a CSV code list document in the following manner:
- Code list identifiers: The CSV file does not specify its code list identifiers. Each CSV file contains a single code list. The CSV file MAY be resolved to any code list identifier.
- Distinct entries: Each CSV record of the CSV file constitutes a distinct entry.
- Code values: Each CSV field corresponds to a code value.
- Column names: The column name of a code value is the CSV column name corresponding by position within the CSV header to the position of the CSV field within its CSV record
- A column in a CSV file is a well-known column when its CSV column name is the same as the column name of a well-known column.
- A reference to column #code is matched, in order, to: a column with CSV column name of code, or the first column of the CSV file.
- a column with CSV column name of code, or
- the first column of the CSV file.
- A code value in a CSV file has no type; its data type is empty.
A Genericode code list document MUST be a Genericode code list document as defined by [Genericode] Section 3.2, Genericode Document Types, which states: A Genericode code list document has the root element . It contains metadata describing the code list as a whole, as well as explicit code list data — codes and associated values.
A resource with an effective conformance target identifier of http://reference.niem.gov/niem/specification/code-lists/4.0/#GenericodeCodeListDocument MUST be a Genericode code list document.
A Genericode code list document MUST be schema-valid against the schema document for the Genericode namespace as provided at http://docs.oasis-open.org/codelist/ns/genericode/1.0/.
A datatype with a namespace name of http://www.w3.org/2001/XMLSchema-datatypes MUST be evaluated as if it had a namespace name of http://www.w3.org/2001/XMLSchema.
A Genericode code list document may act as a code list document in the following manner:
- Code list identifier: Candidate code list identifiers for the document are the values for CanonicalUri, CanonicalVersionUri, and LocationUri defined by the Genericode document for the code list.
- Distinct entries: Each row of the Genericode code list document constitutes a distinct entry.
- Code values: Each Value element of the Genericode code list document corresponds to a code value.
- Column names: The columns are as defined by Genericode; the column name of a column is the value of attribute Id of that column.
- A column in a Genericode code list document is a well-known column when its value for CanonicalUri or CanonicalVersionUri corresponds to the code list identifier specified for that well-known column.
- A reference to column #code is matched, in order, to: a column corresponding to well-known column code, a column with column name code, the column in the first single-column key for the code list, or the first column in the code list.
- a column corresponding to well-known column code,
- a column with column name code,
- the column in the first single-column key for the code list, or
- the first column in the code list.
- A code value in a Genericode file has a type as specified by the data definition of its column. If the Type attribute references an element declaration, then the type is the type of that element. If a Parameter, which introduces gc:DatatypeFacet, is used, then the type is treated as an anonymous type derived from the type of the column. A value for which no data type is specified has an empty data type.
Within a conformant document, every occurrence of the attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets MUST be locally schema-valid to the XML Schema component definition contained in Figure B-1, XML Schema Document for Conformance Targets Attribute.
A conformant document MUST NOT contain any element or attribute information item that has the namespace name http://release.niem.gov/niem/conformanceTargets/3.0/, other than attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets.
A conformant document MUST NOT contain an attribute {http://www.w3.org/2001/XMLSchema-instance}type with a value that has a namespace name of http://release.niem.gov/niem/conformanceTargets/3.0/.
Within a conformant document, each item in the value of an attribute {http://release.niem.gov/niem/conformanceTargets/3.0/}conformanceTargets MUST be an absolute IRI reference.
The RDF graph entailed by a NIEM JSON document strictly conformant to a schema MUST be equivalent to the RDF graph entailed by a corresponding conformant instance XML document instance of the schema, accounting for literal-to-object conversion and the omission of external content.
The RDF graph consisting of the union of:MUST be RDFS satisfiable, accounting for literal-to-object conversion and the omission of external content.
- the RDF graph entailed by the JSON document and
- the RDF graph entailed by the schema
A NIEM JSON document strictly conformant to a schema or NIEM JSON document laxly conformant to a schema MUST be interpreted as an RDFS interpretation of the RDF graph composed of the RDF entailed by the JSON document together with the RDF entailed by the schema.
The RDF graph entailed by a NIEM JSON document strictly conformant to a schema MUST be equivalent to the RDF graph entailed by a corresponding conformant instance XML document instance of the schema, accounting for NIEM JSON normalization and the omission of external content.
The RDF graph consisting of the union of:MUST be RDFS satisfiable, accounting for literal-to-object conversion and the omission of external content.
- the RDF graph entailed by the JSON document and
- the RDF graph entailed by the schema
A NIEM JSON document strictly conformant to a schema or NIEM JSON document laxly conformant to a schema MUST be interpreted as an RDFS interpretation of the RDF graph composed of the RDF entailed by the JSON document together with the RDF entailed by the schema.