Cart
[Home] [By Thread] [By Date] [Recent Entries]
One thing which I find perplexing is that we are discussing how to add namespaces to XML when there are no real XML apps out there that I am aware of who have wrestled with this issue. In other words, despite everyone crying about standards bodies being too slow, perhaps in this case the WG is being too fast. Until real XML applications come out and provide their own proprietary uses of namespaces at the application level, we will all not have much of a clue about how application developers are using namespaces and how application developers have implemented namespaces. My initial understanding of namespaces was that it was a way of associating some particular element name in conjunction with a prefix of some sort to identify a UNIQUE form of data. In this sense, XML is more useful as a data container than as a document model, since a document viewer generally has some sense of how to render all of the elements that is presented to it. In Java at least, I had some creative ideas as to how to dynamically instantiate element handlers by class name. The class name would be constructed by using its prefix as a key to lookup the application specific package name plus any other prefix data for the class name and combining it with the element name in the document. In other words if I had a namespace prefix: java.awt and I had a replace value for the prefix: com.dais.awt.X If I had a namespace name: java.awt:Dimension I would get as a result the class name: com.dais.awt.XDimension which would likely be a subclass of java.awt.Dimension With the current namespaces proposal, it does nothing for me and I am having a very hard time trying to figure out if it will ever do anything for most applications. If you look at previous standards like OpenDoc, they generally failed because no one used them. For the particular app I have I have chosen to embed documents within documents instead of futzing around with all of this namespaces stuff and believe it or not it all works quite nicely. Part of the reasons for this are application specific (for example some objects are dynamically created and the content within a document can only be applied at this particular time) but nevertheless it works. All of this talk about extending DTD's and element type inheritance seems to totally ignore the question of possible implementation. An idea is just an idea until you something concrete behind it. XML has the years of success of SGML behind it, but this namespaces stuff has nothing behind it. That is why I plead for us all to go slowly with namespaces as there seems to be much disagreement about it now. Standards are usually built upon some sort of concensus. If a standards body uses a top-down approach to publishing standards, then they will lose a lot of respect really fast among the average ISV who likes a standards body pushing drafts down their throat (unless it is of the alcoholic kind) about as much as having standard shoved down their throat by some very large monopolistic ISV. The secrecy process that the W3C goes through makes me wonder sometimes if the W3C is simply a corporation responsible to its shareholders (those who fork over the big bucks to become members) rather than a real standards body for the betterment of computing. If the standards process that namespaces goes through were anything like the process that of SAX or XSchema (which to an official standards body may be considered barbaric), I think that namespaces would be much further ahead and there would be many more people happy with it. No matter how many geniuses you have working on some standards draft in a closed forum, it is my opinion that you will rarely do better than a forum of collective opinions of those who actually need to work with that standard. Once you take the politics out of a standards process and only concentrate on being pragmatic, it is amazing how successful standards endeavours can become. 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...)
|
