In the early 1980's the U.S. National highway Traffic Safety Administration (USDOT) required that all road vehicles must contain a 17 character VIN. The result was a unique "DNA" style number for each vehicle, where each character and its sequence identify a vehicle attribute.

How to read a VIN

1st character - identifies the country in which the vehicle was manufactured

2nd character - identifies the manufacturer

3rd character - identifies vehicle type or manufacturing division

4th to 8th characters - identifies attributes of the vehicle

9th character - verifies the accuracy of the transcription of the vehicle identification

10th character - identifies the model year

11th character - identifies the assembly plant for the vehicle

12th to 17th characters - identifies the numeric sequence of the vehicle production.

A Vehicle Identification Number (VIN) may be assigned by the original equipment manufacturer (OEM) or local agencies. The VIN needs to indicate the issuing authority in the “DrivingJurisdictionAuthorityIDType”. The most common assignment of a VIN by someone other than the original equipment manufacturer (OEM) involves conversion vans and other truck-like vehicles where the VIN is assigned by the final manufacturer.

Example: Winnebago buys Ford 350 vans with a cab and a set of frame rails in the rear, after Winnebago adds an RV body, it assigns a VIN. The VIN reflects the manufacturer and model number given by Winnebago, not Ford. A less common case is a completed vehicle, which already has an assigned VIN that is transformed and then receives a new (replacement) VIN.

The Joint Task Force on Rap Sheet Standardization (JTF) has made an effort to implement a national standard for the exchange of criminal history rap sheet. This is a project sponsored by the FBI in combination with SEARCH and NLETS.

The JTF created an XML specification for Interstate rap sheets that contains the XML-based, criminal history transmission standard conformant to the Global Justice XML Data Model version 3.0.2. Included are a recommended text presentation format, an example XML rap sheet instance, an illustrative implementation using the FBI’s Interstate Identification Index and NLETS network, a style sheet, and schema.

The document's Executive Summary provides a description of the project to create a national rap sheet standard. Rap Sheet Specification 3.00, has defined an element (as an extension to the GJXDM) for Court Case Number. The name of thiselementisrap:CourtRecordID.

Rapsheet Specification: https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/glossa…

“rap:CourtRecordID” is defined as the “element that contains the case number assigned by the court.'' Assuming the court docket number is the same number assigned to a particular case on a court's docket, this element seems appropriate. If you are generating a RAP sheet, conform to the JTF RAP Sheet Specification 3.00 as close as possible, since that is what will be sent to other states via NLETS. Extend it only for additional data elements when it is used exclusively within your state.

Joint Task Force on RAP Sheet Standardization: http://www.doj.state.wi.us/les/XML/jtf.htm

XML Specification for Interstate RAP Sheets: http://it.ojp.gov/jsr/common/viewDetail.jsp?sub_id=215&view=yes&keyword…

Sample XML instance documents based on the FilingSubmissions.xml schema are attached to the answer.

Cardinality rules can be specified by editing the default cardinality specifications (minOccurs=0, maxOccurs= unbounded) in a generated subset schema. However, this introduces a development maintenance burden, since each time the subset is regenerated out of the Subset Schema Generation Tool (SSGT), the same edits must be reapplied.

For this reason, a best practice has evolved in the community to represent cardinality rules in constraint schemas.

A feature has been requested for the SSGT to allow specification of cardinality constraints directly in subset schemas. So far, this feature has not been implemented by GTRI.

GJXDM has technical documentation and it explains the technical foundation behind the Global Justice XML Data Model and Dictionary. Its goal is to provide a solid infrastructure for storing and managing relationships between data entities independent of XML. These entities, and the relationships between them, are defined precisely and flexibly using two kinds of components: types and properties.

Reference link: https://www.niem.gov/technical/Pages/niem.aspx

When describing GJXDM and NIEM, the term "structure" is often used, but what is really meant by that? In this case, structure refers to the representation of data dictionary entities in XML Schema. The key factors to remember are:

• Data model types become XML Schema types.
• Properties become XML elements and attributes.
• Data model type inheritance becomes XML Schema type inheritance.
• Duplication of entities is avoided by using references

The important concept here is the transition of the underlying data model hierarchy to the representation of objects in the XML schemas (GJXDM and NIEM) as elements and attributes.

The Law Enforcement Information Technology Standards Council (LEITSC), funded through the Office of Justice Programs (OJP), fosters the growth of strategic planning and implementation of integrated justice systems by:

