Re: Units of Measure

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

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

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

Let me start by making a distinction between two types of code sets. I define "static code sets" as code sets that once agreed on in the ebXML equivalent of a Message Implementation Guideline, will not change during the lifetime of the relevant contract. I define "dynamic code sets" as code sets that are anticipated to change during the lifetime of a contract.

Let me then remind you that our goal is to automate the creation of XML Schemas for defining e-business processes. Note that I deliberately restrict myself to schemas at the present moment, and that I presume that a code set will be defined in a manner that is conformant with an XML Schema. Therefore I presume that the code set will be formally defined along the following lines:

<!simpleType name="ExampleCodeSet" base="xsd:string">
 <enumeration value="MTR">
    <annotation>
       <documentation xml:lang="EN">Meter(s)</documentation>
       <documentation xml:lang="FR">Metre(s)</documentation>
       <documentation xml:lang="RU">Schotchik</documentation>
    </annotation>
</enumeration>
<enumeration value="IN">
    <annotation>
       <documatation xml:lang="EN">Inch</documenation>
    </annotation>
</enumeration>
...
</simpleType>

Note also that schemas should only need to be exchanged once, at the beginning of the contract. They are therefore local resources, and should not need to be called from a remote machine as suggested by yourself and Arofan.

Where does the distinction between static and dynamic code sets come into this picture? A static code set can be embedded directly into the schema so that it is always available for consultation at both ends of the process. A dynamic codes set, on the other hand, will need to be externally referenced from the schema using the xsd:import element. This requires that the relevant resource needs to be called each time the schema is invoked, either from a remote source, or from a local copy of it, or from the memory cache if the rules associated with it state that the currently cached values are still in force.

So, I'm afraid, there is no need to invoke XML Links - XML Schemas will have everything we need and, because they are defined using XML, we can reference them from within our stylesheets using XML Path statements to an alternative resource (the schema), which should always be locally available. The only place time problems are likely to occur is when you need to reference something that is part of a dynamic code set. Then you automatically have a price to pay for ensuring that the latest version of the data is being used, and there is no way around the necessary delays involved.

On a lighter note, you comment that:

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

Whilst the gas-supply-chain-industry may want to bill in MBTU I pray to God that they do not try to impose the same unit of measure on domestic gas bills. (Mine is quoted kilo-Watt-hours with conversion figures given in MJ/m^3 and cubic metres). This highlights my earlier point that measurement units are application specific, and should not be defined as a single global set.

Martin