Why SAX needs namespace support

[Tyler Baker]

Michael.Kay at icl.com wrote:

> >  > Perhaps a setOption(option, flag) interface would be more
> > extensible.
> >
> > I could live with this, but only if the options were namespace
> > qualified, i.e.
> >
> >   parser.setOption("http://xml.org/sax/features/validation", true);
> >   parser.setOption("http://xml.org/sax/features/namespaces", false);
> >
> I'm all for fully qualified names, but I don't see why we should repeat the
> error of using "http://" names for things that are not accessible via the
> HTTP protocol. What's wrong with
> "org.xml.sax.option.validation"?
>
> Or is this overkill anyway? Why not just say that names beginning with
> "sax:" are reserved?

This got me to thinking that you could have the best of both world's here from
those people who want support for validation, namespaces, and the like to be
through filters, and those who quite simply want direct native interfaces to the
parser.

To make this work you would need to do several things:

(1) Change the ParserFactory class to not return a parser but a ParserGenerator
object (in this case you might want to change the name "ParserFactory" to
"ParserGeneratorFactory").

You would then have an interface named ParserGenerator which would be reponsible
for constructing Parser types (such as parsers which do namespace processing).
Really I think we only need two Parser types right now and then do the rest of
the option stuff the way Mr. Megginson had suggested which I feel is simple and
to the point.

For a particular XML Parser package it would supply support for SAX by returning
a ParserGenerator implementation in a manner similiar to how ParserFactory
returns a Parser object (by using a system property).

The structure of the ParserGenerator interface would be something pretty simple
like this in Java:

package org.xml.sax;

public interface ParserGenerator {
  Parser createParser(InputSource source);
  Parser createParser(InputSource source, boolean validating, boolean
entitesExpanded);
  NamespaceParser createNamespaceParser(InputSource source);
  NamespaceParser createNamespaceParser(InputSource source, boolean validating,
boolean entitesExpanded);
}

If for some reason someone needed to use namespaces but the XML Parser
implementation had no direct support for it or otherwise had no way of supporting
the NamespaceParser interface, you could then use a standard filter that will
come with the SAX Package to achieve this need.  Michael Kay's SAXON package is a
great start here.

So if you did something like:

//////////////////////////////////////////////////////////////////////
ParserGenerator parserGenerator = ParserGeneratorFactory.createParserGenerator();

NamespaceParser parser = null;
try {
  parser = parserGenerator.createNamespaceParser();
} catch (UnsupportedParserException e) {
  parser = new NamespaceParserFilter(parserGenerator.createParser());
}

parser.parse(new InputSource("http://www.foo.org/xml"));
/////////////////////////////////////////////////////////////////////


NamespaceParserFilter would implement all of the methods of NamespaceParser and
simply be a utility class for filtering out handled events from the standard SAX
parser and then presenting them to the application.

Not so sure here if this is exactly "Simple" (I am one of the people here who
like SAX for its simplicity), but it does have some advantages in that you could
easily have namespaces support even if the underlying XML parser does not support
namespaces directly.  Plus, I doubt "Namespaces in XML" will have any widespread
use in the future by the great majority of XML Applications, so application
programmers who want to deal with the very populous simple SAX Parser interface,
won't have to eat the complexity of handling the namespace interface in their
applications.  Last but not least, we can talk about having specialized Name
types for the NamespaceParser interface without having to worry about messing
with the core XML parser interface.

What do you folks think here?

Tyler


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)