Re: Units of Measure

[Martin Bryan <mtbryan@sgml.u-net.com>]

Bob

> What worries me is the thought that someone will use a code list (e.g., an
> X12 code list) as an attribute value to an XML element; not provide a means
> to get at the semantics the code represents (the XML representation of the
> semantics of course), and think that the job is done.  

Hopefully the way we are defined Code Sets in the ebXML Core Components will prevent this. One of the reasons for storing these as XML is that we can then address the definition using XPath as part of an XSL Transformation.

>Yet I frequently see
> code lists represented without thought given to how the recipient processor
> is going to be able to identify the semantics associated with the code
> value.

Not a problem with XPath - you can look for an element of a particular type (e.g. Value) with a particular content (e.g. "MTR")

> I forgot to mention it, but code list values also (conceptually) reside in
> (rather restricted) namespaces.  That will likely keep to a minimum the set
> of semantic code values an implementation might choose to represent outside
> an attribute list, lest they risk name collisions in whatever namespace they
> are defining their messages.

Unfortunately namespaces only apply to element and attribute names safely. There are examples of their use as attribute values, but for the life of me I cannot see how these can be tied to the namespace processor in any parser (some may support it, but most will not). There can be a case for namespacing the attribute defining the units, e.g. <length UN:units="MTR">15</length> but in most e-business applications you want to restrict the Code Set in a particular context (e.g. to stop PoundsPerFoot being used for length), so the real constraint is local to the element -- hence <length units="MTR"> is safer as the meaning of the units attribute is unique to the length element, rather than part of a wider global set of values.

Martin Bryan