Frequently Asked Questions (FAQ)

August 24, 2005

These are common questions and answers about the Global Justice XML Data Model (Global JXDM) obtained from a variety of sources including seminars, conferences, e-mail, telephone calls, the Global JXDM Listserv, etc. Answers are prepared, reviewed, and approved by members of the Global XML Structure Task Force (GXSTF).

These questions and answers are generally updated with each new release. They contain basic information about the Global JXDM, as well as a current status. Past and future versions of the data model are discussed along with associated software tools, capabilities, support, and training.

The name of the project, the Global Justice XML Data Model, is referred to as the Global JXDM. The associated Global Justice XML Data Dictionary is referred to as the Global JXDD. We use uppercase "XML Schema" when referring to the World Wide Web Consortium (W3C) XML Schema specification. Otherwise, we use lowercase "XML schema." In some cases, the original question has been edited for clarity.

Questions and Answers

1. General

1.1. What is the Global Justice XML Data Model (Global JXDM)?

The Global Justice XML Data Model (Global JXDM) is an object-oriented data model for organizing the content of a data dictionary, the Global JXDD, in a database. From this database an XML schema specification can be generated that consistently represents the semantics and structure of common data elements and types required to exchange information within the justice and public safety communities.

1.2. Why is it called the "Global JXDM?"

The first version (1.0), called the Reconciliation Data Dictionary (RDD), was a set of tag names for a set of justice-related exchanges. Georgia Tech Research Institute (GTRI) turned the RDD into a simple XML schema, which was called the Justice XML Data Dictionary (JXDD), version 2.0.

GTRI began working with the Global XML Structure Task Force (GXSTF) to create a more comprehensive product that included a data model, a data dictionary, and an XML schema generated from these (version 3.0). The total package became known as the Justice XML Data Model (JXDM). Later, "Global" was added to the name to identify the group responsible for driving the JXDM development, the Global Justice Information Sharing Initiative's (Global) Advisory Committee (GAC). The project and the package are now known as the Global Justice XML Data Model (Global JXDM).

1.3. Who authored the Global JXDM?

In August 2002, the Global Justice Information Sharing Initiative (Global) Infrastructure and Standards Working Group (GISWG) formed the Global XML Structure Task Force (GXSTF) to identify data requirements, explore XML concepts, and apply XML best practices to design and implement the Global JXDM. The GXSTF is a working group composed of government and industry domain experts (from law enforcement, courts, corrections, etc.), technical managers, and engineers.

The U.S. Department of Justice Office of Justice Programs sponsors the
Global Justice Information Sharing Initiative (Global), which is executed by the
Global Advisory Committee which oversees the
Global Infrastructure/Standards Working Group (GISWG), which has a subcommittee called the
Global XML Structure Task Force (GXSTF), which works with the
Georgia Tech Research Institute (GTRI) to design, implement, and maintain the Global JXDM and related technology.

1.4. What is the purpose?

The purpose of the Global JXDM is to provide a consistent, extensible, maintainable XML schema reference specification for data elements and types that represent the data requirements of the general justice and public safety communities. A secondary goal is to provide a baseline model for the data dictionary that can be represented in advanced technologies independently of XML Schema.

1.5. What was the development process?

In 2003, four prereleases of the Global JXDM were published for public review and comment (prerelease versions 3.0.0.0, 3.0.0.1, 3.0.0.2, 3.0.0.3). All comments and responses to those comments are publicly available. Each subsequent prerelease incorporated a number of public suggestions and requests for modification. The GXSTF reviewed and evaluated each comment and approved/disapproved appropriate changes to the Global JXDM. Change logs, published with each prerelease, are linked to those public comments that resulted in changes to the model. In October 2003, the GXSTF solicited and evaluated feedback directly through interviews with a number of technical experts and practitioners in both industry and government (about 15 people). Their constructive feedback resulted in several significant changes to the structural aspects of the Global JXDM. The final prerelease incorporated those changes. The intent was to stabilize the structure of the Global JXDM so that modifications after the initial release would be to the content only.

In January 2004, the initial operational release, Global JXDM v3.0, was published. Subsequent operational releases will change in content, but structural changes will be avoided if possible. The process for change that was used during the prerelease period will continue for operational releases.

1.6. What basic principles and design criteria were used to build the Global JXDM?

Design and synthesize common, reusable, extensible data components that facilitate standard information exchange in Extensible Markup Language (XML).
Requirements-based: Build content from existing data models, dictionaries, and specifications.
Object-oriented: Maximize efficiency through extension and consistent reuse of properties and types.
Generalize the Global JXDM for the justice community at-large. Do NOT target specific applications or systems.
Provide referenceable schema components primarily for schema developers.
Facilitate the evolution of the Global JXDM and its schema by providing change management and extension.
Extendable: Enable local additions of data components, but preserve the semantic relationships when they exist, and minimize the impact on prior schema and code investments.
Implement and represent domain relationships so they are globally understood.
Preserve global semantics.
Build to evolve with emerging technologies (e.g. OWL, Web Services, etc.).
In view of time constraints, national priorities, requirements conflicts, and technical limitations, apply rational compromises to these criteria to achieve solutions.

2. Releases

2.1. How often are new Global JXDM operational releases published?

Our intent is to publish new Global JXDM releases only as needed. To stay abreast of the latest information regarding the timing of a new release, refer to the OJP Information Technology Initiatives Web site or sign up for the Global JXDM Listserv.

