XML Syntax/Semantics

["Miller, Robert (GEIS)" <Robert.Miller@geis.ge.com>]

There has been little if any discussion to date in TR&P on XML
syntax/semantic construction, which seems to be one of our responsibilities
to define.  It is a topic in which I have much interest, and is a source of
considerable concern to our client base due to its potential to impact
interoperability.  My personal observation of several existing consortium
attempts to define XML representation of business data is that they assume
all parties will use only the syntax/semantics they define, in which case
interoperability is a non-problem.

Of course, ebXML could make the same assumption, though surely that would
short-circuit the intent of the interoperability requirement we agree
exists.  Clearly ebXML must support interoperability between traditional EDI
and ebXML-based EDI, another stated goal of ebXML, and among multiple
nationalities whose native language differs.  Such support requires keen
attention to XML syntax/semantic detail.  It is not acceptable for example
to simply equate 'tag names' (XML or otherwise) in two systems and assume
the intersection represents the interoperability domain.

IMO, there is a pressing need to:

1) Adopt the use of unique semantic ID's for each semantic information item.
2) Support multiple name-owners for such semantic ID's, in recognition of
the current absence of a single registry source for such ID's
3) Require the identification of the semantic ID for each semantically
distinct information item in a conformant ebXML document.  
4) Specify common semantic attributes that associate to a semantically
distinct information item, and specify the XML representation of those
common semantic attributes.
5) Specify the means by which semantic ID's are conveyed through the XML
syntactic constructs we define for ebXML messages, and the means by which
the semantic attribute values associated with the semantic ID's are
conveyed.

I offer some recommendations with respect to these needs:

1) Require in the ebXML DTD/Schema for each XML element the definition of a
Semantic ID attribute, suggested attribute name being 'ID' in the ebXML
namespace (or schema namespace when/if the W3C Schema work group should
choose to define such an attribute.)
2) Define the semantic ID value as consisting of an owner part and an
identifier part, akin to the definition of XML element names which use the
NAMESPACE capability.  Note that the content of an XML attribute is not
subject to XML NAMESPACE interpretation;  we must define the syntax rules
for construction of Semantic ID's.  I would point out that the XML syntax
rules seem a good choice, as they provide both a shorthand representation of
ownership and a URI owner identifier.  As we define ebXML documents as part
of the ebXML infrastructure, we may need to specify ebXML as owner and
assignor of some semantic ID's for XML elements we define, at least until
such time as more formal naming agencies adopt and formalize semantic ID's.
3) An XML document which includes some information elements for which no
source of semantic information is available would seem to me incomplete.
4) The W3C Schema work group has done some work in this area, defining for
example type and length/range attributes.
5) I recognize that a set of 'semantic' attributes could be defined and
populated in an ebXML DTD (or Schema).  But its presence there may result in
unneccesary repeated processing costs.  I suggest that such information be
made available instead through a query process using the Semantic ID and any
supplemental keys such as document source/version as may be appropriate, on
a demand basis (Big Schema / Little Schema so to speak).  The semantic ID
for simple XML elements can be initialized in the DTD/Schema.  Code List
elements are a little more complicated as each code value represents a
unique semantic element in the context of the code list element of which it
is a value.  There may also be good reason to represent some code list
entries as individual XML elements in lieu of or in addition to their
representation as values of a code list element.

Cheers,
       Bob