Niem

As you build your extension and exchange schemas, you might need additional components from NIEM that you did not include in your subset.

Before you create a model for your exchange, it is useful to understand how the NIEM data model is structured.

It is best to create a first draft of your model independently without trying to fit it into the NIEM model.

The NIEM tools allow you to save your "shopping list" data selection in an XML file called a "wantlist. "

In addition, a look-up table strategy can be used to add additional metadata to each data element when the NIEM metadata is not sufficient.

As you might expect, NIEM types are represented by classes in a class diagram.

The NIEM model also does not define specific message types or structures for assembling all of the objects in an exchange.

All exchange documents that import a NIEM generated sub-schema use the same meaning or semantics for that data element.

This article isn't long enough to provide a complete introduction to UML modeling, so it focuses on the NIEM-specific pointers.

The actual NIEM-generated and imported sub-schema files are not actually used in the constraint to XForms transformation process.

Table 1 shows the most common NIEM Representation Terms used and how the transform automatically maps these terms into XForms controls.

The NIEM-generated annotations of referenced elements (the definitions) are clearly visible under each data element.

You can use this method when there is a semantically equivalent element in the NIEM model, but it does not quite meet your needs.

These conventions allow general XML transforms to transform the NIEM documents into other structures.

By using NIEM XML Schema structure, naming conventions, and additional metadata, the transformation task is much easier to extend.

The NIEM is a federal XML-centric metadata standard created for the precise exchange of documents.

This article shows examples of NIEM-conformant schemas but does not provide a complete explanation of the XML Schema language.

NIEM does not require any particular method of defining requirements, so this article doesn't describe this process.

NIEM provides a "Work with IEPDs" tool for gathering your IEPD artifacts and assembling the complete package (see Resources for a link).

In this example we use the NIEM, although any controlled vocabulary with sub-schema generation tools can be used.

All association types are extensions (directly or indirectly) of the NIEM core AssociationType.

This is just a sampling of the rules; you can find a complete listing of the NIEM rules in the NDR.

NIEM makes special provisions in its model for relating data to metadata.

A wantlist can be saved and re-loaded back into the NIEM tools as needed for future sessions.

The digest, which contains the most commonly used NIEM components, has a fixed structure and is interoperable across all LEXS-based IEPDs.

There are many benefits for beginning a Web application with a controlled vocabulary or metadata registry such as the NIEM.

NIEM provides detailed guidelines for how to extend the model in a way that maximizes interoperability among NIEM IEPDs.

This article focuses on four small systems: NIEM, XML Schema, XSLT, and XForms.

All elements, attributes, and types in NIEM schemas are global, uniquely named, top-level components.

Another method of NIEM extension is to create a whole new type.

Sub-schemas are subsets of the NIEM schema but remain consistent with NIEM structures.

The NIEM XML data model provides building blocks for common objects.

Aggregations and compositions are treated the same way in NIEM.

The core process in using the NIEM involves creating XML exchange document packages.

The NIEM model uses generalizations, and when appropriate, you should use them in your model, too.

This is an important rule since NIEM conformant documents use namespaces and qualified data elements for all leaf-data elements.

Analogously, a typical form may need only 20 data elements from the NIEM model, so importing the 4000 types and classes is not efficient.

However, instead of giving it the built-in type xsd: boolean, I use niem-xsd: boolean.

For example, it might be useful to modify the structure or names to better fit the NIEM model, where appropriate.

Map your exchange to the NIEM data model.

The majority of the work in creating a NIEM IEPD is now complete.

These sub-schemas are created using the NIEM subset generation tools.

A NIEM constraint file imports other XML Schemas called NIEM sub-schemas.

This means that it can appear anywhere the NIEM element is allowed.

NDR - Schemas is a summary of all of the schema documents and whether they are NIEM conformant.

Now that you understand the process of developing a NIEM IEPD, consider again whether this is a task you should undertake.

For example, trext: BicycleRegisteredIndicator is of type niem-xsd: boolean, a type that was not in my original subset.

NIEM sub-schemas easily combine with state and industry sub-schemas because they reside in their own namespaces.

A schema that defines extensions to the NIEM model, known as the extension schema

NIEM is described as a framework, because it is not just an XML vocabulary for information exchange. It has several components

NIEM; Network for Industrial Environmental Management;

A governance organization that provides training and support and oversees NIEM's evolution over time

NIEM; Network of International Centres of Excellence in the South;