The releases (distribution schemas and documentation) can be downloaded or referenced using the URL that is the namespace of the version you need. Each version has a different target namespace distinguished by its three part version number. The namespace for the most current release version 3.0.3 is www.it.ojp.gov/jxdm/3.0.3. Releases will always remain available and are all organized under the directory www.it.ojp.gov/jxdm.

Releases within a series are forward compatible. This means that instances written to validate with version 3.0.0 schemas will also validate with versions 3.0.2 and 3.0.3 schemas. Please note that, backward compatibility is not supported (i.e. instances written for 3.0.3 schemas may or may not validate with versions 3.0.0 and 3.0.2 schemas). A new series such as 3.1.x or 3.2.x will also not be forward compatible with 3.0.x. See What is the version numbering scheme for releases? for a more detailed explanation of the version numbering scheme and compatibility.

2.2. What are the Global JXDM prereleases (2003)?

Global JXDM prereleases have four integers in their version numbering schemes, and include 3.0.0.0, 3.0.0.1, 3.0.0.2, and 3.0.0.3. All were released in 2003. For transitional reasons, prereleases 3.0.0.0, 3.0.0.1, and 3.0.0.3 will remain available for an undetermined period of time. Global JXDM prereleases are no longer updated or supported.

2.3. Are there previews of operational releases?

Early on, we anticipated that there would be requests to incorporate new components for common requirements or from other standards. In most cases, these were either unknown at the time the Global JXDM was built, or we have not yet had the time to study them. We intend to provide information regarding such efforts to add new content without frequently publishing new releases.

To provide a reasonable means of transition, we have established the capability for users to preview the next release while it is still in development. Once an official release has been published, it will be frozen and permanently available under www.it.ojp.gov/jxdm. Some time after this, the latest developmental version of the next release will be available to preview with the Schema Subset Generator Tool (SSGT). Refer to What is the Global JXDM Schema Subset Generation Tool? for more information. For example, after version 3.X has been released, version 3.X.1alpha1 will eventually become available in the SSGT. Note that developmental releases will not be available as distributions under www.it.ojp.gov/jxdm, and there will be no announcements of preview availability. Also please note that before its final operational release, each preview version is a working prototype, subject to change without notice. It is essentially a snapshot of the current version under development of the Global JXDM in the database. Experimental use of and feedback on such preview schemas is encouraged. However, operational employment is at the user's own risk.

Global JXDM releases evolve through several stages enroute to becoming operational releases. They are:

Alpha - Feature list is not complete; changes may still be applied.
Beta - Feature list complete; changes are frozen; minor errors and omissions are expected and will be fixed; reverts to "alpha" if major fixes are required.
Release candidate (rc) - Neither errors nor omissions are expected; undergoing final review; documentation being proofed; reverts to "beta" if minor or "alpha" if major fixes are required.
Operational release - Finalized and ready for public use.

Note that a numbered version of the Global JXDM can be in one and only one of these stages at any given time.

2.4. How is the Global JXDM maintained and updated?

The Global JXDM Bugzilla-based Feedback Web site will continue to be the primary mechanism for identifying urgent bug fixes and requests for additions, deletions, and modifications. The GXSTF will continue to authorize all fixes and changes. Thus, all bug reports (feedback) will be reviewed and approved/disapproved by the GXSTF. All approved additions, deletions, and modifications will be applied to the next release whenever possible. A cumulative change log will be published with each release to maintain an audit trail. Changes will be linked to appropriate bug reports in the feedback history.

Peer support can be obtained via the Global JXDM Listserv, or by contacting agencies listed in the Organizations Utilizing the Global JXDM. The Global JXDM Listserv exists to support community-wide announcements, comments, requests, questions, discussions, and exchanges that are relevant to the Global JXDM but not directly relevant to the Bugzilla-based Feedback Web site.

2.5. What is the version numbering scheme for releases?

Global JXDM versions are numbered by three integers X, Y, and Z, delimited by periods:

	Syntax:  X.Y.Z

Each integer represents a particular class of change:

	X = Major revisions to the model or representations of the
	    model as rendered in a schema (as XML or other markup)
	Y = Minor changes that do not maintain forward compatibility
	Z = Minor changes that maintain forward compatibility

A version number should NOT be confused with decimal numbers. X, Y, and Z are integers, not digits, and may become greater than 9. For example, 4.89.113 is a legitimate release number (though not likely to ever be used). Global JXDM version 3.0 is the first operational release. Version 3.0 instances will be forward compatible with and validate using the version 3.0.2 schema or appropriate 3.0.2 schema subsets. Refer to Please explain compatibility between versions, for more information.

Prereleases used four numbers to designate versions. There were only four prereleases: 3.0.0.0, 3.0.0.1, 3.0.0.2, and 3.0.0.3. Except for 3.0.0.2, prereleases are still available, but are no longer maintained or supported.

Operational releases of the Global JXDM (from 3.0 forward) will always be available on the OJP IT Initiatives Web site under www.it.ojp.gov/jxdm. This ensures that legacy schemas and instances written to a non-current release will always have the original reference to validate with.

There is no specified life cycle for releases. The Global JXDM Bugzilla-based Feedback Web site provides a mechanism for making suggestions, submitting requests for new or changes to current components, and identifying errors or bugs in the design. When a reasonable number of changes have been approved by the GXSTF, a decision will be made to release a new version. This will involve an intermediate decision to determine if this should be a forward compatible series update or the start of a new series.

