Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Why SAX needs namespace support
 david@m... wrote: > Michael.Kay@i... writes: > > > > "Namespaces in XML" seems to be going down this path as no > > > one will admit that it is a massive failure. > > > > I agree with you that "Namespaces" is technically inelegant, it > > also has the problem of being incompatible with a lot of other XML > > things. Unfortunately, though, I think it is doomed to succeed. > > I agree. > > I also object strongly to the inelegance of attribute-based namespace > declarations and to the unnecessary complication of local namespace > scoping (which, like optional external-entity expansion in XML 1.0, > tries to solve a straw-man problem that turns out not to exist in any > serious way anyway). I never quite understood why attributes are used for namespace declarations as well. I also agree with the Implementing namespaces in an XML parser is a trivial task, but dealing with namespaces at the application level is a totally different story, especially with this namespaces scoping stuff. How do you deal with namespaces in the DOM? I mean if you copy a node here, and insert a node there, this entire namespace scoping stuff gets all out of whack. Of course you could say "well the application programmer will just have to deal with that" and then the application programmer would say "why should I deal with it at all". As someone who has written an XML parser, DOM implementation, XSL processor, and a client-oriented application that I consider to be in the "major" category, I find XML to be very useful as an alternative externalization format to Java Object Serialization for Java objects. All of what you might call "business objects" (this is not a business application but a consumer application) can be expressed in Java Object Serialization (I use this for over the wire object state transfer) or XML (I use this format mostly for spitting out object state to a file since XML is simple enough that many of the properties of the objects can be edited manually as well as the fact XML is much more user friendly for other developers to interoperate with than the binary streams which come out of using Java Object Serialization). These "business objects" are not hardcoded in any particular hierarchy and to support building an XML element tree (effectively elements are mapped directly to these business objects) I have had to create my own Java <--> XML architecture because nothing out there is suitable for my needs or the needs of developers who will hopefully be working with this client application. OK the point is, namespaces as they are currently defined I feel make practical use of XML in this regard too difficult for developer novices to deal with. I would not even have wasted a year of my life on XML if I thought that its goals were targeted exclusively for the browser centric world because that world does not apply at all to how I am using XML. XML 1.0 did the job. Namespaces do not. Of course I could just elect not to support namespaces at all in this application environment, but somewhere down the line, developers will need some sort of namespaces mechanism here. I also don't want to have to develop some namespaces mechanism myself or else use a better alternative that someone else has developed hat perhaps I feel is more suitable to component oriented applications and then have to essentially badmouth the W3C by essentially saying "well they have no clue when it comes to the developer community at large". That does not make me look good, but what else can I honestly say when someone says "well why don't you use "Namespaces in XML" for this application environment. I can tell them the truth or I can make something up. Plain and simple "Namespaces in XML" looks ugly, feels ugly, and therefore is not practical at all for lots of applications that need to be simple, yet need some namespaces mechanism nevertheless. In this regard "Namespaces in XML" is already a massive failure because it is limiting the target audience of XML altogether. I am a huge fan of XML like probably everyone else on this list, but "Namespaces in XML" has dampered my enthusiasm for this fledgling technology. > That said, my customers couldn't care less -- they need the ability to > provide globally-unique names that their software can disambiguate > from other people's names, and for that purpose, XML Namespaces turns > out to be useful far beyond initial expectations, warts and all. Yes your customers, but that is in the document world. You are right they probably could care less. Perhaps I should scrap XML support altogether and stick with just Java Object Serialization. I seriously doubt that will ever happen because I can see that XML (minus namespaces) is the perfect solution to storing object state in a human manageable context. XML right now is simple enough that non-programmers can edit an XML file manually. Add in all of these computer-science geekified additions to XML and a lot of people on this list who are authors of XML books will find their book royalties dwindle to nothingness. > The nicest part is that the utility of namespaces does not depend on > any fancy, yet-to-be-written schema support for compound documents -- > for an enormous number of applications, it's enough just to be able to > identify a globally-unique name. Yah, but try and use namespaces with dynamically built DOM trees (or any other object tree implementation that maps to XML). It can be a major pain in the rear if you have multiple components that have no knowledge of each other and whose externalized content is merged into one XML document tree. Just think of the nightmares of managing namespace defaulting if you are merging a lot of abstract content (perhaps E-Commerce transactions which are converted to a DocumentFragment). Of course if I am living in the browser world, then none of this matters because in the browser world everything is one big document and hardcoded into some visual context whether it be HTML or the forthcoming Formatting Objects of XSL. > Despite my initial pessimistic predications (some of you might > remember that I also predicted the imminent death of Linux back around > 1992 because of its monolithic kernel architecture), I am now > confident that namespaces will succeed, and want some kind of > namespace support in the next version of SAX. I agree here, but I think namespaces will only succeed in the browser world. Most people are using XML for just HTML related stuff anyways, so for the short term future "Namespaces in XML" will do the job. Try using XML with namespaces for anything else more sophisticated and you might as well forget it (especially for E-Commerce). But yes, "Namespaces in XML" may in fact flourish in the web browser world. Nevertheless, we need to make sure that support of "Namespaces in XML" is as painless as possible to the application developer. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
