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.  

I'm afraid what follows suggests we are not! It also highlights a
misunderstanding that may have occurred with Arofan's untimely rejection of
the concept of external sources for multilingual labelling.

MILR: I still believe we're closer than you think!
You say "Our goal is to automate the creation of XML Schemas for defining
e-business processes".  I agree.  And I agree with most of your text on how
the Schema stuff will be downloaded for use.  We seem to have a small
discrepancy however in what the Schema will contain.  

I observe that "automate creation of XML Schemas" implies a generation
'source', such as RDF/XML (my current favorite) derived from a combination
of UML and BSR-like analysis of the metadata aspects of the desired
information exchange.  I both expect and need to find a reference to the
'source' in the Schema, as the 'source' will/should contain more
meta-information than will appear in the Schema.  I say 'will/should'
because the extra information does not pertain to the validation of an
information exchange instance.  But this information does pertain to the
establishment of data transformation/application integration.  So
this is the 'link' I refer to in my earlier messages.  I would not expect it
to be traversed each time I processed an information exchange.

Your distinction between static and dynamic code sets is also important.
But I don't support your suggestion that xsd:import be used to suck the
dynamic list into the schema.  Rather, for each such coded element, I
support:
  Provide access (in the schema) to a dynamic code validation process.  The
process could/should keep a local table of known values.  If invoked, when
it encounters an unknown value, it does a code lookup on the code source
site.  The decision when to invoke the routine is left to the recipient.

Cheers,
         Bob