· promoting the merits of information technology standards:

· providing advice to the nation's law enforcement community on technical aspects of IT standards;

· sharing practical solutions; and

· representing the voice of law enforcement in the expansion of justice and public safety information technology standards.

The first year of funding provided by the Bureau of Justice Assistance (BJA) established LEITSC and allowed the group to lay a solid foundation for the project. Accomplishments of the group include the organization and staffing of project; the identification of association staff and membership representatives; creation of project charter; the development and implementation of operational plan; outreach by utilizing association IT initiatives and collaboration with external initiatives; the coordination of quarterly council meetings; and, the development of a strategic plan.

The strategy proposed utilizes committees comprised of law enforcement information integration practitioners, industry representatives and justice standards representatives to review and evaluate existing information technology standards, specifically functional and technical XML standards. They will determine if the standards reviewed fit the needs of law enforcement and make recommendations accordingly. In addition, a detailed communications plan will be designed and implemented to leverage each association’s means to communicate the need and availability of information technology standards to the law enforcement community, and to involve the Council in on-going standards development.

Source: http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=displa…

Since the 1980’s, most VINs are unique combinations of 17 alphanumeric characters identifying each specific vehicle as defined by ISO 3779 and ISO 3780. Within the 17-digit number are codes that indicate the vehicle's make and model, manufacturing location, manufacturer value (the ''world manufacture id'' - WMI, controlled by SAE registration), optional equipment, and a manufacturing sequence number, etc. A vehicle identification number is normally assigned by the original equipment manufacturer (OEM), but can be assigned by titling or registration agencies or by secondary manufacturers or finishers.

It is important to note, that VINs are not unique at times. In early uses, many of the ''fly by night'' finishing firms would assign the same VIN for similar products. There are also rule exceptions for older or more exotic vehicles with less than 500 vehicles that result in duplicate VINs. Most law enforcement CAD systems, if they recognize exceptions will prompt the user when the make/model values encoded in the VIN do not match the information

From: Global XML Structure Task Force (GXSTF)

To answer concerns that the Uniform Crime Reporting (UCR) code schema is incorrectly documented, the Global XML Structure Task Force (GXSTF) is publishing Patch-1 for all versions of the GJXDM (3.0.0, 3.0.2, 3.0.3). This corrects the UCR documentation elements for the UCR codes that are incorrectly labeled. It does NOT disturb type or element definitions. The README.txt file explains how to patch each release without having to move to a new version.

Patch-1 can be downloaded as: https://bja.ojp.gov/program/it/national-initiatives/gjxdm

In addition to posting this patch to the GJXDM Listserv, it will be highlighted and downloadable from the GJXDM main index page (it.ojp.gov/jxdm) as well as each release index page. Patch-1 will be added to the archive file for each release (jxdm-*.zip). However, the user must apply Patch-1 to the archive, if desired.

Only GJXDM 3.0.3 will be patched in the Schema Subset Generation Tool (SSGT) (gjxdmtools.gtri.gatech.edu). Want lists that were previously generated by SSGT from the non-patched 3.0.3 release will be regenerated with the updated UCR schema (i.e. patch applied).

The change logs for the current and previous releases will not be updated. The next full release of GJXDM will correct the UCR code schema and post an entry to that effect in its change log.

The UCR schema errors are semantic in nature, and they are contained in xsd:documentation elements only (within ucr.xsd). They do not impact XML validation.

Therefore, as long as you are not using the documentation within the UCR code schema as an authoritative guide to the semantics of the UCR codes, your schemas, instances, and applications should be unaffected, regardless of whether you apply Patch-1 or not.

Data Format for the Interchange of Fingerprint, Facial, & Scar, Mark, & Tattoo (SMT) Information defines the content, format, and units of measurement for the exchange of information that may be used for the fingerprint, facial, or SMT identification of a subject. It consists of a variety of items (some of which are mandatory), including related record data, digitized fingerprint information, and compressed or uncompressed images of fingerprints, mugshots, or SMTs.

NIST namspace http://release.niem.gov/niem/ansi-nist/2.0/namespace

This utility has been developed as part of the SEARCH project to develop a Reference Information Exchange Package (IEP) for incident reporting. As part of that project, the utility provided a mechanism to test the robustness of the IEP, since one requirement of the IEP was the capability of representing a NIBRS incident report. During the development of this utility, a small number of missing IEP elements were discovered and incorporated into the final version of the IEP.

