[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Another look at namespaces
David Megginson wrote: > > I believe that > > a. the vast majority of applications will be most concerned with #1; > and > b. the applications concerned only with #1 will tend to be the > lightest-weight ones. This sounds similar to me to a goal we set in designing XML. It's become corrupted over time but as I recall the original goal was that XML should not only be implement but "hackable" in the sense that you could sit down with Perl and Awk regular expressions and do cool things with XML documents like rename element types and so forth. I thought that that was a bad criterion for several reasons but one of the major ones was that nobody *should* have to hack XML with regular expressions. They should be able to download a nice XML module and go to work on top of it instead of pretending that the XML was just text. So XML came around and not only did the nice modules come around for every language but they are actually built into the distributions of most languages now. Java is a little slow but nobody seems to have a big problem downloading and installing parsers. Even if XML was as hard to parse as SGML (which, thankfully, it is not) it would be possible to make "lightweight" applications if you can depend on using a library that someone else has written. Most "lightweight" applications today depend on megabytes of JDK, JVM, OS, GUI and device drivers. So "lightweight" typically means "written in a few lines of code but built on top of mountains of it." Part of your and my life's work has been to help develop the mountains. As part of that exercise I claim that it should be possible to write a single module that handles versioning for most XML applications and transparently allows older applications to do "the right thing" with newer documents. I claim this because I believe so strongly that XML applications should be both lightweight AND robust and I see no reason to require a trade-off. Build on a "version engine" and in a few lines of code you have an application that is future-proof and tiny. In order to invent this version engine we need a unified, implementable concept of language versions and/or dialects. We can't just say: "HTML is anything we say it is and an HTML dialect is anything similar." --- Obviously there is another definition of lightweight that implies tiny byte counts, minimal dependencies, and so forth. "Microwave oven XML" style lightweight. But the truth is that "standard XML" and HTML are not very good for those applications anyhow. You must design an variants that are not so expensive to implement. Therefore I am reluctant to start thinking about embedded processor at level 4 when levels 0 through 3 didn't really do so effectively. Microwave oven designers can develop an XML subset (perhaps just canon XML?) and their own namespace and versioning strategy. I'll bet the smallest, from-scratch (i.e. using no libraries) XML compliant parser takes up more ram than my first computer had! Paul Prescod 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
|