FAQs
For more information regarding NIEM and how you can get involved in the NIEM Community see here - https://www.niem.gov/aboutniem/Pages/how-do-i-get-started.aspx.
NIEM webinars are a convenient way to help you learn more about using NIEM, from general concepts and tools to in-depth technical specifications. Whether you're completely new to NIEM or simply want to hone your skills, you'll find the webinar that's right for you.
Webinars contain videos that will show you how to learn about a variety of useful NIEM tools, including:
NIEM Wayfarer
NIEM Extension Wizard
NIEM Conformance Tool
And more!
For more information regarding NIEM Webinars see here - https://www.niem.gov/training/Pages/webinars.aspx.
The IC-ISM XML Schemas will not be included as part of the NIEM 3.0 release. Instead, each of the NIEM structures base types (ObjectType, AssociationType, AugmentationType, and MetadataType, as well as SimpleObjectAttributeGroup) incorporates an anyAttributes element as part of its definition. This wildcard allows any attributes to appear that have the IC-ISM namespace, as well as those having the IC-NTK namespace. This is in line with the recommendations of the developer of the IC Trusted Data Framework, and should support ISM, NTK, and the TDF. Developers that need schemas for these namespaces should download them from an authoritative source.
JSON is nothing more than a rendering and fully supported by libraries such as the Apache Java XML2JSON library we are using - bi-directional seamless transforms. There is nothing need to do here. NIEM does JSON, and JSON does NIEM, and its completely interchangeable. CAM demonstrates that as a reference implementation and anyone else can easily do this too.
CAM Reference Link: https://www.youtube.com/watch?v=CeDbY0FSX3Y&list=UUHGjVfq4Rm-CC2ClFS2cD6w
For any submissions of wantlist's that do not load or receive an error message, please debug as follows:
1. Ensure the wantlist is a well-formed XML file!!! (use an editor that will check that)
2. Globally remove all cardinality constraints ‘minOccurs=”0” maxOccurs=”unbounded”’ and reload.
3. If wantlist still doesn't load: then globally remove 0,1 cardinality constraints and reload.
4. If wantlist still doesn't load: then globally remove the rest of the cardinality constraints and reload.
5. Do NOT reinsert cardinality constraints for the remaining steps.
6. If wantlist still doesn't load: then validate the wantlist against the correct NIEM wantlist schema.
7. Check that the headers are correct.
8. Ensure the namespaces for components in the wantlist are correct.
9. If wantlist still doesn't load: start a logarithmic decomposition and test each piece until you zero in on the bad component(s).
a. Split the wantlist in half - 2 files, each with the original headers.
b. Load each; if one loads and the other does not, then split the wantlist that does not load, put the other aside as good.
c. If both lists do not load then there is an error in both. Treat each list as another wantlist and split/load.
d. Continue this recursion until you identify the component lines that are incorrect, and remove or correct them.
10. If this still fails, then send a copy of the wantlist to the NISS Helpdesk and tell us when and how it was created (SSGT? another tool? If so, what tool? manually?)
In 2.1, EVERY schema that is NIEM-conformant MUST declare itself such with an i:ConformantIndicator.
Otherwise, the ConTesA ignores the schema and will NOT apply any conformance rules
because it does not recognize the schema as NIEM-conformant.
Here is an example for an exchange schema that should be immediately below the Schema element:
<xsd:annotation>
<xsd:documentation>exchange schema</xsd:documentation>
<xsd:appinfo>
<i:ConformantIndicator>true</i:ConformantIndicator>
</xsd:appinfo>
</xsd:annotation>
This should also be applied to conformant extension schemas as well. User should see the subset schemas – each one contains such an annotation. Note that once these have been inserted, ConTesA will apply other conformance Rules tailored to the schemas to determine what they are (reference, extension, exchange). There will likely be other auto rule failures at that point that had not appeared earlier because no rules are applied to schemas that are assumed to be non-conforming
(because they do not declare conformance with i:ConformantIndicator = TRUE). (a few namespace import issues will likely appear – these will need to be fixed as well)
The NIEM Migration Assistance Tool is an easy tool for you to migrate your current wantlist to the lastest version. The Migration Tool is a tool that allows you to upload your wantlist file that you find in an IEPD, and generate the ouputs for you in just a click of a button. The outputs should include a new migration wantlist, a new subset, and a migration report that indicate the status of that migration resolution.
Here are the supported levels of the tool:
NIEM 3.0 conversion to NIEM 3.0-with-domain-updates
NIEM 2.1-with-domain-updates conversion to NIEM 3.0
NIEM 2.1 to NIEM 2.1-with-domain-updates conversion
NIEM 2.0 to NIEM 2.1 conversion
NIEM 1.0 to NIEM 2.0 conversion
GJXDM 3.0.3 to NIEM 2.0 wantlist conversion
Notice: If you have a wantlist file version NIEM 2.1 and you want to upgrade to the latest version which is NIEM 3.0-with-domain-updated, the tool will migrate the file into the NIEM 2.1-with-domain-updated first, and you will take this wantlist file verison NIEM 2.1-with-domain-updated and continue upload to migrate to the next version. You need to repeat this step until you have the latest wanlist, the latest subset, and the status report.
Migration Assistance Tool: http://tools.niem.gov/niemtools/migration/index.iepd
Magic Draw - Cameo NIEM Plugin Tool can implement the complete NIEM-UML specification with specific enhancements to make modeling for information exchange easier and more effective. NIEM-UML offers a standards-based means to reduce the time, cost, and learning curve of sharing information with NIEM. The Magicdraw implementation provides modeling support for NIEM and can forward and reverse engineer 100% NIEM-conformant IEPDs and reference schema. Once in NIEM-UML, NIEM information models are more easily managed and more intuitive for stakeholders.
For more information on this tool, please click on the links below.
Resources:
Magic Draw - Cameo NIEM Plugin Tool
Creating a NIEM IEPD with NIEM-UML using Cameo NIEM Plugin Tool
Modeling Properties And Associations In NIEM-UML
NIEM-UML Subsetting and Extension
Documents
https://bja.ojp.gov/media/document/29961
https://bja.ojp.gov/media/document/29966
On September 23, 2014, NIEM hosted a Virtual Town Hall. More than 130 community members joined us to hear presentations from a Best of NIEM 2014 winner and updates from representatives of the Emergency Management Domain, as well as to participate in the question and answer session.
NIEM hosted its second annual NIEM in November event on Tuesday, November 4, 2014. NIEM in November was a half-day event filled with presentations, round tables, and discussions highlighting the community's hard work and success. Hosted at National Defense University and live-streamed on NIEM.gov, the event had attendees and presenters from across the United States and beyond.
Resource Links:
https://www.niem.gov/about-niem/news/niem-november-recap
https://www.niem.gov/about-niem/news/september-virtual-town-hall-recap
https://www.niem.gov/about-niem/news/niem-november-recap
In 2004, the Office of Justice Programs, Bureau of Justice Assistance, US Department of Justice, engaged the IJIS Institute to update the existing GJXDM-conformant AMBER Alert Information Exchange Package Documentation (IEPD), to make it consistent with best practices of GJXDM development, and to update it to version 3.0.2 of the GJXDM.
The IEPD is proposed as a baseline for developing a national standard for AMBER Alert message sets to promote the seamless sharing of AMBER Alert information and between jurisdictions and the technologies they employ.
The IEPD is available in the Justice Standards Clearinghouse at http://it.ojp.gov/default.aspx?area=implementationAssistance&page=1017&….
Base64 is an encoding mechanism used to represent binary data as text characters. Triplets of 8-bit octets are encoded as groups of four characters, each representing 6 bits of the source 24 bits. This is one way of enabling binary data to be included in a text (UTF-8) document, such as an XML document.
To include the PDF file binary data in the XML document, the PDF file would first have to be encoded in Base64 (using an API function that varies dependent on the development/target environment), and then put the resulting Base64 encoded data (which is really text characters at this point) between < BinaryObject.Base64 > and < /BinaryObject.Base64 >.
It is recommended that binary data (in the BinaryObject.Base64 element) be accompanied by a BinaryFormatText element, that contains a description of the type of binary data, so that a processing application understands how to interpret the data. It is further recommended that the standard IANA MIME media type descriptions be used for types covered by those descriptions; for example, PDF data would be designated by <BinaryFormatText>application/pdf</BinaryFormatText>.
The IANA MIME Media Types are defined here: http://www.iana.org/assignments/media-types/.
Extensible Markup Language, or ''XML,'' is an open standard base that allows agencies to exchange data, regardless of computer system or platform. XML defines the structure and meaning of data records through simple but carefully defined syntax rules and provides the common framework to facilitate cross-platform data exchange.
With XML, existing systems can remain in place, and the data is translated as it enters and exits each system without changing the meaning of the data or how it appears in the originating system.
XML is designed to transmit both data and the meaning of the data. It accomplishes this by being a markup language, a mechanism that identifies different structures within a document. Structured information contains both content (such as words, pictures, or video) and an indication of what role content plays, or its meaning. XML identifies different structures by assigning data "tags" to define both the name of a data element and the format of the data within that element. Elements are combined to form objects.
XML Tutorial: http://www.w3schools.com/XML/default.asp
An XML parser is the piece of software that reads XML files and makes the information from those files available to applications and programming languages, usually through a known interface like the DOM. The XML parser is responsible for testing whether a document is well-formed and, if given a DTD or XML schema, it will also check for validity (i.e., it determines if the document follows the rules of the DTD or schema). It is a programming library that improves programmers' access to the contents of an XML document. There are two main categories of XML parsers: Document Object Model (DOM) parsers, and Simple API for XML (SAX) parsers. DOM parsers take the approach of creating an in-memory representation of the XML document, which the developer can then "walk" to find the information desired. SAX parsers take a different approach that does not store the entire document in memory; rather, as elements are encountered in the XML document, an event is generated to inform the programmer's code of the fact. The programmer's code then does whatever is appropriate at that point in the document.
Other tools, like XSLT transform engines and XML-object binding toolkits, are built on top of XML parsers and offer enhanced functionality in processing XML.
All parsers will produce parse errors upon encountering non-well-formed XML. Many parsers will also validate the XML instance against a schema, if one is available. (Often this requires setting an option on the parser before parsing takes place.)
Most development platforms and programming languages have at least one XML parser available. XML parsing capabilities are built-in to the Java and Microsoft .NET platforms. In Java, the programmer can use the default library that ships with the Java 2 Standard Edition (J2SE) environment; alternatively, the programmer can "plug in" any compliant parser, such as the Xerces parser from the Apache Foundation.
The alternative to using a parser is to program the processing of an XML document "by hand" (i.e., by reading the XML text, processing XML tags, etc.) While seemingly an easy task, implementing the full XML specification (in addition to schema validation) is complicated. Absent a very good reason, developers should use an off-the-shelf XML parser.
In the instance when two different sub-schemas are created with the subset generation tool, and data in the XML instances of these schemas is dynamic and manipulated extensively, XMLBeans 1.0.3 should be used for Java-XML Binding. XMLBeans is a great light-weight framework that creates an object model of XML schemas. When a schema is ''compiled,'' the XMLBeans schema compiler generates the source code and classes, as well as schema snippets. By default, the code and classes are stored in packages that are derived using the namespaces provided within the schema, which can be very convenient.
However, there is a major downside. The whole reason for the subset generation tool is to provide a way to create a schema that contains only the types, elements, and attributes that are needed. Which means it is possible, and quite likely, the similar types between schemas will be different. For example, the ArrestType in one schema may contain an ArrestCharge element, where as the ArrestType may not have that element defined in different schema. The typical XSL transformation is not sufficient.
When moving and manipulating data between instances of these two schemas programmatically, driven by rules, JAX-B makes sense (for example, if similar types are defined in the schemas which differ in structure.) The namespace for the classes is the same. At runtime, the Class loader will search the class path for class definitions. When the class loader finds a class definition for the class requested, qualified by its namespace or package name, it loads it into the Java Virtual Machine (JVM) and allows the program to use it. The question is, "Which definition of ArrestType did the loader find?" There are two ways to solve the problem. First, one could generate an XMLBeans model for the entire GJXDM or NIEM, and use that library for deployment at runtime. There are pluses and minuses. The upside: one does not have to worry about having all the methods available at runtime. The object will support all of them. The downside(s): Who wants to see ''all'' of the available methods while developing the code? And, there is a bit of a performance hit as the JVM scans the library for ClassDefs.
The best way to solve the problem is to use the facility within XMLBeans to map target namespaces to Java packages. There is one more issue that is a little harder to work around. XMLBeans generates class files with the same name as the types and elements defined within the schema. So, reading the code can be a little challenging. The best suggestion here is to make your variable names meaningful and descriptive, which is a best practice anyway.
XML documents allow the use of a standard which makes it easier to produce, receive, and archive any kind of information across different hardware, software, and programming languages. Generally, electronic justice data exchange is accomplished via documents, queries, responses, and other messages or transactions. In XML Schema terminology, all of these are considered XML documents.
In the GJXDM and NIEM, XML documents refer to standard business exchange containers (i.e. Rap Sheet, Arrest Warrant, or Incident Report) that are usually persistent. This means that they are archived, maintained, or reused intact by the sender or receiver. XML documents can also be transactional. For example, queries, responses, or messages can be structured as XML documents. A document can be defined as ". . . something which brings together strongly related objects for a well defined business purpose or context . . ." or ". . . that bundle of data that is passed from one agency to another as part of an exchange . . ." [Gerry Coleman, Wisconsin Crime Information Bureau]. So, the term XML document can refer to a message or other form of information, as well as what we traditionally recognize as a document.