2.7. How long may an agency continue to use a Global JXDM prerelease? How long does the OJP plan to leave the prerelease distributions available on-line?

While OJP has no immediate plans to remove prereleases from the OJP IT Initiatives Web site, they will not remain indefinitely. Furthermore, prereleases are not maintained or supported.

Here is part of the disclaimer at the bottom of the Global JXDM introduction page:

Earlier prereleases (all 3.0.0.n versions) are no longer updated, but will remain available for an unspecified period of time. Prereleases were essentially alpha versions of the Global JXDM. Implementers that use prerelease specifications do so at their own risk.

Global JXDM prereleases were NEVER meant for production systems. They are equivalent to alpha releases of software; they received minimal review and testing. They were published ONLY to provide an opportunity for the community to review, test, comment on, make suggestons for adjustments, and submit corrections.

2.8. Where is release version 3.0.1?

Global JXDM release version 3.0.1 contained flaws and was removed from service within a few days after its release.

2.9. Please explain compatibility between versions.

The following sequence describes compatibility within the Global JXDM 3.0 release series:

	3.0(.0) instances validate with 3.0.2, 3.0.3, ..., 3.0.n schemas
	3.0.2   instances validate with 3.0.3, 3.0.4, ..., 3.0.n schemas
	3.0.3   instances validate with 3.0.4, 3.0.5, ..., 3.0.n schemas
	...
	(Note: 3.0.1 was removed from service.)

We say that within the 3.0 series, forward compatibility is maintained. However, when 3.1.0 (a new series) is released, 3.0.n instances are NOT guaranteed to validate against 3.1.m schemas. However, 3.1.0 instances will validate with 3.1.1, 3.1.2, ..., 3.1.n schemas, etc. (if/when they are released). In other words, forward compatibility within the 3.1 series will be maintained.

Caveats:

If you want a 3.0.0 instance to validate against the 3.0.2 Global JXDM schema, then you must change the namespace reference in the instance to 3.0.2 (and in your schema, as well if you are using one between the instance and the Global JXDM schema).
Depending on which Global JXDM components you are using, you may find that a 3.0.0 instance validates against the 3.1.0 Global JXDM schema (when available). DO NOT assume that every 3.0.0 instance will validate. NO guarantees of validation will exist between 3.0 and 3.1.

2.10. What happened to the fully documented (full-doc) versions of the Global JXDM schemas?

All downloads are now fully documented (even though they are not labeled as such). If you need smaller undocumented schemas, you can create them with the Schema Subset Generation Tool (SSGT).

It's relatively easy to write a Unix script (e.g. with grep), a DOS batch file (e.g. with FINDSTR), or an XML Style Sheet to filter out the XML annotations. If you need such a tool we have provided a simple set of scripts here.

2.11. How are enumeration (code table) schema versions numbered?

Each enumeration schema began as version 1.0(.0) in Global JXDM release version 3.0. If additions are made to an enumerated list of values, the release will reflect a forward compatible change as an increment to the third integer of the version number. Therefore, in Global JXDM release version 3.0.2, any enumerated list with additional values will become 1.0.1. Since Global JXDM 3.0.2 is forward compatible with 3.0.0, no value deletions are made to any enumeration schemas. However, some values may be deprecated to warn users that they will be deleted in the next release that is not forward compatible. Therefore, any enumeration schema values that were marked deprecated in Global JXDM release version 3.0.2 will be deleted and the resulting new enumeration schema will be numbered 1.1.0 in Global JXDM release version 3.1.0.

NOTE: A change to the definition of an enumerated value will not cause a new version of the schema it is within.

2.12. Why doesn't the change log show more than one bug number and link? (Some change numbers address multiple bug reports.)

The change log is a very simple list with a column for a single hyperlinked bug number. If there are multiple bugs that pertain to a given change number, then related bug reports should be linked together in a sequential chain. If you start from the bug link in the change log, you should be able to follow from that bug report to all other related bug reports.

3. Technical

3.1. What is a Global JXDM component?

A Global JXDM component is any type or property defined in the model. Global JXDM types translate to XML Schema types and properties translate to XML schema elements or attributes.

3.2. What is the difference between the Global JXDM and the Global JXDD?

The Global JXDM is an object-oriented data model that specifies a representation structure for the Global JXDD. The Global JXDM (structure) and the Global JXDD (semantics) are integrated and implemented as a relational database. This database is used to generate a consistent representation in XML Schema.

3.3. How is the Global JXDM structured?

The Global JXDM consists primarily of object classes and properties:

Object classes are converted into XML Schema types. They represent a specific syntax and structure for a set of values.
Properties are converted into XML Schema attributes and elements. They represent characteristics, or values of things.

The Global JXDM is a reference model that is based on a class hierarchy of many specific objects (xsd:type) derived from one very general object (SuperType). Each object contains any number of properties (xsd:element or xsd:attribute). These properties may be simple or complex elements (containing sub-elements). The highest level object classes (under the SuperType) are PersonType, OrganizationType, PropertyType (i.e., things), LocationType, ContactInformationType (i.e., electronic means of contact), ActivityType, DocumentType, and other smaller supporting types. There is also a special class of RelationshipType used to specify meaning to a link between two object instances. On many of these objects, there are metadata properties (xsd:element or xsd:attribute) that supplement meaning. For example, all properties of MeasureType have a mandatory "units" attribute.

