RE: Enlightenment via avoiding the T-word

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

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>
>