Cart
[Home] [By Thread] [By Date] [Recent Entries]
Oren Ben-Kiki writes:
[snip]
> Additionally, implementers would have been able to easily add a
> namespace processing module on top of their current XML parsers (a
> SAX namespace expansion filter, for example, is trivial when
> implemented this way), _without changing the interfaces_. Future
> implementations might use better interfaces - such as APIs for
> accessing just the "namespace part" or the "local part" of an
> expanded name - but the point is every XML application would go on
> working as it is, without any changes.
[snip]
> An obvious consequence of this decision is that implementers were
> hesitant to implement namespaces this way.
Actually, so far, pretty much everyone seems to have implemented
namespaces this way, and it's working like a charm: it's standard in
the very popular Perl XML:Parser module (which uses Expat), I wrote my
own SAX filter (unreleased) which works this way, John Cowan has
released a SAX filter that works this way, and I assume that all RDF
and XSL tools built on top of SAX work this way.
I rely quite heavily on the namespace processing in XML::Parser for
some of my production-grade deliverables to customers.
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...)
|