3.4. What is the Global JXDM namespace?

Each release version has a distinct target namespace. The namespace for a given version is the URL "http://www.it.ojp.gov/jxdm/" concatenated with the version number "3.0.2" (for example). So, the namespace for release version 3.0.2 is http://www.it.ojp.gov/jxdm/3.0.2

This namespace is used for three purposes: (1) as an XML namespace, (2) for schema version control, and (3) to locate the distribution schemas and associated documentation. All releases can always be found under the base URL http://www.it.ojp.gov/jxdm. The specific version can always be found at the URL corresponding to its target namespace. The namespace for the current release is http://www.it.ojp.gov/jxdm/3.0.3

3.5. How were the Global JXDM components determined?

Data components were built from approximately 35 data dictionaries, XML schema documents, and XML data models under development or in use around the justice and public safety communities. These sources yielded over 16,000 data components (elements, attributes, and types). Through study and analysis of the similarities and differences among these components, approximately 2,200 properties (xsd:element, xsd:attribute) and 550 types (xsd:type) were synthesized to represent a common set of elements and types, namely the Global JXDM. It is important to realize that the authors did not invent content. Instead, the Global JXDM tries to capture the requirements of the 35 data sources as completely and accurately as possible. However, compromises were necessary in order to follow the basic design principles and criteria adopted by the GXSTF.

3.6. How are data elements constrained?

The Global JXDM is a reference model and schema. Elements are designed for maximum initial flexibility. They are:

Overly inclusive — there are more elements than necessary for many applications
Optional — minoccurs="0"
Unrestricted — maxoccurs="unbounded"

These rules are not absolute. There may be cases in which these rules are not practical or realistic, or where the XML Schema specifications must take precedence.

In addition the Global JXDM reference architecture defines a constraint schema in which more specific constraints can be applied to elements. The reference architecture is introduced here and described in greater detail here. Also, refer to the new Global JXDM User Guide: Building Exchange Content Using the Global Justice XML Data Model: A User Guide for Practitioners and Developers.

3.7. How are the Global JXDM components named?

The Global JXDM adopts ISO/IEC Standard 11179, Specification and Standardization of Data Elements, Part 5. Names are composed of three basic parts: an object class term, a property term, and a representation term. However, in the Global JXDM the object class term represents the real world object. Each of these terms may be further supplemented with optional qualifier terms (usually adjectives), as required to clarify or focus semantic meaning.

3.8. Why can't I find the component (type, element, or attribute) I am looking for?

There are several tools already available to help locate appropriate components in the Global JXDM. These include the Schema Subset Generation Tool which subsumed the functionality of the Global JXDM Model Viewer, and the Global JXDM spreadsheet that is part of each release distribution. The link to the version 3.0.3 spreadsheet can be found on this Web page.

Regardless of which search tool you use, you must understand the concept of inheritance of properties from general to specific types. Here is an example that illustrates inheritance.

One very general object (high level type) is ActivityType. There are a number of more specific objects derived from ActivityType. They include ArrestType and BookingType. All three aforementioned complex types have a number of properties (XML elements) that compose them. One property in ActivityType is ActivityDate (the date an activity occurred). Since ArrestType and BookingType are derived from ActivityType, they are considered more specific Activity objects with a number of specialized properties of their own. However, they each inherit all the properties of their parent, ActivityType. One property inherited by both ArrestType and BookingType is ActivityDate.

Now suppose you want to determine how to tag (in XML) an ArrestDate. If you search the Global JXDD schema for ArrestDate, you will not find one. The reason is that the value of an arrest date would be tagged as ActivityDate inside of the ArrestType. Analogously, a BookingDate would also be tagged as an ActivityDate inside of the BookingType. This is because the date of any specific activity derived from ActivityType inherits ActivityDate.

Object-oriented inheritance is efficient. If we had to create an element for every case that could otherwise use inheritance, the number of Global JXDM properties could increase greatly.

We do intend that common tagnames (e.g. ArrestDate) be entered into the dictionary with definitions and links to the elements that represent them (e.g. ActivityDate). However, they will not be generated in the schema specification.

Also, by design, synonymous elements are not permitted in the Global JXDD. However, data element definitions may contain synonyms that will not appear as tags in the Global JXDD schema. Thus, within the documentation it is easy to discover synonyms by searching. A data registry for the Global JXDM would also enable this.

3.9. Why do so many components have long names?

One design criteria is to provide a set of data element names that are relatively complete, semantically precise, and globally understood. The meaning of any given tagname should be determinable within a variety of circumstances, ranging from well-structured documents with rich context to transaction- or message-oriented formats that may be weak in context. To do this the GXSTF prohibits synonyms and uses ISO/IEC Standard 11179 Specification and Standardization of Data Elements syntax for naming elements. The resulting Global JXDD has potentially wide applicability and a larger scope, but the result is longer tagnames. However, it would be relatively easy to codify the tagnames for transmission efficiency or to apply compression techniques.

3.10. Does the Global JXDM use acronyms or abbreviations?

Abbreviations and acronyms are highly discouraged within data element names, except when commonly understood, rarely confused, widely accepted, and documented. Authorized abbreviations are listed and defined in the glossary of the documentation.

3.11. Why are there no elements of the type DateTime?

