In an extension schema, an IEPD developer can create new NIEM-conformant properties and types to represent message data requirements that are not available in a NIEM release. Extensions schemas are used in combination with NIEM subset schemas to define the structure and meaning of a message.
The NIEM Naming and Design Rules (NDR) Specification defines what an extension schema document (EXT) is and the set of rules it must follow in order to be considered NIEM-conformant.
New components added to extension schemas are often referred to as “extensions”. These extensions may augment, extend, substitute for, or reuse components from NIEM; or they may simply follow the NIEM syntax rules if no reuse is possible.
See the Modeling Concepts section on this site to learn more about setting up a NIEM-conformant schema, how to add basic properties and types, and how and when to use special NIEM techniques. This material also includes XML and JSON examples and templates.
An XML extension schema must declare an ExtensionSchemaDocument conformance target as defined by the NDR.
<xs:schema ct:conformanceTargets="http://reference.niem.gov/niem/specification/naming-and-design-rules/4.0/#ExtensionSchemaDocument"> <xs:schema>
See the page about the Conformance Target Attribute Specification for more details about how to declare a conformance target attribute, additional schema declarations that are required to support this attribute, and other conformance target values.
An IEPD package might be arranged in the following way, with the
base-xsd folder containing three sub-folders for:
myIEPD-2.0/ base-xsd/ niem/ # NIEM subset schemas adapters/ codes/ domains/ external/ niem-core/ ... extension/ # NIEM-conformant extension schemas extension1.xsd extension2.xsd ... xml-catalog.xml external/ # External standards that are not NIEM-conformant ic-ism/ ...
The Model Package Description (MPD) Specification page on this site contains more information about how an IEPD package might be structured.
In order to reuse components from NIEM, the following steps should be taken:
<!-- Declare a prefix for the NIEM Core namespace --> <xs:schema xmlns:nc="http://release.niem.gov/niem/niem-core/4.0/" > <!-- Import the NIEM Core namespace --> <xs:import schemaLocation="../niem/niem-core/4.0/niem-core.xsd" namespace="http://release.niem.gov/niem/niem-core/4.0/"/> <!-- Reuse a NIEM Core type --> <xs:element name="Veterinarian" type="nc:PersonType"> <xs:annotation> <xs:documentation> A professional who practices veterinary medicine by treating diseases, disorders, and injuries in animals. </xs:documentation> </xs:annotation> </xs:element> <!-- Reuse a NIEM Core property (see the element reference below) --> <xs:type name="PatientFileType"> <xs:annotation> <xs:documentation> A data type for a medical file containing a record health and treatment information for a patient. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="structures:ObjectType"> <xs:sequence> <!-- NIEM Core element reference --> <xs:element ref="nc:Address"> </xs:sequence> </xs:extension> </xs:complexContent> </xs:type> </xs:schema>
There are several steps to follow when checking the conformance of an XML extension schema:
Validate XML Schema
Make sure the extension schema is a valid XML Schema. Tools like XMLSpy, Oxygen XML Editor, xmllint, and Xerces can run this validation step.
Declare conformance targets
Make sure the schema declares a
ct:conformanceTargets attribute, with the appropriate value as defined by the NDR.
Check NDR conformance for automated rules
Make sure the schema is conformant to whatever conformance target(s) are declared in the previous step.
ConTesA cannot check extension schema conformance without the conformance target attribute specified. This attribute tells ConTesA which rule set to use for validation. Without this information, ConTesA will not run any tests.
Check NDR conformance for manual rules
Review the extension schema manually against the NDR free-text rules to ensure they are met.
In NIEM JSON, it can be easier to define properties and types from different namespaces together in the same JSON schema. This is because the NIEM conceptual model uses techniques like element substitution and type extension, which do not have the same counterparts in JSON schema. Because of this, JSON extensions can be added to the same JSON schema that defines the NIEM subset for an IEPD and a separate JSON extension schema is not necessary.
There is currently no automated rule assertions for NIEM JSON schemas. The guidance for now is to follow the principles and intents of the NDR rules as closely as possible.