Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML)
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@p...</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@p...</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@p...</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@p...</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@p...</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@p...</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@m...
http://www.megginson.com/
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
|
|||||||||
