Global JXDM Developer's Workshop Questions and Answers

A wantlist used with the Schema Subset Generation Tool is a simple XML file that specifies all of the components required for a subset of the Global JXDM. The XML schema for a wantlist specifies the format for a wantlist instance.

An Ant task would be much like a makefile dependency. It would generate files based on input files, and update them when the inputs changed. An Ant task specific to subschema development would depend on some pieces not yet present:

1. A want-list specification
2. Loading of want-lists
3. A web services-based system, or other simple system, for generating the schemas automatically from the want-list

Once steps 1 through 3 are complete, anyone would be able to generate such an Ant task, and we'd be glad to inform people of its existence.

Definitely. We are looking forward to providing WS-based functionality for schema generation.

No. The schema subset will be used in place of the full reference schema.

There are numerous data representations with higher information densities than XML. There are, within the XML world, other naming methods that would produce higher information densities than Global JXDM.

The goal in Global JXDM was not to maximize information density, but to maximize reuse and understandability. We adapted the Federal XML guidelines, while keeping an eye on RDF and knowledge management methods. Global element definitions allow for increased reuse of terms, and better knowledge exchange. They do increase the size of tag names, however.

The Integrated Justice Information Systems (IJIS) Institute has initiated a project to conduct performance testing with Global JXDM. One aspect of this testing focuses on tagname length and performance. These results will be available when this project has been completed. Contact the IJIS Institute for more current information.

Nillable fields are definitely a possibility. We need to take a look at the implications of such a strategy.

Also, please note that version 3.0.0.3 is a prerelease and is no longer supported. You should move to 3.0.

UPDATE: The latest release version 3.0.1 allows nillable fields for all elements. However, note that you cannot simply omit the data values for such elements. The W3C XML Schema specification requires that you explicitly declare that a field is empty in the instance. The following is a simple example taken from the W3C XML Schema Part 0: Primer.

XML schema:

          <xsd:element name="shipDate" type="xsd:date" nillable="true"/>

XML instance:

          <shipDate xsi:nil="true"></shipDate>

At the time of the initial design of the Global JXDM schemas, it was thought that fixed-order sequences of sub-elements were the best design. However, there are distinct advantages to variably-ordered sub-elements. Such advantages include better representation of certain types of ordered data, such as interleaved "given name" and "family name" elements.

There are also concerns that must be addressed before adopting this design. How would such structures be represented in languages like Java? (All of a sudden sequence matters, but instance data members have no implied ordering.) How would XSD extension work?

It is an attractive idea, but we have issues to deal with before moving forward with it.

All elements are defined globally so that they may be reused by other schemas. Each element is given a single global definition. This definition may be used by an outside schema by using the <element ref="j:name"> construct. Were we to not define them globally, then elements would not be referenceable from outside.

There were a few main reasons behind splitting the reference elements out from the data elements:

1. Extensibility: The current reference mechanism uses IDREF from XML and XSD. There will be others in the future. These may include XLink-based and XPointer-based references. Keeping references in separate elements minimizes dependencies between such systems, and will allow XLink-based links to be a drop-in replacement for the current links.
2. Data Normalization: The current reference elements have no data content. They simply represent the labelled edge from one data node to another. Allowing them to contain additional data would complicate matters. Does data in the referring element override data in the referred element? Does it augment it? Since they refer to other IDs and don't have IDs of their own, other links would have difficulty referring to them; unless they also had IDs of their own; but those IDs would have to be different from the referred IDs. So you would have to chain them somehow. It becomes much more complicated.
3. Data Formatting: Data elements may have required data content, such as a date string having a fixed format (2004-03-02). For such elements, meaningless or bogus data would have to be constructed to allow the data to validate.
4. Separate Specification: For those using schema subsets, it is nice to be able to separately specify what may be included as data elements, and what may be included as references. Separate reference elements gives you that flexibility.

Adding all of these issues together definitely suggests that separation of data (content) and reference elements is preferred.

The schema generation tool, with its associated want lists, should help with management of schemas. Users will be able to audit their subsets, indicating changes required from one version of the data model to the next. The want lists will also act as a basis for constraint schemas, so patching may be reasonable.

