Create subset schemas, and extension schemas, and sample instances based on the previous mapping and modeling work. Verify that schemas and instances are valid and that they meet NIEM conformance requirements described by the NIEM Naming and Design Rules (NDR) specification.
There are three main kinds of artifacts that should be built during this stage of the IEPD development process: NIEM subset schemas, IEPD extension schemas, and sample instances.
NIEM subset schemas should contain all of the NIEM properties and types that will be reused in the IEPD, plus any dependencies. IEPDs typically contain customized NIEM subsets rather the full set of NIEM release schemas (12,000+ elements in NIEM 5.0 and dozens of schemas) in order to improve performance and reduce size and complexity.
NIEM subset schemas are usually built with the Subset Schema Generation Tool (SSGT), which lets users search the NIEM model, select properties and types, and generate NIEM XML subset schemas. See the SSGT page under the Reference / Tools section for a lot more information about how to search NIEM, build subsets, and reload wantlists later for additional work.
Starting with the Mapping Spreadsheet filled in during the previous stage of the IEPD lifecycle, find each mention of a NIEM property or type, search for it in the SSGT, and add it to the subset. When finished, download the subset. Extract the subset schemas from the downloaded zip file into a NIEM subset folder within the IEPD working directory.
Build NIEM subsets while filling in the mapping spreadsheet during the Map and Model phase in order to prevent looking up the same properties and types a second time. As matches are found in the SSGT and mappings are recorded, add the NIEM property or type to build the subset at the same time.
As extension schemas are developed, the NIEM subset schemas may need to be updated several times to account for additional NIEM properties or types that were not identified during the previous mapping phase. If the subset is no longer loaded in the SSGT, reload the wantlist from the previous subset package to resume work on the subset. Regenerate the subset and update the schemas in the IEPD working directory.
Create one or more schemas to hold the new properties and types that will need to be created specifically for this IEPD. Extension schemas typically import multiple schemas from the NIEM subset, most often including Core and structures (for basic NIEM infrastructure support).
With the extension schema, create NIEM-conformant properties and types for the requirements identified in the mapping spreadsheet as either a “no match” or an “add”. Preliminary modeling work will have already been done for the requirements labeled as “add”. See the modeling information if needed from the previous lifecycle stage for a starting point on how to model local data requirements as NIEM extensions.
See the Concepts section for lots of information about the various NIEM modeling constructs, and for schema and instance examples of each in XML and JSON. Start with Namespaces to set up the extension namespace.
Create at least one sample instance for each kind of message defined by the IEPD. Create more than one of each if needed to better illustrate different options for sending data.
Oxygen and XMLSpy are capable of initializing sample instances given schemas and a selected element to use as the root of the document. Instances generated in this manner should then be updated to add desired fields the tool may have left out of the message and to replace generic strings and other values with realistic-looking ones. This will help reviewers and IEPD implementers understand what messages should really look like.
If NIEM subset schemas are generated by the SSGT, no extra validation for these schemas should be needed. All IEPD extension schemas and any NIEM subset schemas generated by hand or by other methods should be tested for basic schema validation and NDR conformance validation.
Use tools or libraries like XMLSpy, Oxygen, Saxon, Xerces, or Ajv (JavaScript validator for JSON schema) to perform schema validation.
Using the tools or libraries listed above, check the sample instances against their schemas to ensure they are valid.
In addition to verifying schemas and instances conform to basic format and NDR rules, it’s important to make sure that the IEPD meets the original data requirements defined in the Analyze Requirements lifecycle phase.
Go back to the data requirements that were documented in UML, a mapping spreadsheet, or a custom format, and compare that to the sample instance. Make sure all of the requirements are accounted for in the instance. It can be easy to leave small things out and sometimes difficult to discover without carefully comparing the original requirements to a thorough example of the final product.
For XML schemas, the NIEM Naming and Design Rules (NDR) defines may of its rules in Schematron, allowing automated conformance testing. This can be done by either uploading the schemas to ConTesA or by validating the NDR Schematron rules with Oxygen. Review errors, update schemas and sample instances as needed, and rerun all validation steps until conformance issues have been resolved.
Not all rules in the NDR are able to be written in Schematron and automated; some rules must be evaluated manually. The conformance report generated by ConTesA will also provide a list of manual rules. The Rule Browser is another way to find and learn about the text-style NDR rules that require manual evaluation.
At the end of this stage, the full set of NIEM subset schemas and IEPD extension schemas should be complete, and there should be one or more sample instances that illustrate what messages should look like. These are required artifacts for the IEPD.