This is a list of questions that we have received regarding the Justice XML project and related technology.
The full name of the project is the Global Justice XML Data Model (GJXDM), but it will generally be referred to as "the data model"
Please send additional questions and comments to us using our feedback page.
1.1. What is the Global Justice XML Data Model?
1.3. Who authored the justice data model?
1.5. What basic principles and design criteria were used to build justice data model?
2.1. What are versions 1 and 2?
2.2. Does an XML DTD exist for the data model?
3.1. What are the GJXDM data model and database?
3.2. How is the data model structured?
3.3. What is the GJXDD namespace?
3.4. How were the data model components determined?
3.5. How are data elements constrained?
3.6. How are the justice data model components named?
3.7. Why can't I find the component (type, element, or attribute) I am looking for?
3.8. Why do so many components have long names?
3.9. Does the data model use acronyms or abbreviations?
3.10. Why are there no elements of the type DateTime?
3.11. How are codes and literals handled and why?
3.12. What are primary and secondary relationships, and how are they different?
3.13. Why are there properties marked as deleted in the documentation? What are deleted properties?
3.14. Why are IDType, MeasureType, and others not derived from SuperType?
4.2. Why do the schemas not load in my browser?
4.3. What tools have difficulty with the GJXDD v3 schemas?
4.4. Why can't I validate the justice data model schemas with XMLSpy?
5.1. How can I comment on, make suggestions, or ask questions about the justice data model?
5.2. What if I need a data element to represent MyDataElement?
5.3. How can I get my data requirements into the data dictionary?
5.4. How do I request training or technical support for my project?
1.1. What is the Global Justice XML Data Model?
An object-oriented data model, database, and XML schema specification (generated from the database) that represent the semantics and structure of common data elements and types required to exchange information consistently within the justice and public safety communities.
The first version was the Reconciliation Data Dictionary (RDD), which created a set of tag names from a set of justice-related exchanges. Georgia Tech turned the RDD into a simple schema, which was called the Justice XML Data Dictionary (JXDD).
Georgia Tech Research Institute (GTRI) began working with the XML Structure Task Force (XSTF) (see below) to create a more comprehensive product that included a data model, a data dictionary, and an XML schema generated from these. 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 development of JXDM, the Global Advisory Committee. So, the project and the package are now known as the Global Justice XML Data Model (GJXDM). For brevity, we will refer to it as the justice data model, or just "the data model".
1.3. Who authored the justice data model?
In August 2002, the Global Justice Information Sharing Initiative (or just Global) Infrastructure and Standards Working Group (ISWG) XML Committee formed the XML Structure Task Force (XSTF) to identify data requirements, explore XML concepts, and apply XML best practices to design and implement the Global Justice XML Data Dictionary (GJXDD). The XSTF is a working group composed of government and industry domain experts (from law enforcement, courts, corrections, etc.), technical managers, and engineers.
So, the
U.S. Department of Justice runs the
Office of Justice Programs, which sponsored the
Global Advisory Committee to create the
Global Justice Information Sharing Initiative
(also here),
which supervises the
Global Infrastructure/Standards Working Group,
which has a subcommittee called the
XML Structure Task Force,
which works with
The Georgia Tech Research Institute
in the creation of the justice data model and related technology.
To provide a consistent, extensible, maintainable, XML Schema reference specification for data elements and types that represents the data requirements of the general justice and public safety communities. A secondary goal is to develop a more comprehensive data dictionary to support the XML schemas, and to be used with technology other than XML Schema.
1.5. What basic principles and design criteria were used to build justice data model?
2.1. What are versions 1 and 2?
All of these and reference document examples can be found at http://justicexml.gtri.gatech.edu/
2.2. Does an XML DTD exist for the data model?
At present, there is no XML data type definition (DTD) for the justice data model, only XML Schema specification. However, we believe it is possible to generate an equivalent XML DTD from the current data model and database. If a requirement for such exists, please contact us via the feedback page.
3.1. What are the GJXDM data model and database?
The GJXDM is an object-oriented data model, which describes and adds structure to the data dictionary. The model is implemented in a relational database. This database is used to generate a consistent data dictionary schema in XML Schema. The database is also used to generate the data dictionary reference documentation in pdf format.
3.2. How is the data model structured?
The data model consists primarily of object classes and properties:
GJXDD v3 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, EventType, 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.3. What is the GJXDD namespace?
The namespace for the current prerelease is
http://www.it.ojp.gov/jxdd/prerelease/3.0.0.3
This namespace is used for schema version control. Eventually, there will be a /jxdd/3.0.0 folder that will contain the first stable release. It is also anticipated that a set of namespaces corresponding to a number of schemas for reference documents routinely used in the justice and public safety communities will be developed. The exact format for these is yet to be determined; however, each namespace might be formed roughly as follows:
http://www.it.ojp.gov/jxdd/IncidentReport/1.2.3
3.4. How were the data model components determined?
Data components were built from approximately 35 data dictionaries, XML Schema documents, or XML data models under development or in use around the justice and public safety communities. These sources yielded approximately 16,000 data components (elements, attributes, and types). Through study and analysis of the similarities and differences among these components, approximately 2,100 properties (xsd:element) and 300 type definitions (xsd:type) were synthesized to represent a common set of elements and types, the GJXDM v3. It is important to realize that the authors have not attempted to invent content. Instead, the data model 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 XML Structure Task Force.
3.5. How are data elements constrained?
GJXDD v3 is a reference model and schema. Elements are designed for maximum initial flexibility:
These rules are not absolute. There may be cases in which these rules are not practical or realistic, or where XML Schema rules must take precedence.
3.6. How are the justice data model components named?
The draft Federal XML Developer's Guide requires that XML data element names (tagnames) be specified using the syntax rules of ISO/IEC Standard 11179 (Specification and Standardization of Data Elements.) Therefore, all XML data element names contain three basic parts: object class term, property term, and a representation term. Each of these terms may be further supplemented with optional qualifier terms (essentially adjectives), as required to clarify or focus semantic meaning.
3.7. Why can't I find the component (type, element, or attribute) I am looking for?
You must understand the concept of inheritance of properties from more general types to more specific types. The easiest way to understand this is through the following example.
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 justice XML schema for ArrestDate you will not find one. The reason is because 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.
The reason for doing this is to take advantage of the efficiencies of object-oriented inheritance. If we created an element for every case that we could otherwise use inheritance, the justice data model could easily increase from about 2400 components to 5 or 6 times that many.
We do intend that common tagnames (like ArrestDate) be entered into the dictionary with definitions and links to the elements that represent them (like ActivityDate). However, they will not be generated in the schema specification.
Also, by design, synonymous elements are not permitted in the justice data model. However, data element definitions may contain synonyms that will not appear as tags in the XML Schema specification for the data model. Thus, within the documentation it is easy to discover synonyms by searching. A data registry for the justice data model would also enable this.
3.8. 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 XML Structure Task Force prohibits synonyms, and uses ISO/IEC Standard 11179 (Specification and Standardization of Data Elements) syntax for naming elements consistently and precisely. The resulting data dictionary has potentially wide applicability and a larger scope, but the expense is longer tagnames. However, it would not be difficult to codify the tagnames for transmission efficiency or to apply compression techniques.
3.9. Does the data model use acronyms or abbreviations?
The data model follows the Federal XML Developer's Guidelines, ebXML, ISO 11179, and best practices. Abbreviations and acronyms are highly discouraged within data element names, except when commonly understood, rarely confused, widely accepted, agreed upon, and documented. Authorized abbreviations are listed and defined in the glossary of the documentation.
3.10. Why are there no elements of the type DateTime?
During analysis of the data requirements sources, the XML Structure Task Force (XSTF) 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 XSTF 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.11. How are codes and literals handled and why?
The source data requirements that were analyzed were not consistent in their use of codes. For components with the same meaning, some sources used codes, 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, GJXDD v3 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, for example NCIC-2000 and the American Association of Motor Vehicle Administrators (AAMVA). Therefore, the XML Structure Task Force (XSTF) 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 justice data model namespace when every time external standards change. For example, the XSTF has created an NCIC-2000 schema in its own namespace that contains the NCIC code tables. Temporarily the XSTF refers to this as the NCIC-2000 proxy schema because it is external to the GJXDD v3 namespace and can be updated without causing the GJXDD v3 to change. The XSTF anticipates that local jurisdictions will want to create their own proxy schemas for their local code tables as well. A more technical explanation of how code tables and proxy schemas work is contained in the Technical Release Notes and the User/Implementer Guide (not yet available).
3.12. What are primary and secondary relationships, and how are they different?
Primary relationships are the common XML relationships that exist between an xsd:complexType and its defining properties (elements and attributes that compose it and make it complex.) These properties are generally inherent to nature of the complexType being defined. For example, PersonNameType has several inherent properties, including PersonFirstName, PersonMiddleName, and PersonLastName. These properties are actually parts of or compose a PersonNameType. Any complexType can be built with all primary relationships. However, sometimes this is not possible, practical, or sensible depending upon the situation. Secondary relationships provide an alternate method for using XML Schema to model relationships. A simple example is a family relationship between two persons. A secondary relationship mechanism enables you to create a FatherOf relationship between two fully attributed PersonType instances without having to define an XML complexType that requires one to be inside the other. The Technical Release Notes and the User/Implementer Guide will present the details for this mechanism.
3.13. Why are there properties marked as deleted in the documentation? What are deleted properties?
There are properties in the data model which are either vaguely defined, or which overlap other properties. We have marked these properties for deletion. These properties:
3.14. Why are IDType, MeasureType, and others not derived from SuperType?
The XML Structure Task Force found a bug in XMLSpy that prevented refinement to 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 type as a root type, generating inherited properties of that type locally instead of using XML Schema type inheritance.
The XML Structure Task Force is currently working on a partial schema generator, which will give users the ability to add only the elements they want in their local version and set constraints. This will allow applications to load and validate faster. (this will also account for the imported proxy schemas for codes as well).
4.2. Why do the schemas not load in my browser?
Some browsers seem to have difficulty loading large XML Schema files or load them very slowly. One could wait for them to load, or try a different browser.
4.3. What tools have difficulty with the GJXDD v3 schemas?
We have received reports that Apache Axis does not support the ID/IDREF used by the GJXDD v3 schemas to connect relationships in the model.
XMLSpy is also known to take a long time to fully validate files built with the GJXDD schemas. However, the XML Structure Task Force has not seen it fail.
4.4. Why can't I validate the justice data model schemas with XMLSpy?
If you must use XMLSpy, do NOT use it to validate. XMLSpy demands to much overhead to load and exam 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 do the following: In the Tools/Options/Files window ensure you have unchecked (not checked) both options "Validate upon opening file" and "Validate upon saving file."5.1. How can I comment on, make suggestions, or ask questions about the justice data model?
Visit the GJXDM Feedback Site All comments are reviewed and evaluated by the XML Structure Task Force (XSTF). The XSTF will try to answer as many questions as possible, within a reasonable time.
5.2. What if I need a data element to represent MyDataElement?
The justice data model 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 data model will contain elements only recognized by local applications that are aware of the new elements. However, as long as the extended schema and associated instances have been specified properly (see User/Implementer Guide, when available), then all applications expecting the original reference model components can still understand the GJXDD v3 baseline components.
5.3. How can I get my data requirements into the data dictionary?
Formal governance policies and procedures are not yet in place. The current versions are considered prereleases or Release for Comment until basic structural design of the data model is stable and a large part of the dictionary content has been designed. During this time period, your comments, suggestions, questions, and concerns are welcomed at the GJXDM Feedback Site
Currently, the XML Structure Task Force (XSTF) evaluates all comments and determines what components should be added to subsequent prereleases of the specification. In some cases, the XSTF may contact users directly to request information, specifications, clarifications, or even help with a user domain.
If you submit a request for a new component, then please include an ISO 11179 compliant name and a complete definition. Otherwise, we will be guessing your intent. Also, ensure you tell us where in the data model you believe your component is necessary (this may not always be obvious).
5.4. How do I request training or technical support for my project?
If you need training, project help, or general technical assistance, then please submit your request to the Office of Justice Programs.
Please use the GJXDM Feedback website only for asking fairly specific questions, submitting suggestions, requesting component changes, etc. for the data model and dictionary.