When an external standard is updated, it may be added to a compatible minor revision of the data model. Components of the external standard may be included as additional representations (with new qualifier terms / dot notation).

There will likely be copyright and licensing issues with regard to redistribution of external standards, and we will try to clarify any licensing issues that we are aware of that arise.

The same graph constructs are used for relationships and properties because they represent the same data. It is a key concept to keep in mind: the graphs are consistent, regardless of which XML syntax you are using to represent them (inclusion, references, or relationships).

Relationships are properties, with a specific representation. So the data graphs are identical.

We could use UML to represent these, but certain translations would have to be performed. UML is richer (and more complicated) than the simple data graphs we use for this project.

The full source for the validation tool is available from the GTRI website. Download the zip file; all source code is included.

The tool adds a command line to the Xerces validation code. Full documentation for the Xerces XML parser is available from the Apache website. The required parts of the Xerces library are included in the jar file used to run the validator.

The error message from the SAXException is generated by Xerces. Give it bad data to see an example.

None of the tools created by GTRI have any dependency on Microsoft extension to the Java VM. They are all developed using the Sun SDK.

It is up to the application or document designer to decide what root element they wish to use for their data instances. I may decide to use my own root element, or I could use an element from the data model schemas. The most common model is that I would use a type derived from DocumentType as my root element, and include required components within it.

In any case, types in the data model are constrained in their content. A SubjectType may not contain random elements; all elements contained in a type are explicitly defined by the data model schemas.

Recursion has been raised as a problem by some users. This is a necessary tool for the data model. In order to represent realistic relationships, we must allow entities to refer to like entities: a person has a friend who is a person.

Any tool that attempts to expand nested elements (and thereby discovers the meaning of infinite recursive descent) should rethink their methods. Should you, given an unbounded sequence of elements, expand the infinite list? You should not. Likewise, you should not expand recursive elements.

An alternate strategy might be to design the model such that that the object of the friend may not himself have any relations to persons, and so is a fundamentally different type. Such a definition would require a great amount of work, primarily to avoid the direct representation. Keep in mind that this direct representation helps to give the data model a great deal of power and flexibility.

You may wish to use a subset of the data model schema to omit such contained elements. You could instead use references or relationships to represent those properties, instead of contained elements.

It would not hurt to suggest to your tool vendors that they should properly support recursive schemas.

Many of the elements in the data model schemas have references to language codes for internationalization (i18n). Names and types have been modified to accommodate requirements of i18n. However, our primary audience is the U.S. justice community, and this standard has been created appropriately.

We would appreciate similar international efforts being brought to our attention.

This relates back to the joke "What is metadata? --The source of all bar fights between managers at information sharing conferences". In pre-releases of the Global JXDM, IDType was structured so that the ID value was represented as a literal string and other information, such as expiration date, was represented as attributes of IDType. It was determined by our domain experts that some people consider this other information that goes along with IDType to be data rather than metadata, and would thus need to be able to carry its own common metadata. This has required us to change the other information relating to IDs from attributes to elements. This in turn changes IDType from a structure that can carry a simple literal value and attributes to a structure that has sub-elements, including one for the actual ID value itself. We recognize that it is an inconvenience to some, but it is a requirement for others. This is one of the compromises we have had to make.

It is not correct to remove hierarchy from types. Of course it is possible for anyone to create a subset schema or their own schema with PersonSSNID directly under PersonType, but this would be invalid because it would create inconsistencies with the full reference schema. The goal is to make information shareable. If someone uses a modified PersonType that looks different from the common PersonType, then that modified PersonType is only understood locally.

We do see benefits in adding commonly used codes to the Global JXDM even if they do not come from a standard authoritative source since it can be better information sharing to have a single well known non-authoritative set rather than many different local non-authoritative sets. However, we would want to add non-authoritative codes carefully, making sure they are vetted before addition to be as stable as possible, requiring little in the way of future modifications.

This question was addressed during the presentation with the discussion of constraint schemas (Day 2 - The Reference Architecture) but here is a brief answer - subset schemas and constraint schemas. Subset schemas can be used not only to pick and choose which elements you want to use but also to set global constraints, such as the number of occurrences of elements within types. For example, it is perfectly valid in subset schemas to change the minimum/maximum occurrence attributes from their default values of 0 to unbounded to a user specified value.

