Posts tagged ‘XML Schema’

FEMA Interoperable Communications Grant Language – NIEM and EDXL

The Fiscal Year 2010 “Interoperable Communications Grant Program, Guidance and Application Toolkit” has just been published. My first question on seeing the grant language was, Did they mandate real interoperable data standards for software purchased using grant money?

They did. From Page 20:

Grant-funded systems, developmental activities, or services related to emergency response information sharing should conform as much as possible with the OASIS Emergency Data Exchange Language (EDXL) suite of data messaging standards and National Incident Management System (NIMS) guidelines. Additional information on data messaging standards and their applicability may be found at www.oasis-open.org. The NIMS Supporting Technology Evaluation Program (NIMS STEP) provides objective evaluations of commercial software and hardware products, and reports on product conformity to standards and NIMS guidelines. Findings from evaluations may be accessed through the Responder Knowledge Base (RKB) website to assist grantees in making purchases. More information on the NIMS STEP can be found at https://www.rkb.us/contentdetail.cfm?content_id=219711.

And Again from page 28 under Technology:

National Information Exchange Model (NIEM). FEMA requires all grantees to use the latest NIEM specifications and guidelines regarding the use of Extensible Markup Language (XML) for all grant awards. Further information about the required use of NIEM specifications and guidelines is available at http://www.niem.gov.

NIEM is XML. EDXL is XML. What gives? Who has precedence? Why is EDXL mentioned in the Funding Restrictions section and NIEM in the Administrative Requirements section?

In reality, you can ignore the apparent confusion. The requirements are valid and complimentary. For the most part, EDXL standards are accepted by NIEM as “approved external standards.” So you do not violate the NIEM requirements by using them, provided you use them as-is, in their entirety. If you use use individual elements (or a subset of elements) from an EDXL schema) in a way that does not validate against one of the schema standards, you are actually violating both EDXL and NIEM unless you document the use of those elements using the formal NIEM Information Exchange Package Documentation (IEPD) methodology as defined at niem.gov. So if you want to use a system that uses EDXL-Common Alerting Protocol (CAP), EDXL- Distribution Element (EDXL-DE), EDXL-Resource Messaging (EDXL-RM), and/or EDXL-Hospital Availability (EDXL-HAVE), go ahead. You are within the terms of the grant language. But if you modify (aka “improve”) the standards in any way, you must go through a formal IEPD process.

If, however you have requirements for information exchange that are not met by existing standards, NIEM offers you the opportunity to reuse existing NIEM IEPDs, build a new IEPD from existing NIEM data definition resources, or build an IEPD from a combination of data definition resources. It is a well-defined process that is designed to maximize reuse and minimize redundancy in data structure definitions supporting emergency management dat exchange requirements.

So, to summarize, if the software you are considering for purchase/development with your grant money reuses EDXL Exchange Standards and/or NIEM IEPDs, you are home free. If not, the system needs to define its exchanges with other systems following NIEM IEPD development rules as found at NIEM.gov

Using NIEM IEPDs to Document Federated Use of XML Standards

I have been studying the National Information Exchange Model (NIEM) fairly extensively over the last few weeks. I have even read the NIEM Naming and Design Rules document from beginning to end. I will admit that I went into it with something of a jaundiced view.  As a veteran contributor to the DoD data model and an outside observer of the GJXDM (recently), and a large scale IBM model (a long time ago), I have real reservations about the usability and maintainability of any all-knowing, all-seeing model.  I have, at least at this point, become a believer in NIEM.  Why?   Because NIEM accepts the notion that a federation between separately name-spaced models makes sense, both within NIEM, and with external standards defined outside the heavy NIEM NDR discipline (or defined with a different heavy discipline).   The notion of defining an Adapter for NIEM use of other standards is a brilliant concept.  This, combined with the Information Exchange Package Documentation (IEPD) methodology for documenting the contextual use of data used in exchanges has made me a fan.

The problem with this “federation of standards” concept is that it makes tools (and “auto-magic” validation) harder to build.  As a result there is a tendency to try and force all of the standards back into the all-knowing, all-seeing model. It is a seductive idea, but not a good idea.  Let’s look at a very simple example: EDXL Resource Management uses the Customer Information Quality (CIQ standard) for Person Names. This allows internationalization for all kinds of different Naming structures and for a wide variety of Addressing schemes.  NIEM (as a national model) is much more U.S. centric, particularly in the use of PersonName tag. Both CIQ and NIEM are appropriate in their respective namespaces (and the NIEM NDR respects this fact by allowing for the adapter wrapper for external standards).   If we try to combine the two standards by defining CIQ elements as NIEM elements directly in order to make the subschema generator work more easily, we blur important distinctions that were developed for good reason.

So, we need to use NIEM IEPD methods. They are excellent. But we must resist the desire to force single definitions for concepts that may appear to be the same, but actually differ due to the context in which they were defined.  In other words, do not force a merger of conceptual domains, unless they actually are the same.  NIEM lets us federate in the building of an IEPD.   We should take advantage of that capability.

Customer Information Quality (CIQ) Issues Resolved

We figured it out at the Emergency Management Technical Committee Messaging subcommittee meeting yesterday.   There was an error in the CIQ schema.  We have submitted a fix to the the OASIS CIQ committee chairman.  All is good. Our Resource Messaging schemas work. Yea!!!