NIEM’s technical architecture is a set of reusable XML schema documents. These schema documents contain commonly used data components and are grouped into abstraction layers. Each abstraction layer reuses and extends data components from previous layers. The graphic below provides a description of NIEM’s abstraction layers.
The rules and guidance that make up NIEM’s technical architecture are designed to encourage and facilitate NIEM use. They are defined in detail by several key documents, including the Model Package Description (MPD) and Naming and Design Rules (NDR).
Namespaces are used to avoid element name conflicts. Therefore, each reference schema in the NIEM model is defined individually by a namespace. Reuse of any component is always by reference to both its namespace and its name. All NIEM component names have global scope.
The rules for the use of namespaces must also be followed for exchange-specific schema documents. It’s critical to evaluate the namespace of a component when browsing the model or building exchanges, as components have different meanings and attributes across the various NIEM domains.
The graphic below provides an overview of naming conventions for data objects in NIEM. Naming conventions start with a namespace prefix. In this example, “nc” stands for the namespace “NIEM core.” Qualifier terms can be inserted into Objects, Property, and Representation Terms to provide additional context.
Here are all the NIEM Namespaces and their associated prefixes.
Read the NDR for more details about the use of namespaces and namespace prefixes.
Code lists are most often used to limit possible values for an element. NIEM conformant code lists can be generated from an Excel spreadsheet by using the NIEM Code List Schema Generator Tool. If code lists are reusable by many exchanges, they have the potential to be integrated into NIEM Core or a NIEM domain. An example of a code list in NIEM core is “nc:LocationCountryFIPS10-4Code,” which is used in the example below. The possible values for that particular element are country codes.
Publication of code lists: Each NIEM code list within the model has a governing body responsible for its content and has authority over its timeline for updates and code list publication. Code lists that are unique to an individual exchange, and not available in core or domain schema documents, are managed by that particular exchange developer.
Code list substitutions: The NIEM model defines an abstract element for each distinct concept that coded elements represent. This allows a code list to be updated independently of the NIEM core. A coded element (whose values are enumerated) is substituted for the abstract element that represents the concept (e.g., country).
Below is an example of a code list.
Association types link together related objects in an exchange. The use of association types prevents the need to redefine objects. Association types are implemented using references. Referencing allows the use of structures:ref attribute, which provides a link to an object with a matching structures:id attribute.
In the example below, the association type “DriverLicenseAssociation” allows both the “Person” and “DriverLicense” to be linked in the exchange through the use of structures:ref attribute.
The diagram below displays the same example in schema and instance format.
The NDR outlines association types. Access the Association section of the NDR.
Every NIEM type that is built from structures:ObjectType or structures:AssociationType contains an "augmentation point" element. An "augmentation point" is an abstract element that acts as a substitution group head, for which additional elements (or containers of elements) of any type may be substituted. These additional elements are “augmentations,” which represent additional characteristics and relationships of the original type.
In summary, augmentation points increase the potential for reuse and adaptation across domains without forcing the creation of many specialized types. The example below displays how the augmentation element “nc:VehicleAugmentationPoint” can be used to create a domain-specific vehicle type.
To learn more about Augmentations, visit the NDR.
Substitution groups are used in augmentation. They consist of elements from multiple domains and together create a new type.
NIEM uses substitution groups to allow a single concept to be represented by multiple elements of different types. Within NIEM, substitution groups allow flexibility in the allowed data types for an element. A user would substitute one of the following elements for nc:DateRepresentation:
The example below demonstrates how to use substitution groups in XML schema.
To learn more about substitution groups, visit the NDR.
Metadata is data that qualifies other data. An nc:Metadata element is used in NIEM to add additional information about data. Metadata types do this by adding descriptive information about data within an XML instance. They can also be used for searching or categorizing data included within an exchange. Metadata can be implemented by reusing existing metadata types within NIEM or creating a new metadata type.
The example below shows the use of Metadata types in schema.
Read the NDR for more information about metadata.
XML Artifacts help define the parts of the model needed in a particular exchange.
NIEM is a relatively large model. When designing an information exchange, it’s not necessary to use all of NIEM. A schema subset based on a given NIEM release is more efficient. A NIEM schema subset contains only those types, elements, and attributes required for a particular information exchange.
Below is a subset schema document that outlines the exchange requirements for the element “VehicleType.”
A wantlist is an XML document that identifies the NIEM types, elements, and attributes that a developer desires to use within the schema document subset for an information exchange. A NIEM-aware tool (such as the Schema Subset Generation Tool—SSGT) can import a wantlist and generate a correct NIEM schema document subset that includes additional NIEM components that the subset depends on.
A NIEM-aware tool can also generate and export a wantlist from a correct NIEM schema document subset.
The example below shows a sample wantlist.
A wantlist does not necessarily identify all the components required for a complete subset. It only identifies the components requested by the developer by name. Those items may depend on other components that will be needed and present in the generated subset but that were not identified in the wantlist. A NIEM-aware tool can add the dependencies to the subset.
An extension schema document extends existing NIEM data components and it can create new NIEM data components. NIEM is a diverse data model, but it may not describe everything needed for an information exchange. An existing NIEM component should only be employed in a context that fits its semantics. Consider reusing, extending, or augmenting a NIEM component with the correct semantics first; but if such a component does not exist for a given situation or context, then create a component per the NIEM NDR. An extension schema document must include a unique target namespace declaration, as well as references to NIEM, W3C, and other extension schema namespaces required. When possible, extension schema documents should be designed for reuse in other information exchange definitions.
Extensions can be candidates for future inclusion into the NIEM model. Learn more about the NIEM harmonization process on the Model Overview page.
The example below shows an example of an extension.
Read the NDR for more information about extensions.
Now that you understand some of the architecture of the model, learn how to build an exchange.