Re: English Language Tags

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by "William J. Kammerer"
>This markup-text dichotomy is a separate issue from using UIDs.  Even
after considering the contributions from UID proponents, I see no
advantage these unintelligent identifiers have over a natural language
vocabulary used to build semantic components (read: BSR).
<<<<<<<<<<

William,

The devil is in the implementation and this is largely subjective, 
but nevertheless important since these things critically impact
the implementation maintenance and adoption curve.

The advantages come from two areas.  One is integration into 
query paths and using the UIDs within
the Registry itself to ensure information referencing.  Xpath constructs
and versioning are more intuitive using the UID approach, but one
could argue that is subjective of course.

Then the other is one I'm surprised you as an old EDIr don't recognise.
Ability to re-use existing element codes from EDI dictionaries as UIDs
and allied with this - the inherent simplicity of assigning UIDs.

Contrast the CALS - UDEF approach - where you have to hire 
consultants to allocate the information model.   And then the man-years
that are wasted in committee deciding if   invoice.payment.date is 
better than  payment.date.Invoice  and mountains of similar busy work.

The busy work factor is the most compelling for a neutral construct that
is simple and unambiguous and allows people to use 
invoice.payment.date and payment.date.Invoice interchangably.  And
it even supports UDEF too - for those who have already sunk $millions
into that hole and want the save their investment.   Avoiding the 
re-tooling of existing implementations is another KEY factor here.

DW.