SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML)

[David Megginson]

Paul Prescod writes:

 > > Namespaces seem to be an essential solution to two problems
 > > encountered when designing XML stuctures: - how can I distinguish
 > > my tags from everyone else's, to avoid confusion (eg:
 > > "<my:pastry/>");
 > 
 > Actually, this problem is very RARELY encountered. If you are
 > building a typical one-organization application then what are you
 > doing with "other people's tags" in your documents? I mean, if you
 > are writing typical software, it will choke and die when it comes
 > upon tags it does not know about.

This depends on whether the information is documentation or
fielded/tabular content.  So far, far over half the work that
Megginson Technologies is doing with XML (rather than SGML) is for
data exchange rather than document production.

For example, let's say that I design a record structure for
information about a member of a mailing list:

<member>
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
</member>

Now, let's say that I get records in from other mailing lists whose
maintainers include extra information that is not part of my original
spec:

<member>
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
<origin>Canada</origin>
</member>

These records are still using <member>, <email>, and <company> in the
same way, but they've added something else.  Now someone else might
take a different approach to <origin>, since it wasn't part of my
original spec:

<member>
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
<origin>University of Waterloo</origin>
</member>

The advantages of being able to come up with globally-unique names
should be obvious:

<member xmlns="http://foo.com/ns/"
        xmlns:a="http://hack.com/ns/">
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
<a:origin>Canada</a:origin>
</member>

or

<member xmlns="http://foo.com/ns/"
        xmlns:b="http://bar.com/ns/">
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
<b:origin>University of Waterloo</b:origin>
</member>

or even

<member xmlns="http://foo.com/ns/"
        xmlns:a="http://hack.com/ns/"
        xmlns:b="http://bar.com/ns/">
<name>Paul Prescod</name>
<email>paul at prescod.net</email>
<company>ISOGEN</company>
<a:origin>Canada</a:origin>
<b:origin>University of Waterloo</b:origin>
</member>

A second major advantage of namespaces is the ability to reuse
processing code.  If I have written an event-handler/subroutine/method 
to do something useful with an HTML <table> element, then I'd like to
reuse that for *every* document type that happens to use the HTML
table model, even if I don't know about the document type in advance.

Of course, I know that I could do all of this with architectural forms 
as well.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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)