RE: Units of Measure

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Martin,

Your reference to XPATH convinces me we are not on totally different
wavelengths.  Responses imbedded.


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.

MILR: 
Not all data to be exchanged will be defined by Core Components.  Not all
Core Components that could be used will be used in a given user
implementation.  I don't argue that ebXML must glue these off-by-n's
together, but I do argue that ebXML cannot ignore them.  We have to at least
offer some clamps and glue formulas that they can use on their own to help
such disparate systems interoperate.

I concur that XLINK et al should/will provide the path to the metadata.
Some day before this project ends we need to settle on how (in XML) the
metadata is to be represented, and some mimimal requirements on metadata
content. And we need to agree in some detail on how the metadata will be
located, so that processors that need to find it know which link to pursue
to get to it.

>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")

MILR: Agreed, provided we settle on how XLINK/XPATH is going to be used. One
nice thing about XLINK is that one can tack the linkages on without
modifying the source DTD/whatever, if one cannot modify the DTD/...  Sounds
ugly, but it sure beats not working at all in the absence of a translation
friendly DTD/...

> 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.

MILR: I did not mean to imply that attribute values would include explicit
namespace qualifiers.  I expect the unqualified values would be prepended
with a namespace qualifier in constructing the (XLINK/XPATH) pointer to the
metadata.

Perhaps that namespace qualifier can come directly from the owning data
element, perhaps not.  Consider a DE containing a codelist attribute, whose
codes include the X12 set and the EDIFACT set (and perhaps some 'readable'
code values). There could be 'collision' of code list values between X12 and
EDIFACT, and it is likely in that case that the same code value will
represent different semantic values.  Some solutions include using another
attribute to specify from which code list the value was taken; using two
DE's that encompass the same semantics, with each DE referencing a different
code list source; prepending each code value with a preface (but not
technically an XML namespace) that infers the code list source.

BTW, my text was referring to using data element names (e.g.,
BreakpointPrice) rather than values (attribute or DE) to represent semantic
entities we represent in standards like X12 as codes.

As to code set restrictions, they are probably relative to a subclass
element that is industry specific.  For instance, in the Gas Industry,
volume might be measured in million cubic feet, or in (!!!) million BTU.
Obviously the latter code is not a volume qualifier, but it is a value that
can be used to compute volume where the BTU/CuFt is a known value for a
given well-source.  (Don't ask me why MBTU might make business sense to the
GI, I don't know why!  Apparantly, it just does.)

Martin Bryan