[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: English Language Tags
Please read the following comments: ITEM ONE: John McClure wrote: > > Hello David. > Like Sandy, this is my last word on this, promise! You seem to suggest that > creating UIDs are out-of-scope for the W3C, and that is why they haven't > done it. I am suggesting to the contrary that they already created a set of > mechanisms to achieve what you want -- XML Namespaces and XML Schemas. " ITEM TWO: > | JM2: Well, if it's not there, then create it! It's not that hard you > |know! The point is to stay on the same field as the rest of the world -- I > |don't see a huge effort in the W3C to create a registry of data element > |UIDs > |for their OWN elements because XML Namespaces and XML Schemas are > |adequate." >>>>>>>> FACTS: One thing that seems to have gone completely missing from this logic is the fact that XML namespaces are no adequate. A namespace attribute value points at nothing meaningful!!! An XML NAmespace does not tell a parser anything useful either. An XML Namespace does not provide any semantics about an element. Read on: The only thing an XML namespace value does is allow a code writer to build a handler routine which can tell an application that the domain of an element is different from another element based on the fact that the namespace attribute is unique (ie - has the domain url in it). There are no rules saying that urls have to point at anything which provides semantic rules. UID's, as contemplated in ebXML, will have that mandate. The UDI's also have to have a mechanism for resolving the UID to a Registry item. WHile there are no implementation details to constrain this in the current TA Spec, we have discussed using some of the work done by Michael Mealling (re: using URN's and an open field in DNS) to create a location neutral reference for locating the reference file. For ebXML Core Components, the reference file likely should be a place to reference semantic associations accross multiple taxonomies as well as provide usefull meta data about the component. Namespaces have no such mandate to provide any of this, therefore are completely useless for this task. Many have argued that maybe Namespaces should point at something useful (a notion I personally share) but no effort has been launched to my knowledge to say what. 'nuf said. Duane Nickull
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC