Re: English Language Tags

[Sandy Klausner <klausner@coretalk.net>]

Title: 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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
>  
>