SML - an alternative
I wonder if the markup community is best served by trying to create yet another standard. Clearly, this discussion indicates that XML has problems. I suspect we'd be better off finding the solution -- we'd have a better tool without diminishing the momentum behind XML. In that vein, then, some thoughts. People who have built parsers claim the alleged complexity of XML isn't a problem for them *as XML stands*. Not having built one of my own, I'll take their word for it. As a writer, I'd agree there is a real documentation problem with the recommendations. People like me need to explain the Recs to programmers, but how about better examples in the Recs? They're kind of thin. For that matter, there is an appalling lack of internal consistency in some of the drafts I've seen. As a community, we need to find a way to bring newcomers up to speed without telling them they are incompetent if they don't know the intricacies of entities, say, on day one. Coming from the XML-as-data camp, I seldom have need for them. The XML-as-publishing people do. Let's recognize that different communities exist which require different tool sets. As a programmer, I am concerned with the spiraling growth of standards and apps that build on "core" XML, e.g., XSLT, XPointer, etc. This is where I think this list could help. The same impulses that are driving the SML discussion should drive us to discuss what the minimal set of standards should be for a parser. That is, if you recognize "<?xml version="x.x"?>", what should you support? XML 1.0 clearly. I feel namespaces should be folded into an update of the XML rec in preference to its orphan status. The same goes, eventually, for XML Schemas. But XPath? XLink? I think we could help the community by discussing different levels of processor support and lobbying W3C for a mechanism for communicating this in documents. Maybe a well-known PI or an attribute of the XML declaration. A processor encountering a document that requires something beyond the core could dynamically load a component that supplied that support or reject the document. Perhaps there should be a WG on showing how the XML-related efforts relate, *especially programmatically.* In summary, then, I think SML is a bad idea being discussed for the right reasons. I don't think XML is so badly broken that we need yet another ML recommendation. Addressing the problems will require a variety of approaches. Let's get at it. 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 unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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