Refinement Task Force Report

While the Refinement Task Force Report is to be commended for its very clear
definition of the problems relating to content model
substitability/refinement, it does seem to have missed an opportunity to say
something about what may be a more important type of
Reuse/Modification/Subtyping that is vital to the use of XML for EDI:
permitted attribute values and permitted content. Within EDI applications
many data elements are defined in terms of lists of permitted codes. The XML
Schema enumeration datatype is designed to provide features for the
definition of such lists, but the import/include/refine model of the
structures definition is sadly lacking in facilities for the proper
management of such lists.

Let me start with a (somewhat simplified) statement of requirements:

At the United Nations it is determined that a particular data element is to
contain a code value that is to be taken from one of a number of formally
recognized code lists, the agency providing these code lists being
identified in another data element in the message instance (which could be
represented in the XML data as an element or attribute whose content/value
is an enumerated list).

Requirement: Selection of which enumeration list to import or include based
on the value selected from another code list

At the European Expert Group for a particular industry area it is determined
that only a subset of the permitted code lists will be permitted for
cross-European trade

Requirement: Reduction of list of permitted value, and any imports based on
values no longer listed

At a national assembly for the relevant industry trade body it is determined
that certain of the values in a code list should not be allowed when the
message is used between members of the trade body

Requirement: Identification of non-acceptable code values from within an
imported/included list

A national industry trade body decides that the values in the code list need
to be expressed in the local language, rather than one of the ones defined
by the UN.

Requirement: To replace a code list with an equivalent set of locally
meainingul values, where there is an ordered relationship between the two
code lists.

Two companies, in agreeing to use a particular type of message agree that
only codes that conform to a list one of the companies maintains shall be
used within messages sent between the two companies

Requirement: Replacement of code list defined in generalized schema with
code list of partners using the schema.

Two months after the DTD is agreed a message is sent that includes items
that are not listed in the original code list used for the schema.

Requirement: Facilities to extend a schema definition, either on a
per-message override basis or in the form of an "extend permitted code list"
instruction within the internal subset of a message instance.

The management of lists of permitted values over time is critical. Whilst a
limited versioning property is defined for the schema no such versioning has
yet been defined for imported or included definitions. The fact that
importation and inclusion must be done as part of the preamble to the
definitions, rather than as part of a declaration of the particular element
or attribute, is likely to lead to error. Conditional importation, in
particular, needs to be handled at element level. The ability to assign
unique names to locally or externally defined datatypes that can be
referenced from attribute definitions is very powerful, but without the
ability to subset/supplement the referenced sets in specific places in the
model, or within specific instances of messages, the power of this
functionality will be limited in practice.

I am sure you have given some thought to these issues already, but until you
make such thoughts public little can be done to promote the use of XML
Schemas as a tool for electronic data interchange between businesses.

Martin Bryan
Technical Manager
The ISIS European XML/EDI Pilot Project

Received on Monday, 27 September 1999 08:55:23 UTC