[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Why SAX needs namespace support

  • From: Tyler Baker <tyler@i...>
  • To: Michael.Kay@i...
  • Date: Wed, 27 Jan 1999 10:18:49 -0500

sax parser support namespace
Michael.Kay@i... 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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.