Re: English Language Tags

[Sandy Klausner <klausner@coretalk.net>]

So all we need to do is define our own stake, drive it into the ground, and
defend our turf. Sounds straightforward to me!
Sandy

> From: John McClure <hypergrove@olympus.net>
> Date: Wed, 31 Jan 2001 17:44:29 -0800
> To: "Ebxml-Core@Lists. Ebxml. Org" <ebxml-core@lists.ebxml.org>
> Subject: RE: English Language Tags
> 
> OK, last response, coz I'm sure this is getting tiresome to the list!
> 
> Duane says:
> |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.
> 
> As a standards-making organization, you DO have the power to say that,
> within THIS domain, the URI referenced by a namespace identifier IS
> meaningful. The fact that the W3C did not pre-ordain what the URI points at
> does NOT make them useless, rather, it is a demonstration of their
> adherence to a chosen functional scope, empowering organizations such as
> yourselves to make the call about the semantic interpretation of the
> namespace's URI, in a manner sensitive to the context of your documents.
> So, I suggest you stop waiting for someone else to "launch an effort" to
> standardize a thing that is not to be standardized globally, IMHO.
> 
> David says:
> |Namespaces are simply a PREFIXING mechanism to avoid clashes
> |of use between included XML content.  Classic example is <company>
> |
> |I've used <company> in my shipping address elements, you have used
> |<company> in your billing party elements.  Its not the same thing, nor
> |is the data the same.  Therefore you need <shipping:company> and
> |<billing:company> to get out of the empasse.
> 
> If the complete code is:
> <Root xmlns='uri0' xmlns:shipping='uri1' xmlns:billing='uri2'>
> <shipping:company/>
> <billing:company/>
> </Root>
> 
> then to the parser, it is
> <uri0:Root>
> <uri1:company/>
> <uri2:company/>
> </uri0:Root>
> 
> Each name is prefixed in effect by a URI. As Duane notes, it is important
> to know what the URI is pointing at. If by agreement it is pointing at an
> XML Schema, then all the information that is going to go into the Registry
> could just as easily go into a company's XML Schema document which is
> pointed at by the URI. Such an approach -- given or despite my usual
> caveats about fully understanding W3C intentions -- conforms with the
> decentralized database architecture that is the Internet.
> 
> |Now - the W3C was solely concerned with name clashes.  We are
> |concerned with business semantics.  Just becuase you know its
> |called <company> - so what?  You will need the specific UID to
> |reference the complete definition within the Registry.  A query
> |based solely on the word 'company' would garner dozens of hits within
> |the registry and lead to you not being able determine the exact
> |definition reliably.  Same thing for the excellent 'Stock' example
> |cited earlier.
> 
> Hopefully I have demonstrated that the definitions for the two <company>
> element-types are independently retrievable, and are uniquely identified
> within an XML data-stream. In the DCN, we use the 'name' attribute, which
> contains a 'qualified name', i.e., one that is qualified by a namespace
> identifier, to point at an RDFS dictionary where similar information as
> that I understand is in the Registry, is located. A company can have their
> own dictionary, and can reference multiple dictionaries within a single DCN
> data-stream.
> 
> Gotta go, and I hope that these remarks are helpful to you!
> Thanks and regards,
> John McClure
> Hypergrove Engineering, Inc.
> 211 Taylor Street, Suite 32-A
> Port Townsend, WA 98368
> 
> 360-379-3838 (land)
> 
> |-----Original Message-----
> |From: duane [mailto:duane@xmlglobal.com]
> |Sent: Wednesday, January 31, 2001 1:43 PM
> |To: John McClure
> |Cc: Ebxml-Core@Lists. Ebxml. Org
> |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.
> |
> |
> |'nuf said.
> |
> |Duane Nickull
> |
> 
>