The utility is also a potentially valuable tool that could be incorporated into NIBRS-compliant law enforcement records management systems (RMSes), should those systems wish to emit XML instance reports that are valid according to the IEP structure.

To download the NIBRS Incident Report to Incident Reference IEP Conversion Utility and related documentation, please click on these links:

http://www.search.org/files/zip/nibrs-iep-converter-src.zip#overview.doc or

http://www.search.org/files/doc/overview.doc

Unified Modeling Language Tools

Today, there are a substantial number of tools for enabling model-driven development, both commercial and open-source. Microsoft’s Visio (available through the Microsoft Office suite) has recently been used to support domain modeling by several members of GJXDM Information Exchange Package (IEP) teams.

One of the most popular open source tools for UML design is ArgoUML. This is a full GUI (graphical user interface) desktop application that allows creation of virtually the entire set of UML diagrams, with the ability to save those diagrams in the XMI format, which many modeling tools use as their source for code generation. ArgoUML is hosted at http://argouml.tigris.org/, please go there for all file releases and resources.

There is no single right approach to this issue; the schema designer should ensure conformance to local business and architectural requirements. The following may assist in determining the fit of each approach to requirements.
NIEM 1.0 and GJXDM 3.0.3 contain components that implement many of what could be considered "transactional" or "messaging" attributes. These attributes appear in NIEM 1.0 in the DocumentType type in the universal and common namespaces and the MetadataType type in the structures namespace. In GJXDM 3.0.3, the attributes appear in DocumentType and in the attributes of SuperType. The schema designer should assess the fitness of exchange requirements (represented in the domain model for the exchange) to these NIEM or GJXDM components.
It is important to consider whether the "transactional" or "messaging" requirements are addressed by the standards or technology being used to transport the message between systems. In many cases, such as addressing, the message transport infrastructure will rely on attributes' being represented according to a standard (such as WS-Addressing). Similarly, reliable messaging mechanisms will often assign message identifiers and timestamps (or will rely on their being represented according to a standard in order to function properly.) The schema designer should be aware of these issues when choosing where (and whether) to represent these attributes in an IEPD.
In addition, as a general principle, it is a good idea to satisfy requirements by leveraging standard XML vocabularies rather than inventing new structures. Even if there is no component in NIEM that meets a requirement, there may be other standards that do contain appropriate components.

The Justice Reference Architecture (JRA) consists of two principle sets of information: a reference architecture that defines standard terminology and concepts for understanding a service-oriented approach to information sharing, and a set of documents that evolve JRA concepts into guidelines about how to design and implement information exchanges.
The JRA is a deliverable of the Global Infrastructure/Standards Working Group (GISWG).
The JRA is based on the OASIS Reference Model for Service-Oriented Architecture (SOA-RM). The SOA-RM provides vendor-neutral, standard definitions of concepts involved in information exchange and system integration. (Actually, the SOA-RM is sufficiently general to support exchange between and integration among non-computer entities, but the JRA applies the concepts only to system integration.)
They key innovation of the JRA is to introduce the concept of a service between two systems: one that has a capability (called a "provider system"), and another ("consumer system") that needs to use that capability to achieve some business objective. The capability can be simply providing information, or it can be a complex workflow or business process. The service that sits between these two systems is defined by a formal model that documents clearly and specifically what the service does, as well as what information is needed to interact with the service. In the JRA, the information model of the service is formed from NIEM- and GJXDM-conformant components.
The JRA also includes concepts that support the interaction between consumer systems and services, such as: repositories to store and search service descriptions, infrastructure elements necessary to transmit information between systems, and technical standards for inter-system communication (called "service interaction profiles").
Specific guidelines currently under development include: service interaction profiles for web services, MQ, file transfers, and ebXML; guidelines for modeling/describing services; guidelines for infrastructure capabilities; and guidelines for the identification of services. GISWG is also developing guidelines for the management and governance of a service-oriented architecture.
Finally, the JRA will include a set of "reference services" that represent typical, common services that exist in justice.
There are two key use cases for the JRA.
The first use case involves an actor whose responsibility is to establish an architecture-that is, a set of standards and infrastructure capability requirements-for a justice information sharing initiative. Often (but not always) this actor will be an architect or chief information officer, or equivalent. The actor uses the JRA as a starting point for standardizing the terminology used to describe and understand information sharing in his/her enterprise. The JRA will also provide baseline technical standards for the design and implementation of services, which the actor can modify as necessary to suit local business requirements.
The second use case involves separate jurisdictions using the set of "reference services" to establish interoperability between those jurisdictions.