During analysis of the data requirements sources, the GXSTF found no evidence of the mandatory use of date and time together. Many sources had defined both date and time components, but there were no components of the type DateTime. The XML Schema DateTime type uses ISO 8601 format and does not permit the option to use either date or time without the other. This means that if a component is of type DateTime, then both date and time are significant and must be present. There is no way to indicate that time is insignificant or unknown. The GXSTF believes that this could lead to potentially confusing or misleading data. Therefore, it was decided to use xsd:date and xsd:time optionally and independently.

3.12. How are codes and literals handled, and why?

The source data requirements that were analyzed and found to be inconsistent in their use of codes. For components with the same meaning, some sources used codes while others used literals. When codes were used, they were not always drawn from the same code table. Some code tables are specific to local jurisdictions. In order to provide maximum flexibility, the Global JXDM usually provides both a code type element and a text type element (that may contain a literal). There are particular code tables that are always common, such as those published by the National Criminal Information Center (NCIC)-2000 and the American Association of Motor Vehicle Administrators (AAMVA). Therefore, the GXSTF provided a mechanism to use codes from other namespaces. This enables the use of standards without restriction to a single internal set of values. This also does not require a change to the Global JXDM namespace every time external standards change. For example, the GXSTF has created an NCIC-2000 schema in its own namespace that contains the NCIC code tables. Temporarily, the GXSTF refers to this as the NCIC-2000 proxy schema because it is external to the Global JXDM namespace and can be updated without causing the Global JXDM to change. The GXSTF anticipates that local jurisdictions will want to create their own proxy schemas for their local code tables as well.

3.13. Why are some types such as ApplicationNameType, DirectionCodeType, EnginePowerDisplacementType, LatitudeDegreeType, LongitudeDegreeType, MeasureType, and others not derived from the SuperType?

The GXSTF found a bug in XMLSpy that prevented refinement of the simple content of a complex type by restricting an existing complex type with simple content. It was decided that, in deference to XMLSpy users, schemas that use this capacity of XML Schema will be avoided. Instead, when a type with simple content is derived from a type with no content, generate the type as a root type, generating inherited properties of that type locally instead of using XML Schema type inheritance.

3.14. Why is a 9-digit SSN so complicated?

A 9-digit Social Security Number (SSN) is a seemingly simple concept that should uniquely apply to persons in the U.S. In the Global JXDM, one correct way to specify the Name and SSN for a person in its simplest terms is as follows:

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

Note that four levels of XML tags are required 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

Note that even though 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. However, consider that the SSN may also require an IDEffectiveDate and possibly an IDIssuingAuthorityText to specify which Social Security Office issued the identifier. The generic IDType has been designed with a stucture that is reusable for a number of other kinds of assigned identification. Many of these must use other properties. For example, a PersonStateID will require IDJurisdictionText (and/or Code) to designate the state that issued the identifier. IDEffectiveDate may also be required. Other forms of IDs may require IDExpirationDate and a more detailed textual description (IDTypeDescriptionText) that further qualifies the identification.

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

Again, these are optional and do not have to be used if not required. The SuperType properties can permit a user to specify the credibility of the SSN (or any other component). Some jurisdictions or law enforcement intelligence applications may require the date the SSN was reported, the identity of the person who reported it, and the reliability that it is correct.

The following is an expanded example of a Name and SSN where the application requires SSN to use some of the additional properties discussed above and a few others:

  <Person>
    <PersonFullName>John Doe</PersonFullName>
    <PersonAssignedDetails>
      <PersonSSNID
          reliability="0.60"
          sourceText="Social Security card"
          reportingPersonText="Detective Bill Smith"
          reportingOrganization="LA County PD"
          reportedDate="2001-08-29">
        <ID comment="unusually consecutive digits">123456789</ID>
        <IDEffectiveDate>1964-10-25</IDEffectiveDate>
        <IDIssuingAuthorityText>SSA, Chicago, IL</IDIssuingAuthorityText>
      </PersonSSNID>
    </PersonAssignedDetails>
  </Person>

3.15. What are all of the "XxxxYyyyReference" elements in the Global JXDM schema used for?

These Reference elements exist to allow users with multiple occurences of the same information object in a schema or instance to reference a single content-filled object rather than repeat it in different locations.

This ensures that the same information object does not repeat multiple times and mislead the receiver into thinking there are multiple (different) objects. If an object is recorded once and referenced from everywhere else it is used, then there is a lower risk of misunderstanding or inconsistency. This requires one specially typed XML element (XxxxYyyyReference) for each element in the model. Using this technique makes the Global JXDM somewhat redundant. There are more elegant ways to implement it. However, elegant implementations that eliminate the need for dual elements in the Global JXDM tend to increase the redundancy, and therefore increase the number of the decision points for applications that process the XML. The use of separate elements for bearing content and content references makes it easier for applications to know immediately if and when they are looking at the information object itself or a reference to it.

3.16. What is an XML document? What is Information Exchange Package Documentation (IEPD)? How does this relate to the Global JXDM DocumentType?

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 Global JXDM, 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 transmitted information, as well as what we traditionally recognize as a document.

Global JXDM Information Exchange Package Documentation (generally referred to as an IEPD) is a specification for a model document or transaction that has been derived from and uses the Global JXDM. It is considered a suggested reference model for a particular kind document. For example, an Arrest Warrant IEPD uses the Global JXDM, is specified in XML Schema, and is a reference for building an Arrest Warrant. This means that it can be used as is, or extended for a more specific or local purpose, or to guide construction of another similar document specification. An IEPD is a starting point for a standard, not a rigid, fixed standard specification. For more detailed information on IEPDs refer to Global JXDM Information Exchange Package Documentation Guidelines, Version 1.1

