Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
 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@c...] >Envoyé : mercredi 29 août 2001 20:13 >À : Nicolas LEHUEN; 'xml-dev@l...' >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@u...] >> Sent: Tuesday, August 28, 2001 3:25 AM >> To: 'Rick Jelliffe'; 'xml-dev@l...' >> Subject: RE: Enlightenment via avoiding the T-word >> >> >> >> >> >-----Message d'origine----- >> >De : Rick Jelliffe [mailto:ricko@a...] >> >Envoyé : mardi 28 août 2001 11:27 >> >À : xml-dev@l... >> >Objet : Re: Enlightenment via avoiding the T-word >> > >> > >> >From: "Nicolas LEHUEN" <nicolas.lehuen@u...> >> > >> >> 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> >> > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
