RE: English Language Tags

[John McClure <hypergrove@olympus.net>]

Title: Re: English Language Tags

 

-----Original Message-----
From: Sandy Klausner [mailto:klausner@coretalk.net]
Sent: Wednesday, January 31, 2001 10:37 AM
To: John McClure; Ebxml-Core@Lists. Ebxml. Org
Subject: Re: English Language Tags

JM: You mean for the SAME semantic component. Are you saying that someone thinks one name is better than another, after the other one has lots of software programmed to it? In standard XML though, an element-type's namespace qualifier does point at an element's definition, and its stated inheriting-relationship -- that certainly give software adequate information to understand what's going on, and to react accordingly.

SK: Any particular component should be controlled by a single authority grounded in a domain community. The community decides if a semantic component's user visible name should be updated. Any third-party discovery and usage of that semantic component would see the most up-to-date natural language name (within their foreign language or dialect) without effecting the underlying machine reference.
 

JM2: This does tend to happen in a natural way -- I should know, as the architect of the Data Consortium Namespace (Candidate Standard). The definitions of the names in our namespace are based upon both an XML Schema and an RDF Schema document, and it is incumbent upon me to be as responsive as possible to the DC community. Each version of these documents is referenced by its own URI. The URI is referenced in the instance document using standard W3C conventions for XML Namespaces. I see nothing broken with XML Namespaces that is fixed by UIDs.

 
JM: I honestly don't see this ever happening. Rather, if it is to be renamed in a different release/version of the same or different namespace, the new element-type (with the new name) inherits from the old element-type, referencing the old element-type's namespace URI. Software can understand that!

SK: Software can understand that, but humans can't and it is called spaghetti code. Why create a code branch when the delta is only a name clarification (syntax) and not a meaning (semantic) change. 

 

JM2: Hmm, I look at it differently maybe. Within the code, a UID is really not much more significant than the value of the pointer to a meta-data object that is a property of the object represented by the element, an object incidentally that hides all this spaghetti code you perhaps think I advocate. 

JM: Maybe you're interested in seeing a distinction between an element-type name used during exchange between software programs and the display string(s) seen by an end-user -- that probably could be handled by XML Schema, although I am not an expert...

SK: This is exactly the point. The ebXML initiative is all about global-scale collaboration between people first before machines. Any  method that promotes user understanding of complex information space should be considered to assure successful deployment. As far as I know, XML Schema has no specific machinery to gracefully achieve this infrastructure functionality. 

 

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. 

JM: Hmm, although not an expert in XML Schema, I'd strongly suspect that multiple languages can and should be handled using the global 'xml:lang' attribute.

SK: Another XML extension afterthought, perhaps, but will it scale?

JM2: Aren't you agreeing above that this issue of labels for element-type names is a user-interface requirement, i.e., one secondarily important to the central mission of creating a document interchange protocol? It's certainly fine to have this requirement -- in fact, the DCN defines the label attribute for just this purpose  -- but note that the UI reqt is handled by the instance element itself, not by a lookup in some registry somewhere. Anyway, I find it annoying that you scoff at xml:lang.

  
JM: The mechanisms envisioned by XML Namespaces (W3C Technical Recommendation #2) and XML Schema certainly seem adequate -- perhaps not perfectly, but certainly "good enough" -- what's broken about it that UIDs would solve?

SK: This ebXML challenge remains to bolt all these technologies together. UIDs are just one small aspect of a much greater problem. The winning solution needs to integrate many ideas together. So this is not so much an issue of what specific problems would UIDs solve.
     
Sandy

From: John McClure <hypergrove@olympus.net>
Date: Wed, 31 Jan 2001 09:45:26 -0800
To: "Ebxml-Core@Lists. Ebxml. Org" <ebxml-core@lists.ebxml.org>
Subject: RE: English Language Tags

-----Original Message-----
From: Sandy Klausner [mailto:klausner@coretalk.net]
Sent: Wednesday, January 31, 2001 8:32 AM
To: William J. Kammerer; ebXML Core
Subject: Re: English Language Tags

> From: "William J. Kammerer" <wkammerer@foresightcorp.com>
> I see no advantage these unintelligent identifiers have over a natural language vocabulary used to build semantic components (read: BSR).

William:

There are several UID advantages for building semantic components (elements). A semantic component identified by a natural language mark-up tag is assumed to be immutable.

Can I substitute (element) and read this as "an element whose identifying 'name' is composed of intelligble text characters is assumed to never change". Personally, I think that's a good thing -- because the reality is that you want to always get at the definition of the element using its name, i.e., its relationships with other elements; and information about its properties and its constraints. A given namespace cannot have multiple definitions for a given element-type identifier, so a namespace URI plus an element-type name will always get one to a unique, relatively-stable, definition.

This fundamental characteristic is critical to third-party components that need to maintain reference to the semantic component source.

Yes, third parties need to be able to look up the definition of an element's element-type.

You state that mark-up is for programmers who invent these tag expressions. As a domain is better understood over time, the original programmer (and even the domain expert) may realize that there is a more optimal natural language descriptor for a semantic component.

You mean for the SAME semantic component. Are you saying that someone thinks one name is better than another, after the other one has lots of software programmed to it? In standard XML though, an element-type's namespace qualifier does point at an element's definition, and its stated inheriting-relationship -- that certainly give software adequate information to understand what's going on, and to react accordingly.

The problem is that a natural language mark-up tag cannot be modified once the semantic component is made public.

I honestly don't see this ever happening. Rather, if it is to be renamed in a different release/version of the same or different namespace, the new element-type (with the new name) inherits from the old element-type, referencing the old element-type's namespace URI. Software can understand that!  

If on the other hand, if the semantic component had a base identity expression grounded in an immutable UID, then its owner could update the natural language expression without effecting third-party references.

Should the owner update the properties of the element-type, without changing either the name or the URI mapped to its namespace identifier, then its owner would be making a mistake. Maybe you're interested in seeing a distinction between an element-type name used during exchange between software programs and the display string(s) seen by an end-user -- that probably could be handled by XML Schema, although I am not an expert...

This dual expression approach also has the advantage of allowing foreign language and foreign dialect extensions.

Hmm, although not an expert in XML Schema, I'd strongly suspect that multiple languages can and should be handled using the global 'xml:lang' attribute.

A foreign dialect is a synonym used to characterize for party peculiarities or special circumstances. This dual expression approach could also apply to attribute components as well.

The mechanisms envisioned by XML Namespaces (W3C Technical Recommendation #2) and XML Schema certainly seem adequate -- perhaps not perfectly, but certainly "good enough" -- what's broken about it that UIDs would solve?


Sandy Klausner
CoreTalk Corporation