The Global JXDM contains a DocumentType component from which standard XML document schemas can be derived. The Global JXDM DocumentType includes commonly used properties, such as control and records management metadata, security and classification metadata, and general document descriptive metadata.

Within its own target namespace, an IEPD document schema will import the Global JXDM namespace (or a subset) and usually extend the DocumentType to create its document element (sometimes referred to as the root element). For example, a CitationDocument schema would import the Global JXDM namespace and create (1) a CitationDocumentType that extends j:DocumentType, and (2) a complex root element CitationDocument of type CitationDocumentType. Consequently, CitationDocumentType inherits all of the standard metadata properties of j:DocumentType. Each document designates its own target namespace, enabling local document customization and preventing name conflicts.

The following example illustrates the Citation scenario described above with a very simple CitationDocument:

CitationDocument.xsd — an XML schema

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://park.gatech.edu/citation" 
    xmlns:j="http://www.it.ojp.gov/jxdm/3.0" 
    xmlns="http://park.gatech.edu/citation" 
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:import namespace="http://www.it.ojp.gov/jxdm/3.0" 
        schemaLocation="3.0/jxdm.xsd" />

    <xs:element name="CitationDocument" type="CitationDocumentType"></xs:element>

    <xs:complexType name="CitationDocumentType">
        <xs:complexContent>
            <xs:extension base="j:DocumentType">
                <xs:sequence>
                    <xs:element ref="j:Citation" />
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

</xs:schema>

CitationDocument.xml — an XML instance for the schema above.

<?xml version="1.0" encoding="utf-8" ?> 
<CitationDocument xmlns="http://park.gatech.edu/citation" 
    xmlns:j="http://www.it.ojp.gov/jxdm/3.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://park.gatech.edu/citation CitationDocument.xsd">
    
        <j:Citation>
            <j:ActivityID>
          <j:ID>C519</j:ID>
            </j:ActivityID> 
            <j:ActivityDate>2003-12-25</j:ActivityDate> 
            <j:ActivityTime>11:53:00</j:ActivityTime> 
            <j:CitationIssuingOfficial>
                <j:PersonName>
                    <j:PersonFullName>John Doe</j:PersonFullName> 
                </j:PersonName>
                <j:EnforcementOfficialBadgeID>
                    <j:ID>3033</j:ID>
                </j:EnforcementOfficialBadgeID> 
            </j:CitationIssuingOfficial>
        </j:Citation>
    
</CitationDocument>

3.17. What are reference exchange documents? What are IEPDs? Are there examples?

The term reference exchange document has been replaced with the term Information Exchange Package Documentation or IEPD. This term was derived from the Federal Enterprise Architecture concept of an Information Exchange Package, a standard message structure. Refer to the Federal Enterprise Architecture Consolidated Reference Model Document for more information.

An important goal of the GXSTF has been to provide justice practitioners and their contractors with components to develop standard XML schema to provide common instruments of justice information exchange that can be leveraged by all. For several years, the justice community has been developing functional XML specifications for common justice documents, such as Arrest Warrant, Arrest Report, Incident Report, Amber Alert, Rap Sheet, Sentencing Order, and others. The Global JXDM approach is to construct IEPDs with Global JXDM components and to provide these as model document schemas that can be used, as is, or extended by the justice community to meet individual jurisdictional requirements.

For a detailed explanation and description of IEPDs, refer to Global JXDM Information Exchange Package Documentation Guidelines, Version 1.1. A rather complete example of an IEPD that uses Global JXDM 3.0.2 is the Amber Alert. This IEPD was built by the OASIS LegalXML Integrated Justice Technical Committee.

The GXSTF identified a list of 100+ documents in common use and for which IEPDs are potentially required. Building, approving, and making these available are tasks that require much planning and coordination. Monitor the OJP IT Initiatives Web site for the latest information and plans for IEPDs.

4. Tools and Capabilities

4.1. Must I use the full Global JXDM distribution for my applications, or can I use only part (i.e., subsets) of the full schemas?

No, it is not necessary to use the entire Global JXDM for an application. GTRI built the Global JXDM Schema Subset Generation Tool (SSGT) to provide users with the ability to select only the types and properties they need in the schemas they build. The SSGT also contains the Global JXDM Model Viewer, a lookup tool that enables the user to search and navigate the data model and find components based on name, definition, or other attributes. As appropriate components are identified, the user can add (select and move) them to the schema subset being built. When all required components have been selected, a correct subset schema of the Global JXDM can be generated. This generated subset will include all dependencies required to ensure proper validation. A description of this particular subset will be saved as a wantlist specification. The wantlist is an open (XML) specification of the subset, used to reload a subset for modification. Refer to What is a Global JXDM wantlist? for more information.

4.2. What is the Global JXDM Schema Subset Generation Tool (SSGT)?

