Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Remembering the original XML vision
 Other than that without the old guard, you'd be doing C++ programming without a name to brand, in most of what you say I'd agree. But let's not be too self-congratulatory. XML was a bit of hacking on a mature tree to make planks. The XML WG was a sawmill, not a forest. 1. XML has to be able to work with non-web systems if SGML is to be sandbagged at the same time. Some of these systems do not use MIME or even URLs. There is life Off The Web. The old guard saved markup from the likes of those who believed that only the Web was important to the future of computing and markup. That was heroic because it cost them dearly. 2. The SGML Way was more of a problem than SGML. This includes notions such as fully-easily readable tag names which document users appreciate but which are anathema to messaging systems where size does matter (try an RF system). The authors of some guideline documents based on thinking that only applies to document systems are doing the wrong thing. Too much form over function and fit. Too much appeasement over engineering. 3. What the vendors did was rush to the next new thing that had a chance of selling. XML was captured by lemmings. We traded some notions of flexibility for cheap tools and ubiquity. So far so good. But be very wary of believing that is proof of good decisions because the day is long and many events will transpire before one retires. XML may be overbuilt for any given application and a bit under built for others, but experience old and new is proving that without this slightly contracted but still core SGML system (aka XML), we would need another markup system and we would probably set out again to subset SGML. The SGML vision is inclusive. That made it an ideal place to start. The XML vision is narrowed and is increasingly narrowing. That will be its death knell. What isn't explicit in the markup will become explicit in the code. Still, it didn't bother some of us to narrow SGML as needed before there was an XML, and it will not bother us to refocus XML for our own applications, broad or narrow, if that is what we have to do to get performance and maintainability. We need neither permission nor sanction. In the interests of the health of the information, most will attempt to do as the specification insists one must, and one will use the applications such as XML Schema as they are designed to be used. Until they don't work. Then screw them. The XML WG/ERB taught all how to do this without apologies whereas in the SGML systems that predated XML, we were always defending sound technical judgment against tradition and view-specific guidance. No more. But we will stay on good terms with the horse. len -----Original Message----- From: David Megginson [mailto:david@m...] It is true that there is some useless cruft in XML that was included only for political reasons: public identifiers, notations and external entities serve no function that MIME types (or URIs -- sorry, Simon) and URLs couldn't serve, but we had to keep them in XML as part of an unwritten ceasefire agreement with the SGML old guard (*), which was still powerful at the time and could have seriously hindered acceptance of XML both inside and outside the W3C; the other part of that ceasefire was to pretend that XML and SGML would coexist, with XML for lightweight Web and SGML for so-called "serious enterprise applications" (the vendors put paid to that idea by abandoning SGML so fast that we couldn't keep up with the press releases). 
|
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
|
|||||||||