Setting more advanced constraints, like defining one subset for PersonType in a certain context and another subset for PersonType in a different context (e.g., do you want your juvenile to look just like your criminal?) is not possible in a subset, where everything must be defined globally to stay consistent with the reference schema. These kinds of constraints can also not be set in a local namespace because the use of xsd:restriction can cause problems and is not a fool-proof way of validating constraints. To effectively control how Global JXDM components are constrained, you need to be able to control how those components are actually defined, which will have to be done in the Global JXDM namespace.

Constraint schemas are like a user sandbox in the Global JXDM namespace - users can locally define Global JXDM components without affecting actual Global JXDM definitions. In a constraint schema, you can set element PersonGivenName to be of a constrained string type with a maximum length of 32 characters. You can set occurrences here. You can also create local components. This lets you do things like create one PersonType for a juvenile (no identifying information) and a different PersonType for a criminal (lots of identifying information).

The caveats to constraint schemas are multi-pass validation and limited scope. Because constraint schemas have a lot of power and flexibility, they are able to define instances that do not conform to the Global JXDM. To make sure that you have valid Global JXDM data, you must be able to validate against either the full reference schema or a valid subset schema in addition to the constraint schema. Validating in two passes lets you check both Global JXDM conformance and local user constraints. Because of this, you cannot do things in your constraint schema that would cause inconsistencies with the reference schema (e.g., rename elements, remove hierarchy). Finally, constraint schemas are local and solely for the purpose of checking user constraints. Anything you define in this local constraint schema is just that - local. You may do things like create your own JuvenileType and your own CriminalType, but you can't reuse these components outside of the constraint schemas because they are not real Global JXDM components.

The ActivityID property inherited by CitationType from ActivityType should be used as the citation number or citation identifier. One of the PE's asked for a Violation ID (not a Citation ID). CitationViolation is of type IncidentType, and therefore, also inherits an ActivityID from ActivityType (because IncidentType IS-A ActivityType). Therefore, an ActivityID represents a Violation ID within a CitationViolation when required. To make this a little clearer, here are the appropriate extracts from the Global JXDM spreadsheet:

Citation                                CitationType extends ActivityType
	CitationFineAmount                  AmountType
	CitationDismissalConditionIndicator j-xsd:boolean
	CitationDismissalConditionText      TextType
	CitationSubject                     SubjectType
	CitationIssuedLocation              LocationType
	CitationIssuingOfficial             EnforcementOfficialType
	CitationAgency                      OrganizationType
	CitationViolation                   IncidentType

Incident                                IncidentType extends ActivityType

The Justice XML data dictionary is just one part of the solution to defining standard exchanges. The dictionary contains well-defined pieces to be used in many different justice and public safety exchanges. The dictionary represents requirements from the entire community and must thus be very flexible (e.g., the same pieces are not going to be required by both a sentencing order and a traffic citation).

Having a flexible dictionary for the community is great, but it is not enough to explicitly define standard individual exchanges. This is where reference documents come in. A reference document is a schema for a single information exchange that defines what elements should appear. This could be a standard incident report, a standard traffic citation, a standard sentencing order, and so on. Each reference document may be accompanied by its own subset schema and constraint schema, which will allow the low-level kinds of constraint setting necessary to create a well-defined exchange.

Additional information about reference documents: Although none currently exist, it is expected that work developing them will begin soon. There is a list of about 150 of the most common that are planned to be created. Reference documents themselves may be customized by users by extension.

Context definitions are not another tool. They are simply additional terms (property names) and respective definitions that map to and are represented by a particular Global JXDM component in XML. Global JXDM components are rendered as XML in the Global JXDM schema, context terms and definitions are not. Context definitions are metadata that will exist only to improve searching in the Global JXDM. They are planned additions to the search capabilities of the model viewer and schema subset tools. There is no defined process established for collecting these context definitions. Several techniques are known and a few are obvious (for example, all inherited Global JXDM properties are clear candidates for having associated context terms and definitions) Some context definitions will likely come from reference documents. All will be approved by the XSTF.

