RE: English Language Tags

[John McClure <hypergrove@olympus.net>]

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
|