Another look at namespaces

[Paul Prescod]

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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)