OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: "XML Developers' List" <xml-dev@ic.ac.uk>
  • Date: Fri, 5 Feb 1999 09:37:05 -0500 (EST)

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@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@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@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@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@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@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@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS