OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 
>boo hoo. 
>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>