[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Announcement: XML Infoset Requirements Published
> > This layered approach to XML is burying its potential. > >I'm having a lot of trouble following the argument -- perhaps a simple >summary of the main points would help. Do you believe that layering >is a problem because it's hard to keep track of or manage the >different layers, or do you believe that XML should not be the base >layer? Some of both. I worry that the stack model is deceptive in that it masks the degree of complexity that each spec adds to the entire system. 1) Putting the XML spec at the bottom presupposes that the markup is the essential characteristic of XML. I would argue that the essential characteristic of XML--what gives it so much potential--is the consistent data model that is shared between the XML spec, DOM, Sax, RDF, etc. I don't see how the XML spec proper is somehow "more essential" to the system than anything else. Granted, it is much easier to formalize a language than an abstract data model, but I see that as a poor objective justification for elevating its status. The issues at hand are very pragmatic. The success or failure of XML will not turn on the academic aspects of the langauge spec. It will turn on the degree to which the system as a whole is able to tame the complexity (and thus costs!!) of various information systems. If history is any indication, that complexty (and cost) will be manifest in the software required to process and manage the data. To that end, it seems naive to assume that decisions can be made at the lowest levels without regard to their impact at the higher levels. 2) OSI-style protocol stacks work (or don't work) because the number of interfaces are directly proportional to the number of layers. Ideally seven layers yeilds six interfaces. XML isn't so neat. This is manifest in the discontent over namespaces. If the namespaces interface was with the XML spec only, I doubt that there would be so much complaining. But ultimately if we're to keep the XML camp together, all of these technologies need to be kept in sync. This is HARD! If N is the number of XML related specs, the number of related interfaces will be N!/2. This is going to get really complex, really fast. More than anything, we need a *name* for the system that is comprised of all of the specs discussed on this list. Java is a good example. The java language spec, the virtual machine spec, and the APIs, and the various implementations all fall under the banner "Java". This subtle organization has been instrumental in its success. Microsoft tried to claim that Java was just the java language spec, but Sun has arranged things so that that it is clear to the objective observer that this is not the case. More importantly, the Java banner has ensured that Java ISVs have gone in a consistent direction. You might not agree with what Sun is doing, but they're doing a hell of good job doing it. XML is not heading down the same path. I'd like to see the following: 1) A rallying point for XML related technologies. The psychology of a name is significant. If this list was called XYZ-dev, I think that we'd all be better off. I know a lot of people will think this is frivolous, but I hope there is some thought put into the issue. I'm afraid that XML is going to become, in Bill Gates' words, *just* a markup language. (Please, don't respond by telling me that XML is just a markup language because that is my point.) 2) Some formal analysis of the overall system. At the very least, this could be a set of hypothetical use-cases for the various XML technologies. There is quite a lot of "XML is for ____" commentary on this list these days. Arguing these points in detail is bound to go nowhere. The fact of the matter is that people are going to use XML for all kinds of different things. Of course it does not make sense for all of these potential uses to become guiding principles for the XML initiative. However, without some guidance, these differences will begin to manifest themselves in parochial initiatives (ABC spec, DEF spec, etc) that will be mutually incompatible and ultimately fracture the overall effort. As you can see, these are *not* technical concerns. I think that it is imperitave that we realize that the success and failure of technology rarely turns on objectively technological issues. Focusing on the shortcomings of XML namespaces misses the salient issues entirely. The litany of woes will continue unless something is changed. Last month it was namespaces, now it is the infoset, next month it is going to be something else. Let's go after the root of these problems. Rob 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/ and on CD-ROM/ISBN 981-02-3594-1 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
|