NIEM is best understood as a standards-based framework approach to exchanging information. Data exchange1 designers follow the NIEM approach to create exchange specifications. Developers use those specifications to write software that creates and consumes the exchanged data at runtime.
A NIEM-based exchange specifications are voluntary consensus data standards. NIEM includes a data model, expressed by the data components in the NIEM Core and NIEM domains. However, NIEM also includes governance, training, tools, technical support services, and an active community.2 Any understanding of NIEM as just a data standard or just a data model is therefore incomplete.
It is always possible to express your information in the form of an IEP 3; that is, a NIEM-conforming XML document. If you need an alternative to NIEM, it is because that alternative works better than NIEM in your situation, not because NIEM won’t work at all
That is usually the case. The data components in the NIEM Core and the NIEM domains are intended to be useful in many data exchanges, but they are not expected to be complete for every data exchange. If you can’t find the data component you need in the Core or in any domain, then you simply create a new component as needed for your IEPD. If your new component will be useful in many exchanges, then you should see about adding it to the appropriate domain.
Data exchange designers should avoid needlessly duplicating a data component in the NIEM core or a NIEM domain. However, exchange designers are never required to use a component that is not suitable for their business needs. If a data component for your concept won’t work, and can’t be extended or augmented as you need, then you don’t have to use it. You are free to create your own data component instead. As before, if your new component will be useful in many exchanges, then you should see about adding it to the appropriate domain.
Adapters provide schema metadata to inform tools and developers that the adapted external schema and XML instance data may not conform to the NIEM Naming and Design Rules (NDR). Adapter elements also include the attributes defined by default for every NIEM object. Developers usefully depend on finding these attributes as needed in the message.
NIEM adapters do not involve significant additional effort during development, and do not require special processing at runtime. The entire message can be validated and processed normally. There is no need for a special “NIEM validation engine”, and no need to extract the external content for separate processing. For an illustration of a NIEM adapter in practice, see [EmbeddedGML].