Based on the concept of custom schema subsets, the Schema Subset Generation Tool (SSGT) is an on-line prototype that enables the user to identify required Global JXDM components (using the Global JXDM Viewer), sequence them, and generate a correct schema subset of the Global JXDM for a specific application. The SSGT also allows you to save and reload your work in a wantlist. A schema subset lets you use and validate only those parts of the Global JXDM (i.e. a subset) required for your specific application. This is based upon the rule that an instance, which validates against a correct schema subset of Global JXDM, will also validate against the entire Global JXDM schema. The SSGT is available now, and subsumes the Global JXDM Viewer. Refer to What is a Global JXDM wantlist? for more information.

4.3. What is a Global JXDM "wantlist?"

A Global JXDM component is any XML type, element, or attribute in the dictionary schema. A Global JXDM wantlist is an XML instance (based on a schema) for identifying the Global JXDM components required for a given subset. It is the intermediate format that the Schema Subset Generation Tool (SSGT) uses and edits, and subsequently uses to generate a correct subset of the Global JXDM. By employing this open XML-based specification, it is possible for other tools (such as editors or schema builders) to interact with the SSGT.

4.4. What is the Global JXDM Viewer? Where has it gone?

The Global JXDM Viewer is now a functional capability contained within the SSGT. This search and navigational capability can be used to find Global JXDM components or browse the model. Note that the SSGT prototype is in spiral development. New capabilities, enhancements, and optimizations will be applied and made available as soon as they have been tested.

4.5. What is the Justice Information Exchange Model (JIEM) Modeling Tool?

The Justice Information Exchange Model (JIEM) Modeling Tool, a software package developed by SEARCH, the National Consortium for Justice Information and Statistics, provides a Web-based user interface, business logic, and relational database designed to document information flow and business rules in criminal justice operational processes. The JIEM Modeling Tool allows justice practitioners to model current data flow (the AS-IS Model) among their systems and enter specific information about each data exchange. Once the data about all of the exchanges are entered into the tool, it is possible to generate tabular and graphical reports that help justice practitioners identify redundancy, bottlenecks, and opportunities to improve justice system work flow, as well as identify the specific data exchanges that are their highest priority for automation (the TO-BE Model).

SEARCH, with Georgia Tech Research Institute (GTRI) as its contractor, has developed a "Next Generation" JIEM Modeling Tool. The new JIEM Modeling Tool provides a bridge to Global JXDM components, that will include Global JXDM IEPDs, as they are developed. This will help justice practitioners model the information dimension of their TO-BE data exchanges to be consistent with national justice data exchange standards.

4.6. What tools have difficulty with the Global JXDM schemas?

We have received reports that Apache Axis does not support the ID/IDREF used by the Global JXDM schemas to connect relationships in the model.

XMLSpy is known to take a long time to fully validate files built with the Global JXDM schemas. However, the GXSTF has not seen it fail.

Some developers have tried to use JAXB to compile the Global JXDM schemas into classes. Although now corrected, JAXB experienced a limitation problem with enumeration types that prevented it from completely processing large enumeration types, such as those in the NCIC-2000 namespace. However, there are still other issues that apparently prevent processing of the entire Global JXDM. Smaller schema subsets might still be possible to process.

4.7. Why can't I validate the Global JXDM schemas with XMLSpy?

If you must use XMLSpy, do NOT use it for validation. XMLSpy demands too much overhead to load and examine imported and included files. The external schemas (such as NCIC-2000) are very large. If you want to use XMLSpy to view the model, then ensure you have unchecked (not checked) both options "Validate upon opening file" and "Validate upon saving file" in the Tools/Options/Files window.

4.8. What are context data elements?

The Global JXDM is an object-oriented model that takes advantage of property inheritance to reuse components. This helps to keep the total number of elements smaller. However, this also means that some specific data element names do not exist in the dictionary because more generically named properties are inherited down to the more specific subtypes. For example, the Global JXDM does not contain an ArrestDate element. This is because an arrest date is represented by ActivityDate (a property of ActivityType) within an Arrest (of type ArrestType). ActivityDate is inherited by ArrestType (a subtype of ActivityType). The following is a sample excerpt from an instance document containing an Arrest element:

  ...
  <Arrest>
    <ActivityReasonText>
      automobile accident caused by road rage
    </ActivityReasonText>
    <ActivityDate>2004-01-01</ActivityDate>
    <ActivityTime>01:30:00</ActivityTime>
    <ArrestTypeCode>T</ArrestTypeCode>
    <ArrestSubject>
      ...
    </ArrestSubject>
    ...
  </Arrest>
  ...

Note that Arrest inherits Activity properties because it is an ActivityType.

In order to improve understanding of this concept within the Global JXDM, we intend to add the capability to store common names (context data elements) in the dictionary database that are not used in the Global JXDD schema. These context elements will be defined and will refer (link) to the Global JXDM elements that represent them in a given context. For example, ArrestDate will be defined in the Global JXDD and its entry referenced to (linked to) ActivityDate and explain the Arrest context. This capability will assist users who must map their local dictionaries to the Global JXDM. There are a number of ways to identify appropriate context data elements. The GXSTF is evaluating them.

The Global JXDM Viewer, contained within the SSGT, is currently capable of using context data elements for navigation. Refer to What is the Global JXDM Viewer? Where has it gone? for more information. However, there are no context data elements in the database as yet. Identifying what context data elements should be placed into the Global JXDM database will be evolutionary and based upon input from the field and methods for collecting such.

4.9. What are Global JXDM "key words?"

