SAX2: Namespace proposal

[James Clark]

Here's an alternative proposal:

interface DocumentHandler {
  void startElement(String namespaceURI, String localName,
                    AttributeList attList);
  void endElement(String namespaceURI, String localName);
  // ..
}

interface NamespaceDeclHandler {
  void startNamespaceDecl(String prefix, String namespaceURI);
  void endNamespaceDecl(); // prefix argument?
}

interface AttributeList {
  String getValue(int i);
  String getLocalName(int i);
  String getNamespaceURI(int i);
  int getType(int i);
  String getType(String namespaceURI, String localName);
  String getValue(String namespaceURI, String localName);
}

I propose that there there is a NamespaceProcessingLevel feature that
applications can set on the parser with 4 possible values:

Cooked (the default)
IncludePrefixes
NamespaceDeclarationsAsAttributes
Raw

When the level is Cooked, you get a fully cooked
post-namespace-processing only view: namespace declarations don't
appear in the AttributeList; localName contains the local name and
namespace URI contains the namespace URI.

When the level is IncludePrefixes, the parser instead of reporting
local names, will report QNames.  Specifically the second argument in
startElement and the value returned by AttributeList.getLocalName(int)
will include any prefix as well as the localName.
AttributeList.getValue(String, String) and
AttributeList.getType(String, String) are affected as follows: the
localName may have a prefix; if the namespaceURI is non-null, then the
prefix is ignored; if the namespaceURI is null, then any prefix is
used to identify the attribute.

When the level is NamespaceDeclarationsAsAttributes, as well as the
IncludePrefixes changes, namespace declarations are included in the
AttributeList. The namespaceURI for namespace declarations is always
treated as null.  (This level is intended for applications like the
DOM Level 2 that want to support simultaneously both a XML 1.0 view
and an XML Namespaces view of a document; applications like XSLT and
XPath that just need namespace scoping information would instead use
the NamespaceDeclHandler.)

When the level is None, then no namespace processing
is done at all.  This is the same as the
NamespaceDeclarationsAsAttributes level, except that namespace URIs
will always be null.

The thinking behind this proposal is that there are three classes of
use:

1. Those who want a fully cooked namespace view

2. Those who want a fully cooked namespace view, but also want to know
   the actual prefix used.

3. Those who don't want any namespace processing at all (perhaps
   because they want to roll their own)

My view is that class 1 is in the long-term the most important class
and the interface should be optimized for them; therefore it's
acceptable to subject class 2 and 3 users to a little inconvenience in
order to buy convenience for class 1.

With this proposal, class 1 users get an ideal interface. Class 2
users have the inconvenience that they need to split up a QName into a
local name and a prefix whenever they have a non-null namespace URI;
this is easy and cheap to do, and SAX can provide convenience
functions; they also have deal a slightly misleading name for the
AttributeList.getLocalName. Class 3 users have the inconvenience that
they have to pass a null namespaceURI argument to some methods on
AttributeList, and they have to ignore a null namespaceURI argument on
startElement and endElement.

SAX processors would be required to support at least one of the
Cooked level and the Raw level, and could
optionally support as many others as they wished.

James


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 unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)