Standard mappings are different from context definitions. These are envisioned as pre-defined mappings between commonly known data sets and Global JXDM (for example, between NIBRS and Global JXDM). There is no formal plan as yet for determining what data sets should or will be mapped. However, the intent is to work with data set owners to establish these mappings once and publish them for all to reuse.

If a business data item can't be mapped to a Global JXDM property, a local extension is the appropriate thing to do - there is nothing more elegant. If the property is of general use within the justice community, it should be submitted for possible addition to the Global JXDM.

ActivityID is correct because it is the ID of the citation that is exchanged, and ActivityID is really the Citation ID as inherited from the broader Activity. Some implementations could have a separate and distinct DocumentID as a control number for the document itself, as opposed to the number designating a particular citation activity.

Let's say that a state pre-numbers all of the citations and tracks the IDs to deter officers from tearing up citations for their friends. Now let's say that there is a citation form with ID number C123 that has not been issued yet. C123 is not the identifier of an actual citation. So far it is only the identifier of a citation form - the document ID. Once the citation has been issued, an actual activity has occurred and now has the same value as document ID, C123.

There is a text field, PersonEducationLevelText, but no code set. You may create an extension to add this local code set.

That example would only be valid if you define an element local:FirstName inside of local:DoctorType. The element j:FirstName is defined as part of j:PersonType.

If you change the namespace from j to local, you lose the meaning of the element. The element FirstName only has meaning because it is in the j namespace, and we have defined it a certain way. And the only reason that it is legal in the first example is because j:PersonType is defined to contain j:FirstName.

1. Absolutely - building a constraint schema by starting from a subset schema is a great way to get started. 2. Yes, there will be (this feature is currently being developed). When a user uses the subsetter tool and builds a subset, a specification file will be returned along with the subsetted schemas. This specification file can be loaded back into the tool at a later date to make modifications to it or to use as a base for another subset.

We allow multiple representations for each property in the data model. Although most properties have only a single representation, there are several that have multiple representations. In such a case, we use that dot notation to separate the property name from the representation. The value after the dot is a qualifier, which identifies the representation.

For example, the property j:BondRevokeDate is alway of type j-xsd:date, but the property j:BondIssuer can either be of type j:PersonType or j:OrganizationType. So we use the qualifier Person for j:PersonType, and we use Organization for j:OrganizationType. This results in two, strongly typed, elements: j:BondIssuer.Person and j:BondIssuer.Organization.

Not likely from us. Please understand that we are not trying to build everything. That is why we work closely with the IJIS Institute Industry Working Group. Our intent is to implement a few tools in direct support of Global JXDM as rapidly as we can. We encourage industry to pick up the ball and establish additional tools that can be made commercially available with support. This is a primary reason that the specification for the Schema Subset Tool WantList (when completed) will be open source.

No. The very reason multi-pass validation is used is because it resolves several major issues concerning the need for conformance validation and validation of constraints that are not contained in the basic specification (because it must be optional and over-inclusive to be flexible).

All properties in the Global JXDM are defined to be asymmetric. Each property can be represented as a labelled, directional arc. Each property has a subject, or a thing that has the property, and an object, or value of the property.

An example of a property might be parent We could say that Bart Simpson has a parent of Homer Simpson. In this case, Bart would be the subject, that has the property. The property would be parent. The object, or the value of the property, would be Homer.

In the data model, we do not define higher level properties, such as the implication that if Bart has parent Homer) then Homer has child Bart. We also do not spell out specifically symmetrical relationships, such as that of spouse. If we know that Homer has spouse Marge, we don't imply that Marge has spouse Homer.

Relationships in the data model are a specific representation of these properties. They follow the same model as other properties: all properties have a subject (the thing that has the property) and an object (the value of the property). Such properties may be duplicated if required by the user to represent symmetry.

Higher level understanding of these basic properties is an area for future development.

Yes, the list is compiled HERE.

Unfortunately, the timeliness of this question was overlooked during the workshop. However, the Global JXDM Listserv could be used to organize such groups. Also, recall that all attendees were provided with contact information and email addresses.