There are many information sharing and system integration architectures to choose from. Web services (i.e., the use of SOAP over HTTP and standards based on SOAP, such as the WS-I Basic Profile, WS-I Basic Security Profile, WS-Security, WS-Reliable Messaging, WS-Addressing, etc.) is not the only viable approach.
Message Queuing (MQ) approaches offer one alternative. In an MQ approach, the sending system forms a message (in the justice world, this should be a GJXDM-conformant message) and uses a software component to place the message in a queue. Often, this queue is "local" to the sending system-either on the same computer or a "nearby" computer that shares a very reliable network with the sending system. The queue at the sending end identifies the destination of the message and sends it to a second queue at the destination, where the message remains until it is retrieved by the destination system. Often, the message is not deleted from the queue at the sending end until it receives confirmation of receipt at the destination queue, thus implementing "reliable delivery" of the message.
MQ approaches require software and hardware infrastructure to support the message queues. The software infrastructure generally makes available application programming interfaces (APIs) that allow developers to place messages in and retrieve messages from queues. These APIs can be proprietary to the manufacturer of the software infrastructure, or they can follow API standards developed by industry consortia (such as the Java Message Service (JMS) APIs.)
File Transfer is a second alternative approach. A file transfer involves a sending system writing a file (in the justice world, this should be a GJXDM-conformant information exchange package serialized to a file) to a local or remote file system. Writing to a remote file system generally involves a file transfer protocol such as FTP or S/FTP (secure FTP). When the file arrives at the destination, the destination system reads and processes it.
Writing and reading transferred files can be accomplished by developing software or using import/export capabilities of a database platform. When developing software for this purpose, developers often use tools such as the .NET XML serialization libraries or Java libraries such as JAX-B or XML Beans.

Currently there are two SSGTs supported in the community, these are the GJXDM SSGT and the NIEM SSGT.

