RE: Enlightenment via avoiding the T-word

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

That's an interesting point. Giving unique name to local elements looks to
me pretty much as a task a validator could perform, the result being shoved
into a <i>kind of</i> PSVI. Indeed, to me, a good candidate for a unique
name would be the canonical XPath of the local element in a valid document,
or better, the canonical XPath of the local element relative to the global
element containing it.

If you give an automatically generated unique name to a local element (like
Java compiler do with inner classes, be it anonymous or not), I suspect our
template :

<xsl:template match="person/name"/>

(name being a local element defined in the person global element)

would become :

<xsl:template match="__unique__person__name"/>

Or something like that. However, in the second sample, in which we wanted to
process the buyer's name and the seller's name in different ways, the
template :

<xsl:template match="buyer/person/name"/>

Becomes :

<xsl:template match="buyer/person/__unique__person__name"/>

or :

<xsl:template match="buyer//__unique__person__name"/>

So, finally, what is the benefit ?

Regards,
Nicolas

>-----Message d'origine-----
>De : Fuchs, Matthew [mailto:matthew.fuchs@commerceone.com]
>Envoyé : mercredi 29 août 2001 20:13
>À : Nicolas LEHUEN; 'xml-dev@lists.xml.org'
>Objet : RE: Enlightenment via avoiding the T-word
>
>
>It probably comes as a surprise (especially to Rick) that I essentially
>agree with him about the need to use namespaces to distinguish 
>among local
>names (although I've said it many times).  Where I disagree 
>with Rick is in
>the need to shove these namespaces in everyones face as a 
>requirement for
>good XML.  This is the kind of thing that can be handled 
>automatically in a
>very consistent way, allowing people to write documents as if 
>they weren't
>there, if one expects to validate and retrieve that information, like
>attribute defaults, or write documents with that information explicitly
>spelled out, if one doesn't want to validate.  Similar to that 
>way that the
>Java compiler gives names to all the anonymous inner classes 
>people write -
>you don't need to name them in your Java source, but you can't actually
>execute a program without those names.
>
>There is no context sensitivity - everything has a single 
>name, but (just
>like default namespaces) you don't always need to see the whole thing.
>
>Matthew
>
>> -----Original Message-----
>> From: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com]
>> Sent: Tuesday, August 28, 2001 3:25 AM
>> To: 'Rick Jelliffe'; 'xml-dev@lists.xml.org'
>> Subject: RE: Enlightenment via avoiding the T-word
>> 
>> 
>> 
>> 
>> >-----Message d'origine-----
>> >De : Rick Jelliffe [mailto:ricko@allette.com.au]
>> >Envoyé : mardi 28 août 2001 11:27
>> >À : xml-dev@lists.xml.org
>> >Objet : Re: Enlightenment via avoiding the T-word
>> >
>> >
>> >From: "Nicolas LEHUEN" <nicolas.lehuen@ubicco.com>
>> >
>> >> Well I wouldn't be surprised that by adhering to the 
>> >"all-global" policy, we
>> >> would soon find our namespaces too small... Let's consider 
>> >this (somewhat
>> >> corny) "purchase" sample with local elements :
>> >> 
>> >> <purchase xmlns="http://foobar/purchase">
>> >> <customer>
>> >> <name>Nicolas</name>
>> >> <address>Paris, France</address>
>> >> </customer>
>> >> <delivery>
>> >> <mode>UPS</mode>
>> >> <address>Somewhere else</address>
>> >> </delivery>
>> >> <lines>
>> >> <line>
>> >> <!-- duh, will this wake up Echelon :) ? -->
>> >> <product>
>> >> <name>ACME Explosives</name>
>> >> <price currency="dollar">2000</price>
>> >> </product>
>> >> <quantity>200</quantity>
>> >> </line>
>> >> </lines>
>> >> </purchase>
>> >
>> >Sorry, where are the local types in this?   You need to 
>> >provide a schema
>> >or some clearer indication, otherwise I cannot follow the 
>> >example. But it
>> >doesn't seem very convincing, from what I can follow: to say that
>> >having "mode" and "mode" with different meanings is preferable to
>> >having "mode" and "deliveryMode" is baffling. [Of course 
>context will
>> >be useful for figuring out the meaning of an element when you first
>> >come to it; but if the meaning is different depending on 
>each context
>> >(without warning) there is no way to synthesize the meaning from
>> >the multiple contexts.]
>> 
>> In the first case I get the delivery mode by the XPath expression
>> /delivery/mode/text() ; in the second case 
>> /deliveryMode/text(). It is the
>> same when I'm reading the document. What is baffling in this 
>> ? I don't see
>> any difference in terms of readability or processing power required.
>> 
>> However, I see that in the second case, I'm stuffing names that are
>> semantically bound to a context (even deliveryMode is bound 
>> to the context
>> of delivery conditions, it can't be used alone) in the global 
>> namespace.
>> This will sooner or later clutter my namespace and prevent 
>> the readability
>> and maintenance of the schema and documents.
>> 
>> >On the concrete point of not wanting to use different 
>> >namespaces because it
>> >complicates things, namespaces are the W3C technology for preventing
>> >name clashes and allowing modularization.  They are the 
>> >appropriate thing
>> >to use, if it is impossible to figure out alternative names. 
>> >If you don't want
>> >to use multiple namespaces, why even use one?
>> 
>> I WANT to (and I do) use them, but as context sensitivity is 
>> not a thing you
>> can do without, I think that forbidding local names, thus forcing all
>> element names to be unique in their own namespace, thus encouraging
>> unrequired namespace multiplication, for the mere purpose of removing
>> context sensitivity from element names, is overkill (like 
>> this sentence :).
>> Namespaces are really useful, but a context is also a nice 
>> thing to use to
>> prevent semantic collisions.
>> 
>> I just don't see what is the good side of all elements being 
>> global. This
>> won't make processing data more easy, as you HAVE to process 
>data in a
>> context-sensitive way.
>> 
>> It could certainly help building a global injection between 
>> element names
>> and t***defs or classes for lazy implementers of validators, 
>> but I'm sure
>> that the clever people who are implementing validators can 
>> handle the little
>> overhead of context-sensitivity (the injection would no more 
>> be global, but
>> context-sensitive, that's all).
>> 
>> >If your tools don't handle schemas with multiple namespaces 
>> >well, get better tools,
>> >don't foist PSVI on the rest of us :-)
>> 
>> My vision of PSVI (which may not be the W3C's one) is a piece 
>> of metadata
>> that is as important as the manipulated data. Maybe the W3C's 
>> PSVI will be
>> overkill, but such information is so precious that I can't 
>> wait having it.
>> Heck, even acceding to the DTD of a document in SAX or DOM is 
>> not easily
>> done !
>> 
>> >> Problem is, the only way to have both global
>> >> element names only AND achieve modularity and extensibility is to
>> >> extensively use namespaces, 
>> >
>> >Yes, if you want to reuse local names, you need as many namespaces
>> >as you have re-uses.  That's the way it should be: no local 
>names, no
>> >local types. If different columns in tables in DBMS have the 
>> >same name, 
>> >it is a mapping issue not something that should be needed by an XML
>> >schema language.  And if it makes auto-generated Java more 
>> >complicated, 
>> >boo hoo. 
>> >
>> >Cheers
>> >Rick Jelliffe
>> >
>> >
>> >-----------------------------------------------------------------
>> >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> >initiative of OASIS <http://www.oasis-open.org>
>> >
>> >The list archives are at http://lists.xml.org/archives/xml-dev/
>> >
>> >To subscribe or unsubscribe from this elist use the subscription
>> >manager: <http://lists.xml.org/ob/adm.pl>
>> >
>> 
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>> 
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>> 
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.xml.org/ob/adm.pl>
>> 
>