Re: Units of Measure

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

Arofan

When you use four letter words such as Java in your message you should not expect me to


> Woah, Martin!

When you show a red rag to an old bull in a fragile goods shop (me in the EDI world!) you must expect him to instinctively charge you:-))
 
> You seem to have gotten me wrong somewhere along the line!

Hopefully, but some of the claims you are making are general enough to rile an old timer like me.

> I do not reject the idea of making code-lists available for referenceing -
> quite the opposite. My point was that XSL isn't great for doing run-time
> translation of code-lists into something human-readable for presentation in
> a browser.

You seem to forget two things. One is that I never mentioned XSL - in my original message I said XPath. XPath is the glue used to link all XML applications. The second is that XML Schemas are another XML document. To link an XML message to an XML Schema the in-built route is XPath - anything else is an unnecessary, non-generic, external interface. You brought in XSL with claims that are patently untrue.

> As currently existing, schemas are wretched for doing cross-language
> equivalency (a "language" is not something that can be validated as a
> property of any data set by a parser) 

Rubbish. xml:lang is a built in property of XML that can identifiy any language used on this planet (and a few, such as klingon, that are supposedly not used on this planet), and which can equally well be used in an XML Schema (or any variant thereof). Remember that the following is valid, AND GOOD, xml

<!element Nom xml:lang="FR" type="PersonName">

>but obviously we need a good mechanism
> for doing this. 

If by we you mean ebXML then you are wrong. XML ALREADY PROVIDES AN IN-BUILT ANSWER. Please, lets not re-invent the wheel - it took a lot of effort to design it correctly for the international market.

>personally, and for performance reasons, I think java
> applications make this easiest and most efficient

NO, NO, NO!!   Please do not use that four letter word. Unlike HTML, XML has no built-in mechanism for exchanging or referencing Java code/scripts. ebXML should not have to rely on extensions to XML that will make applications specific to ebXML. It should be designed to work with any XML-aware toolset, not just with those designed to e-business. If we cannot manage to do that we have FAILED, and we will be in the same boat as EDI, requiring customised tools that are only relevant for a narrow range of applications. This will not solve the key problem, that of getting SMEs to adopt electronic commerce.
 
> I don't think I fundamentally dis-agree with you on this point, though, nor
> on the utility of referencing code lists. The way I see this, a code-list
> would be published in some standard way that would allow for an application
> to render it in the appropriate syntax, whether that was schema or something
> else.

You are confusing two things again. What you are talking about are the UN definitions of the Core Component Code Sets, which need syntax independent full definitions in multiple languages. What I am talking about is the usually very small subset of this code set that are needed in a Schema that is to be used to control the exchange of messages between two or more trading partners according to some pre-agreed contract (the equivalent of a message implementation guideline). My subset is a "restriction" on the UN maintained master list. It normally only requires to have details of one or two language conversions per code. This subset is small enough to be handled efficiently by a parser. Remember that the Schema needs to be "compiled" before it can be used. In this compiled form the code lists will, as far as the local application is concerned, be even more efficiently coded than Java (damn it, you've got me using four letter words!!).

> Another place where I think we agree is that generally speaking, any static
> resources should be down-loaded and stored locally - all systems that I am
> aware of do this for performance reasons. Dynamic resources are also cached
> if this makes sense to do - do you need to update a code list more than once
> a day? There is a case for needing run-time downloading when you encounter
> schemas that may be extensions of ones that are stored locally - this will
> depend on the trading scenario.

That's why I mentioned the use of timed caching for external resources. These are normally application dependent, rather than UN controlled, and should be generated by querying databases, with an external mechanism regularly checking whether the cached data is up-to-date that is independent of message processing,

> I just wanted to make sure you didn't mis-understand me, as that appears to
> ne tha case here. 

No, its just that I'm used to arguing programmers out of using program-language specific procedures and convincing them that declarative techniques are just as efficient in the long run!!! (Don't take my jibes too seriously Arofan - I have tremendous respect for you.)

> In terms of codes and element names in general, I agree
> with harmut's proposition that we have semantic-free identifiers for all of
> the core components and data types, and then instantiate them in
> semanticaly-meaningful ways according to specific languages. 

Sorry, I cannot agree here - semantic-free identifiers = extended and long on-going maintenance costs for code. Lets stick to "semantic-agreed identifiers" which are based on the common denominator of programmers - bad english-based acronyms such as MTR and IN. This is reality, not science fiction. Who remembers how a 137 date format differs from a 102! Arghh!! I know the difference between a DateTime and a Period, and most programmers would as well, even those whose native language is not English.

>This will
> enable us to leverage good semntic labels in all langusges, and I think that
> a transformation across these could fairly easily be built in the way that
> you suggest, or by using more traditional means.

Ah, now you have come to the nub of the question - what we need is transformations. AGREED, wholeheartedly. What we need is a standardized transformation mechanism that all ebXML applications can agree to support consistently. What we need is, surprise, surprise, something called XSL Transformations, which uses XPaths, can obtain information from XML Schemas as easily as from ebXML messages, can access other XML resources whenever it can't find what it needs in these two well known resources, and can combine all these, all-be-it at slower-than-light speed, into a single whole that can be used for subsequent processing. We do not need yet another external processor written in Java that cannot be integrated with every ebXML application.

So the answer to the question of the universe, when ebXML is added to it, is XPath rather than 42:-)

Martin