[Q] How should SAX support Namespaces?

[Toby Speight]

Toby> Toby M. Speight <URL:mailto:tms at ansa.co.uk>
David> David Megginson <URL:mailto:david at megginson.com>
John> John Cowan <URL:mailto:cowan at locke.ccil.org>


=> In article <199807201132.HAA00572 at unready.megginson.com>, David
=> wrote:

David> 2. Use the current interface, but allow namespace-aware SAX
David>    processors to prepend namespace URIs to element type and
David>    attribute names, as in
David>
David>    startElement("urn:www.megginson.com:doc", ...)
David>    endElement("urn:www.megginson.com:doc", ...)


=> In article <u7m18pqsz.fsf at delivery.ansa.co.uk>, Toby wrote:

Toby> I don't particularly like (2) above, since it means that different
Toby> SAX parsers may return different values for the same document.


=> In article <35B8F05B.7ABBD816 at locke.ccil.org>, John wrote:

John> I don't understand this comment.


My worry is that if the new interface for namespace-processed elements
is the same as that for SAX 1.0, then either kind of parser could be
used in a given program.  But the two types will not return the same
information through the interface, even though there is no change to
the function call.  This violates the principle of interfaces and
programming-to-contract.

OTOH, if namespace processing is an extra layer slotted in, that has
to be explicitly enabled with something like

  parser.setNamespaceProcessor(myNameHandler);

or

  namespaceProcessor.setParser(myParser);

then there is no change on the namespace-unaware application, and if a
namespace-aware application is given a namespace-unaware parser, this
will be discovered when it tries to enable namespace support.

-- 


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/
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)