See answer to question labeled " Agreement on references or relationships" below.

Interagency agreements among the levels and branches of government, and agencies within each level, provide the critical foundation of any data sharing effort, however, the development of these agreements is outside the scope of this Global JXDM initiative. The OJP has developed a wide variety of resource material to assist justice entities establish appropriate governance policies and instruments to support justice information sharing. These materials are available on the OJP IT Website. One important resource developed by OJP through a cooperative agreement with SEARCH is the Justice Information Exchange Model (JIEM) modeling tool, which can help justice organizations understand and document existing business processes and information exchange, in order to develop data exchanges using the Global JXDM components. JIEM includes four components:

1. A conceptual framework for analyzing and designing information exchange
2. A methodology for applying the conceptual framework in a particular jurisdiction
3. The JIEM Modeling Tool, a software package that allows sites to implement the conceptual framework and methodology quickly and easily
4. The JIEM Reference Model, an evolving set of standard information exchanges derived from the work of 22 state and local jurisdictions

Usually, JIEM analysis is conducted by bringing together a team of business process and technology experts from all the justice disciplines within a state, region, or county. This group performs an enterprise-level analysis of all their information exchanges. The JIEM tool is available at no cost to public entities, and training and technical assistance is provided by SEARCH and the IJIS Institute.

The Reference Architecture and Document Building curriculum, provided during the Developer Workshop, sets out JIEM analysis as the first step of the five step methodology for building exchange schemas using Global JXDM components.

Exchanges ultimately drive the conformance between two endpoints. The representation of the data within a system is internal to that system and does not affect the conformance.

The Global JXDM is a Reference Model and is not a rigid standard that must be used exactly as it stands in its entirety. It provides the underlying infrastructure (for lack of a better term), from which the data artifacts associated with an exchange can be constructed using local exchange schemas (commonly referred to as reference documents) having local namespaces. Compliance to the Global JXDM means that the data elements used within an exchange will validate against the Global JXDM. However, compliance to the exchange is another layer of compliance that is beyond the scope of the GXJDM and the definition of those exchanges between systems still need to be defined and standardized in many cases. Please refer to the question and answer on References and Agreements for more information on this topic.

From the Management Guidance presentation, the informal rules for conformance are:

1. Import and reference Global JXDM namespace or a correct subset.
2. If it exists, use the appropriate Global JXDM component. (i.e., do not create a duplicate of one that exists.)
3. Be semantically consistent; use Global JXDM components in accordance with their definitions; do not use an element to represent data other than what its definition describes.
4. Apply XML Schema extension rules correctly and consistently.

Remarks:

• Exchanges conform, NOT systems. What you call data or how you use it in your own system does not impact conformance. What counts is how you package data as XML for exchange.
• There is no concept of partial conformance. Just because you use parts of the Global JXDM to exchange with other justice agencies does NOT mean you are conformant. (You may be violating Rule 2.)

No. We said that parts of the ebXML specifications were used in Global JXDM. For example, Global JXDM uses the ebXML core component types for representation of its core types.

This is a great question! We'd like to see this too! Seriously, this is beyond the scope of our current charter. Global JXDM does not define a database design. In fact, recall that one design criteria for Global JXDM was that it should not be built to any specific system. It was designed to define and model information objects that are exchanged in the justice and public safety community. Database management system vendors are constantly adding and improving their XML interfaces and translational capabilities. Suggest you contact one and ask for a demonstration of this capability. The schema subset rules are published.

These are domain specific questions that we hear often. They generally relate to the design and creation of reference document schemas for particular purposes. Domain experts have a better understanding of how this should be done. Although, the Global XML Structure Task Force (XSTF) might still be involved. There are already some formal efforts in this regard (e.g., Rap Sheet), and much work remains to be done in many specialized areas. Watch for upcoming events regarding guidance for, help with, and general information about reference document design and construction.

One additional note: The design of Global JXDM was influenced by early versions of reference documents that existed in the justice community while Global JXDM was being implemented. We also anticipate that formal efforts to design and develop additional reference documents with Global JXDM will help us to evolve and possibly expand Global JXDM.