If the site goes down, bugs should be reported directly to the IJIS Helpdesk (https://www.niem.gov/Pages/contact.aspx).

Email: [email protected]

NIEM SSGT issues must be emailed or called into the IJIS Helpdesk (https://www.niem.gov/Pages/contact.aspx).

Telephone: 1-877-333-5111 or 703-726-1919
Email: [email protected]

Any suggestions for improving the NIEM SSGT must be put through the proper NIEM Governance committees.

The Justice Information Exchange Model (JIEM) Methodology is a structured, formally documented approach for defining and capturing information exchange requirements. The overarching goal of the JIEM Methodology is to build consensus about information exchanges among business partners. The JIEM Methodology provides the steps necessary to capture both the content of the exchange (the information being exchanged) and the context of the exchange (who is involved in the exchange, the factors determining when and where the exchange should occur, and what event will happen next).

The JIEM Methodology is premised on the notion that all information exchanges can be described by identifying five dimensions of requirements. These five dimensions are:

1. Process: A series of logically related events and exchanges that achieve some business purpose or milestone.
2. Event: Decisions or actions that trigger information exchange.
3. Agency: Business partners who exchange information.
4. Condition: Decision points or "gates" that define when information exchange happens.
5. Information: The content of the information exchanged-the "payload."

JIEM documents additional important requirements, including the priority and frequency/urgency of each exchange. In the future, JIEM will capture critical policy requirements such as exchange privacy and security details.

The JIEM Methodology also supports the concept of reference models. A reference model is a set of information exchanges regarding business functions that are common to most jurisdictions based on the models developed by JIEM users. Reference models allow JIEM users to leverage key exchanges of relevance to their site, reducing the time it takes to develop requirements while producing results that are more consistent with those of other jurisdictions. The existing JIEM reference model is based on the Adult Felony judicial process. SEARCH is adding new reference models to define exchanges commonly found in other environments.

The JIEM Modeling Tool applies the JIEM Methodology and allows users to capture requirements using the five JIEM dimensions. The Tool also supports the definition of "as-is" and "to-be" models, aligning with basic enterprise architecture techniques and supporting the ability to identify information sharing capability gaps. This information can in turn feed into a jurisdiction's strategic planning efforts in order to determine specific projects, initiatives and investments necessary to achieve business goals outlined in a strategic plan.

Between 1998 and 2007, the JIEM Tool was a Web application hosted at SEARCH. SEARCH released JIEM 4.0, based on the Eclipse tools platform, in September 2007. This new platform improves usability and opportunity to integrate JIEM with other off-the-shelf modeling tools (such as UML and XML tools) that industry is actively developing on Eclipse.

JIEM plays a key role in the National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) Lifecycle. The second step in the NIEM IEPD Lifecycle is "Analyze Requirements." JIEM provides an effective way to gather the requirements necessary to construct an IEPD. The JIEM Tool is also integrated with NIEM through the use of component libraries. Component libraries allow JIEM users to use NIEM concepts when defining exchange content.

Access to JIEM, including training, is available at no cost from SEARCH through funding from the Bureau of Justice Assistance, U.S. Department of Justice. Use of JIEM is reserved for those who have completed JIEM training and certification. For more information about JIEM training opportunities, please email [email protected].

Further information about JIEM can be found on the official JIEM Web site: http://www.search.org/programs/info/jiem.asp

The Global Federated Identity and Privilege Management (GFIPM) framework provides the justice community and partner organizations with a standards-based approach for implementing federated identity. The concept of globally understood metadata across federation systems is essential to GFIPM interoperability. Just as a common Extensible Markup Language (XML) data model was the key to data interoperability, a standard set of XML elements and attributes about a federation user's identities, privileges, and authentication can be universally communicated.

Please refer to the pdf attached for the full article.

Documents
https://bja.ojp.gov/media/document/30121

In the modern of technology right now, 9-digits of SSN had placed a very important role or key in the web and window applications. In the database (SQL, Oracle, or etc…), SSN also is an important key to give access for log in the application or export the data into a letter, form, report(spreadsheet), and etc… In NIEM/GJXDM, we use 9-digit Social Security Number (SSN) as a simple concept that should uniquely apply to a legal person that lives in the U.S. In order to export such amount of large data, XML is a best way to handle this kind of job (especially spreadsheet). The XML code below is an example and it will be a correct way to specify the Name an SSN for a person in its simplest terms:

<Person>
<PersonFullName>John Doe</PersonFullName>
<PersonAssignedDetails>
<PersonSSNID>
<ID>123456789</ID>
</PersonSSNID>
</PersonAssignedDetails>
</Person>

The XML tags are required to have four levels to associate the SSN with a person:
Person/PersonAssignedDetails/PersonSSNID/ID
The following XML instance specification is the result of the following type structures and properties in the Global JXDM:
PROPERTY of TYPE (derived from or extends TYPE)

Person PersonType (SuperType)
PersonAssignedIDDetails PersonAssignedIDDetailsType (SuperType)
PersonSSNID IDType (SuperType)
...
PersonStateID IDType (SuperType)
...

IDObject IDType base xsd:string (SuperType)
ID TextType
IDTypeText TextType
IDTypeDescriptionText TextType
IDTypeCodeText TextType
IDTypeCodeSourceText TextType
IDTypeCodeVersionText TextType
IDStatus StatusType (SuperType)
IDEffectiveDate j-xsd:date
IDExpirationDate j-xsd:date
IDIssuingAuthorityText TextType
IDJurisdictionText TextType
IDJurisdictionCode j-ncic:RESType
IDSourceText TextType
PersonSSNID is of type IDType and IDType contains a number of properties to qualify the SSN, it is not necessary to use them unless your requirements demand it. In fact, many of these properties may not be appropriate for the SSN. In addition to having the use of the IDType properties, the user also has access to a number of attributes under the SuperType (see some examples in the chart below):

SuperObject SuperType
@languageText xsd:string
@probabilityNumeric xsd:decimal
@reliabilityNumeric xsd:decimal
@distributionText xsd:string
@sensitivityText xsd:string
@sourceText xsd:string
@reportingPersonText xsd:string
@reportingPersonRoleText xsd:string
@reportingOrganizationText xsd:string
@reportedDate xsd:date
@lastVerifiedDate xsd:date
@lastUpdatedDate xsd:date
@effectiveDate xsd:date
@expirationDate xsd:date
@sourceIDText xsd:string
@criminalInformationIndicator xsd:boolean
@intelligenceInformationIndicator xsd:boolean
@comment xsd:string

Reference links for XML SuperType:

http://www.tdan.com/view-articles/7185

Article source reference: https://bja.ojp.gov/program/it/national-initiatives/gjxdm

A Partner System refers to each system that is involved in the mutual sharing of law enforcement information, with each party retaining ownership and possession of its information, and therefore becoming partners in law enforcement information sharing.

Data Source refers to a system that is operated by an organization that publishes information to a data repository.

Data Consumer refers to the data repository that receives and ingests the published information.

When a data repository republishes information that it does not own, it is acting as a Data Submitter.

A Data Owner is the original owner of the information that is submitted to the repository.

All there terms describe roles that a system can have.

Xsd.exe (or XML Schema Definition Tool) is a code generation tool that is part of the Windows SDK and is packaged with Visual Studio. It allows various forms of code generation relating to XML and XML schema for both C# and Visual Studio.NET. It can create an XML schema document from XML; sample XML from an XML schema, XML schema from a .NET assembly, or C# and Visual Basic from XML schema. It is this last code generation capability that is valuable to us as we can generate C# and Visual Basic XML serialization code from the NIEM IEPD schemas.

Source: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in C# with .NET 3.5"; see article ID# 547

Svcutil.exe is a newer code generation utility that Microsoft has released as part of WCF in .NET 3.0. Unfortunately, SvcUtil.exe does not support the more advanced XML schema features that are required by NIEM such as abstract types and substitution groups.

Source: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in C# with .NET 3.5"; see article ID# 547

Sgen.exe is a tool that is provided with Visual Studio and can be used to optimize XML serialization. When used directly, XmlSerializer will create a serialization assembly at run-time for serializing and deserializing the generated code. It relies heavily on reflection and has the potential to perform very poorly given the size of some IEPDs. Sgen.exe can be used to create a serialization DLL from an existing DLL that contains the generated classes so that they are not created at runtime. To use Sgen.exe, call it from the command line with the name of the DLL that contains the generated XML serialization classes as an input argument.

Example: > sgen.exe MyNiemIepdXmlPersistence.dll

This will generate an XmlSerializers DLL called MyNiemIepdXmlPersistence.XmlSerializers.dll with namespace Microsoft.Xml.Serialization.GeneratedAssembly with a number of type serializers that should be used instead of the default System.Xml.Serialization.XmlSerializer class.

Source: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in C# with .NET 3.5"; see article ID# 547

Yes, it is OK to exclude any NIEM content in a subset schema (including the metadata attributes in the structure namespace) as long as something else in the subset or the extensions does not depend on it. It appears that the NIEM Schema Subset Generation tool includes these attributes in the subset, so one will have to manually edit the structures.xsd file to remove them as attributes of s:ComplexObjectType. Also, when associations or roles are used or needed, the s:id and s:ref must be part of the schema.

Before:
<xsd:complexType name="ComplexObjectType" abstract="true">
<xsd:annotation>
<xsd:documentation>The ComplexObjectType type provides a base class
for object definition, association definitions, and external adapter
type definitions. An instance of one of these types may have an ID.
It may have metadata as it establishes the existence of an object
(maybe a conceptual object). It may also have link metadata, as an
element of one of these types establishes a relationship between its
value and its context.</xsd:documentation>
</xsd:annotation>
<xsd:attribute ref="s:id"/>
<xsd:attribute ref="s:metadata"/>
<xsd:attribute ref="s:linkMetadata"/>
</xsd:complexType>

After:
<xsd:complexType name="ComplexObjectType" abstract="true">
<xsd:annotation>
<xsd:documentation>The ComplexObjectType type provides a base class
for object definition, association definitions, and external adapter
type definitions. An instance of one of these types may have an ID.</xsd:documentation>
</xsd:annotation>
<xsd:attribute ref="s:id"/>
</xsd:complexType>

XML Substitution groups are very heavily used within NIEM. Within the XSD.exe, there is an issue where substitution groups will not always serialize when members in a namespace are different from the one the substitution group head has declared. This issue will manifest itself during testing with unexpected exceptions occurring because of null values in the rendered classes.

Note that the circumstances where a substitution group member will or will not serialize is somewhat dependent on the overall complexity of the IEPD, however, they can be broken down into the following scenarios:

1. A substitution group with a head element & members in different namespaces
2. Substitution group without head and extension types in different namespace.

For more details on these two scenarios, please see the full article at

Source: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in C# with .NET 3.5"; see article ID# 547

While WSDL is valuable in general as a way to describe the behavioral and information models of services, this brief (see source below) focuses on the value of WSDL to software developers, who can use WSDL definitions to produce software code for the intersystem sharing of information. This Technical Brief will also demonstrate the ability of several available tools to create programming code based on NIEM schemas. In doing so, this brief also demonstrates that the web services tool space — on both the Java and Microsoft .NET platforms — has matured to the point that there are no longer significant barriers to the use of NIEM with web services and WSDL.

In order to effectively establish a web services-based information sharing environment, it is critical that systems have the ability to access and process XML data. A common and efficient way to do this is to leverage the WSDL definition of a service in order to automatically generate programming code (Java, .NET, etc.) that maps to XML constructs that define a service.

For further reading, please see source below.

Source - Web Services and NIEM:Realizing the Value of Available Tools

A reference architecture is a set of documents that the technologists—developers, architects, project managers—in a jurisdiction can use to accelerate the planning process for information sharing, while simultaneously aligning the final outcomes with proven best practices. A reference architecture is a tool practitioners can use to make it easier to develop a well-conceived, formal approach to designing information sharing solutions/systems. A key benefit of reference architecture is that it helps promote consistent thinking and approaches among the people who use it, even if they have not shared information with each other.

Source: https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/GRAFAQ…

The Services Task Team (STT), was implemented by the U.S. DOJ, Bureau of Justice Assistance and Global Infrastructure Standards Working Group (GISWG) in order to assist in GRA execution.

The goal of the STT is to implement the GRA framework, methodologies, and guidelines for the development of Global Justice Reference Service Specifications.

An entity (person or organization) that offers the use of capabilities by means of a service.

Donna Roy, NIEM Executive Director, draws an analogy between NIEM and a bank card transaction, both of which use the power of a common language to enable the cross-jurisdictional exchange of information, while protecting the information’s integrity. For more information on the "Magic of NIEM," click here.

The information below provides Grant Resources for Justice and Public Safety Community.

Grants.Gov: http://grants.gov/
Office of the Juvenile Justice and Deliquency Prevention (OJJDP): http://www.ojjdp.gov/funding/funding.html
FEMA Grants: http://www.fema.gov/grants
Excellent one-stop shop for Police Grants. It includes a free Basic Search tool and grant writing tips for Federal, state, foundation and corporate grants: http://www.policegrantshelp.com/grants/
Funding Sources newsletter from JustNet (good links to funding agencies): https://www.justnet.org/InteractiveTechBeat/fall_2011/GrantsHelpAgencie…
The Walmart and Target Corporations also fund a number of law enforcement and public safety projects: http://walmartstores.com/CommunityGiving/203.aspx; and http://sites.target.com/site/en/company/page.jsp?contentId=WCMP04-031891
MetLife Foundation Grants - MetLife supports organizations that supports drug market disruption gang prevention, youth sand senior citizen safety. Law Enforcement Technology Grants | eHow.com http://www.ehow.com/about_5506905_law-enforcement-technology-grants.htm…

The NIEM Naming and Design Rules (NDR) refers to ISO 11179 as guidance for good data definitions. Typing information within a data definition (such as "7 digits" and blocking ranges that refer to various kinds of accounts) is considered TERRIBLE practice by ISO 11179. All NIEM data XML elements are typed elements and carry only typing needed for representation (NIEM can use constraints and/or patterns when required). The definition for an ID should state the meaning of the ID and/or its use; not define it through its specific typing and business rules. NIEM has other fields for data examples and detailed description of usage if needed.

The newly-developed, interactive Global Information Sharing Toolkit (GIST) Web portal, was designed to help you locate the best Global tools and solutions for your business needs.Whether you are tackling a justice information sharing business problem, targeting a general area of interest, or are looking for a specific Global publication, the Global Wizard has the solution. This tool is designed to give you, the user, options for locating the best solutions from developing a privacy policy to establishing a fusion center to seeking guidance on First Amendment rights or implementing Global Reference Architecture standards, the GIST will make that much easier.

Also see attached flier.

Documents
https://bja.ojp.gov/media/document/30126

The GFIPM System-to-System Profile and GFIPM Implementation Guide provides the details in the implementation techniques to consider in GFIPM.

An organization wishing to participate in the federation MUST adhere to the following sequence of membership phases and associated processes:

1. Request-to-Join Process
2. Application Process
3. Onboarding Process
4. Ongoing Membership

For further details on the participation process, please refer to GFIPM Operational Policies and Procedures

The training is video-based and hosted on YouTube for easy access from any YouTube-enabled device. The videos are high-definition, ensuring readable on-screen XML for examples and exercises. There's over six hours of video instruction, broken and organized into manageable sections of 15 minutes or less.

The training contain serveral topics:

NIEM Advanced Technical Concepts
NIEM XML Artifacts
NIEM IEPDs
And more!
For more information regarding Video-Based Training see here - http://niemtraining.org/video.php.

The PersonSSNIdentification element is of type IdentificationType, which in turn has an element IdentificationID of type string. Clearly IdentificationID needs to accept arbitrary strings. However, in the context of PersonSSNIdentification, the IdentificationID needs to be nine characters, the first three digits of which cannot be 000 or 666 (plus a bunch of other rules enforceable using regex). Here is a simple business rules for SSN to be enforced by the XML schema that you can define a PersonSSNIdentificationID in your own namespace and use xsd:pattern:

<xsd:simpleType name="PersonSSNIdentificationID">
<xsd:restriction base="xsd:token">
<xsd:pattern value="[0-9]{3}-[0-9]{2}-[0-9]{4}"/>
[additional pattern facets to specify remaining business rules]
</xsd:restriction>
</xsd:simpleType>

Or, you can use the substitution method as below:

<nc:Person>
<nc:PersonSSNIdentification>
<nc:IdentificationID>123-45-6789</nc:IdentificationID>
</nc:PersonSSNIdentification>
</nc:Person>

<nc:Person>
<nc:PersonSSNIdentification>
<your:SSNIdentificationID>123-45-6789</your:SSNIdentificationID>
</your:PersonSSNIdentification>
</nc:Person>

It highly recommend to use the simple method before going into the substitution method. In case of using the substitution method, you have to ensure that the IEPD documentation is clear that your:SSNIdentificationID is to be used for SSN (as a substitution for nc:IdentificationID), and nc:IdentificationID is not to be used for SSN. If you need to enforce that, the receiver will have to use a means other than XML schema validation, as is the case with many business rules that cannot be represented using XML schema validation as is or constrained by the NIEM NDR.

Using a "Constraint Schema" one simply takes a copy of the native NIEM schema subset and modifies the base type as required.  The follow example from step 1 to 4 will show how you can max out the length of a person name.

Example:

Use Case: Add Max Length to nc:PersonGivenName

Step 1:

Copy "subset" directory to a new directory called something like "constraint"

Step 2:

Modify all extension and document schemas to point at "constraint" directory instead of "subset" directory.

Step 3:

Edit ./constraint/niem/niem-core/2.x/niem-core.xsd to add your constraints

Use <xsd:pattern/> with a regex expression instead of <xsd:maxLength/> for any more complex validation.

If a lot of constraints are being added, you may want to add the constrained data types to a new schema file and simply import the file so as to minimize the changes directly to the niem-core.xsd file.

Step 4 (DO NOT SKIP THIS STEP):

Test and document changes. . . .ANY TIME you update the subset (yes this happens A LOT), you will need to reapply the constraints, so it is CRITICAL to document what constraints you added.

Below are the NIEM valid codes:

<xsd:simpleType name="SKNCodeSimpleType">

<xsd:annotation>

<xsd:documentation>A data type for Skin Color.</xsd:documentation>

<xsd:appinfo>

<i:Base i:namespace="http://niem.gov/niem/structures/2.0&quot; i:name="Object"/>

</xsd:appinfo>

</xsd:annotation>

<xsd:restriction base="xsd:token">

<xsd:enumeration value="ALB">

<xsd:annotation>

<xsd:documentation>ALBINO</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="BLK">

<xsd:annotation>

<xsd:documentation>BLACK</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DBR">

<xsd:annotation>

<xsd:documentation>DARK BROWN</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DRK">

<xsd:annotation>

<xsd:documentation>DARK</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="FAR">

<xsd:annotation>

<xsd:documentation>FAIR</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="LBR">

<xsd:annotation>

<xsd:documentation>LIGHT BROWN</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="LGT">

<xsd:annotation>

<xsd:documentation>LIGHT</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="MBR">

<xsd:annotation>

<xsd:documentation>MEDIUM BROWN</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="MED">

<xsd:annotation>

<xsd:documentation>MEDIUM</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="OLV">

<xsd:annotation>

<xsd:documentation>OLIVE</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="RUD">

<xsd:annotation>

<xsd:documentation>RUDDY</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="SAL">

<xsd:annotation>

<xsd:documentation>SALLOW</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="YEL">

<xsd:annotation>

<xsd:documentation>YELLOW</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

You can't add codes to an existing code table. (The reason is that code tables are done via restriction instead of extension. Once you've restricted something, you can only restrict it further. You can't extend the restriction.)

The solution here is to literally copy the code table XML into an extension schema and add the code to this local namespace.