There are often many ways to name a particular data element. The Global JXDM prohibits the use of synonyms within the XML schema specification, however, the Global JXDD database from which the schema is generated may contain additional navigational terms to help identify the Global JXDM names for required components. We refer to such navigational terms as key words. Like context data elements, key words do not appear in the Global JXDM schema but do appear in the dictionary database, however, key words differ from context data elements in that they are not represented by inherited Global JXDM properties (which usually have generic names). Instead, they are simply terms or common abbreviations that are near in meaning to, synonymous with, or suggestive of Global JXDM property names. Key words often come from other data models, dictionaries, or schemas. The following are a few examples of key words and the Global JXDM components they might link to:

	KEY WORD        LINKS TO
	Automobile      Vehicle
	Car             Vehicle
	ChildFlag       JuvenileIndicator
	Fine            DisciplinaryActionFee

Key word capability is available in the Global JXDM Viewer, contained within the SSGT. Refer to What is the Global JXDM Viewer? Where has it gone? for more information. However, the key words themselves must be identified and entered into the database and linked to the appropriate Global JXDM properties before users will be able to use them to navigate.

4.10. Have you considered a Global JXDM data registry?

Yes. The ultimate intent of the GXSTF is to establish a Global Justice Data Registry capability. This would provide a single logical point of access to all Global JXDM artifacts, including the Global JXDD content, the schema releases, IEPDs and their artifacts, tools, and additional capabilities. These may be stored in one repository or in multiple distributed networked repositories. The registry would be standards-based and present multiple interfaces (e.g. browser, Web services) to enable both users and other servers to access, navigate, view, and retrieve metadata from the Global JXDM.

The data registry may be implemented with commercial registry software, depending upon requirements and cost-effectiveness. The GXSTF and OJP are evaluating requirements and alternatives.

5. Training, Documentation, and Support

5.1. Is a Global JXDM User Guide available?

Yes: Building Exchange Content Using the Global Justice XML Data Model: A User Guide for Practitioners and Developers.

Other good sources of information are the Global JXDM Developer's Workshop On-line Training Materials that consist of all the presentations, training materials, and recorded audio/video streams from the first developer's workshop held at Georgia Tech in Atlanta, May 11-12, 2004.

5.2. Collaboration — Who is using the Global JXDM?

There are over 40 projects using or committed to using the Global JXDM for their data exchange applications. If you are interested in collaborating or sharing experiences with any of these organizations, refer to the Organizations Utilizing the Global JXDM list.

5.3. Is training available for Global JXDM?

The first Global JXDM Developer's Workshop was held on the Georgia Tech Campus in Atlanta, Georgia on May 11-13, 2004 This three-day training event was recorded, and segments were made available on the OJP IT Initiatives Web site under the topic Global JXDM Developer's Workshop On-Line Training Materials. This resource contains streaming video sessions, slideshow presentations, and all training materials.

Developer's Workshops are held periodically. The Global JXDM Training and Events Web page contains the latest training information. Subject to availability of resources, workshops may also be conducted at user sites for audiences of 30 or more. Use the OJP IT Initiatives' Contact Us form for inquiries.

6. What can I do?

6.1. How can I make comments, suggestions, or ask questions about the Global JXDM?

Visit the Global JXDM Bugzilla-based Feedback Web site. All comments are reviewed and evaluated by the GXSTF. You may also wish to join the Global JXDM Listserv. This allows you to share and submit questions, and exchange experiences with other practitioners in the community who are planning or have implemented a project using the Global JXDM.

6.2. What if I need a data element to represent my own local data elements?

The Global JXDM is a reference model that is based on a class hierarchy of many specific objects (xsd:type) derived from one very general object (SuperType). Any xsd:complexType can be extended to include additional properties (xsd:elements) as necessary. XML instances based on a schema that locally extends the Global JXDM will contain elements that are only recognized by local applications that are aware of the new elements. However, applications expecting the original reference model components can still understand the Global JXDM baseline components.

6.3. How can I get my data requirements into the Global JXDD?

Your comments, suggestions, questions, and concerns are welcomed at the Global JXDM Bugzilla-based Feedback Web site.

Currently, the GXSTF evaluates all feedback and determines what components should be added to subsequent releases of the specification. In some cases, GXSTF may contact users directly to request more information, specifications, clarifications, or help with a user domain.

If you submit a request for a new component, then please include an ISO/IEC Standard 11179 compliant name and a complete definition. Also, ensure that you tell us where in the Global JXDM you believe your component is needed. This may not always be obvious.

6.4. How do I request training or technical support for my project?

If you need training, project help, or general technical assistance, please submit your request through the OJP IT Initiatives' Contact Us form.

For specific questions, submitting suggestions, requesting component changes, etc. on the Global JXDM and Global JXDD, please use the Global JXDM Bugzilla-based Feedback Web site.

7. Other Topics

7.1. Are there any other FAQ resources covering the Global JXDM?

There is another set of FAQs gathered from participants at the Global JXDM Developer's Workshop conducted, in May 2004. Refer to the Questions and Answers link on the Global JXDM Developer's Workshop On-line Training Materials Web site.

Return to the Global JXDM introduction page.

Frequently Asked Questions (FAQ)

August 24, 2005

Contents

1. General

2. Releases

3. Technical

4. Tools and Capabilities

5. Training, Documentation, and Support

6. What can I do?

7. Other Topics

Questions and Answers

1. General

2. Releases

3. Technical

4. Tools and Capabilities

5. Training, Documentation, and Support

6. What can I do?

7. Other Topics