Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ubiquitous XML?
 At 09:54 PM 11/16/00 -0800, Chris Lovett wrote: >1. XML is not a passing fad. It is here to stay, despite all the weird and >wonderful things we are all building on top of it. XML is simply the >standardization of an incredibly powerful design pattern that has existed >for eons and will continue to exist for lots and lots of reasons. The >standardization of this design pattern is a hugely powerful thing creating >all kinds of new opportunities from PDA to Mainframe and everything in >between. I'm certainly not arguing that XML is a passing fad. What I'm arguing is that the current approach to XML's continuing development may in fact stifle more possibilities than they create. If complexity grows faster than capability, the net benefits are only apparent to those for whom complexity is not a cost. XML's initial rise had something to do with its approachability, and the tools which supported it. While the tools are continuing to improve, however, the overall approachability is (IMHO) declining. >2. The true genious behind simplicity is when it does not limit the complex >from being possible. This is the balance we must all strive for as we >continue to drive the evolution of XML and it's related family of >technologies. This is a nice vision. However, it lacks perspective on the costs which the complex can inflict on the simple. While 'XML 1.0' still means more or less what it did in February 1998, 'XML' no longer has the same meaning. For some perspective on what 'XML' now includes, I'd suggest taking a look at Xerces or MSXML, parsers which have grown capabilities well beyond XML 1.0. Keeping the simple out of the way of the complex does not keep the complex out of the way of the simple. It's easy to say "If you don't like the features, don't use them." It's very difficult not to have to deal with the features, however, if you don't have complete control over the set of XML documents you are expected to process. In certain limited cases, it's easy not to use the features, for now. In the total set of XML use cases, however, there are many situations where different expectations require developers to deal with the full range of possibilities. It's also easy to say "Hide the complexity in tools." While there are undeniably better and better tools emerging for XML, those tools aren't available in every situation, nor do they necessarily reflect the full set of capabilities in the specs. Again, this works, but only in a limited way. On top of these problems are real integration problems created by the continuing evolution of the XML specification family. Namespaces in XML introduces incompatibilities with XML 1.0 processing, and W3C XML Schemas introduce a post-schema-validation-infoset which is only accessible to those who use XML Schemas, not to mention some new interpretations of Namespaces in XML. XInclude adds some functionality to XML 1.0, but inflicts new transition costs on developers. There aren't obvious ways to make these things interact cleanly, but there are some very good questions about how this layering works and doesn't work, which might eventually lead to answers which allow the 'simpletons' to get along with the 'complexities'. >3. Sometimes the most valuable tool in software development is the garbage >can. When a given solution doesn't stand the test of time, then be honest, >put all politics aside and start over. Mortality in specifications may well be a good thing, but I don't see any of that happening in the near future. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books 
|
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
|
|||||||||
