[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: English Language Tags
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.
Powered by eList eXpress LLC