Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Looking for an example of a name colliision
 (I'm playing catch-up on the list. Apologies). [Chiusano Joseph] >Here are several off the top of my head: >(1) "feet": > - One occurrence could be a string that contains the anatomical >condition of a foot, perhaps in a list of body parts in a doctor's form; >- Another occurrence could be a distance; Hello Joseph. The start of this post is a response to your e-mail but the rest of it is a rant against namespaces. Its not a rant against your post! As for the example of different occurrences of "feed". One word: CONTEXT The element structure of XML is a simple, elegant way of contextualising chunks of text. XPath etc. give you techniques for interacting with that context. The element context of XML is all you need to resolve the multiple occurrences of "feet" elements in your example. As far as XML tools are concerned, where is the "collission"? Does the collisson stop a WF parser checking well-formedmess? No. Does it stop an XPATH processor winding its way through the nodes? No. If you need to distinguish one element from another - regardless of whether or not they share the same element type name - you can use the element *context* to do so. The element structure gives you all the context machinery you need. Namespaces simple adds more context machinery. As pointless as it is complex. The extra context machinery is unnecessary and extremely counterproductive. It adds complexity in-your-face all the way through XML application development and XML interchange. Anybody who thinks this is not the case has a much better way of writing XML applications than I have (and is keeping the details to themselves to boot :-). Name collision lower down than application-level semantics is a myth. At the application level, you have the full power of the element context model to handle it. If you need to differentiate elements for interchange purposes, interchange XPaths along with the instance. What's the problem? Adding another context model - a complex context model at that - from the UnicodeWithAngleBrackets, right the way up to the application, is a really, really bad idea. Its also another dreadful example of more and more *stuff* being piled into XML without any apparent thought for how functionality can be modularised, pipelined and otherwise kept from exploding in our faces in one big fireball of complexity. The alternative to namespaces? XML + XPath. Why not? Lets explore it. All around me I see SAXes, XPaths, DOMs etc. etc. that are infested with namespace complexity. I see programmers all over the map pulling tufts of their own hair out. Programmers who strongly suspect that, in this case, the XML appointed emperor has no clothes, but are reticent to come forward and say so. There simply must be a better way. Sean http://seanmcgrath.blogspot.com 
|
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
|
|||||||||
