xml-dev - Re: SAX2 Namespace Support

[David Brownell <david-b@pacbell.net>]

There's been way too much email on this topic -- I should have weighed
in earlier.  In all honesty I'd prefer to see all namespace support be
cleanly layered on top of SAX1.  It's easy to do it that way; just add
some optional code to postprocess a SAX event stream.


With respect to this particular proposal, I have several comments.

First, it's unclear to me what's happened to our old friend, the
org.xml.sax.DocumentHandler.startElement callback:

    public void startElement (String name, AttributeList attrs)
    throws SAXException;

If that call is gone, I anticipate migration problems to SAX2.

If it's still there, then it must be the application's choice to use
the new sax2.DocumentHandler interface or the original ... presumably
it would use Configurable.setProperty() with some ID for the new
namespace-aware sax2.DocumehtHandler to identiy its choice.


Second, it's unclear how to report violations of namespace conformance.

I'd asked that the namespace spec resolve this issue, by using the same
reporting terminology that the XML spec uses ("warning", "error", and
of course "fatal error"), but instead it got even more vague.  So I'll
have to ask how SAX will address this ... keeping in mind that if W3C
gets around to answering those questions, it might pick different answers.

That is, faced with this document

	<?xml version="1.0"?>
	<html:p>Hello again! :-)</html:p>
	<?at-end-of-document?>

Two reporting issues arise:  (a) How does one know that namespaces are
to be used at all?  It's a legal XML 1.0 document, so inherently there
is no error.  (b) If one knows that namespaces are to be used, is
the undeclared "html" prefix to generate a warning, recoverable error,
or fatal error through sax.ErrorHandler?  Is it reported some other way?

I think that using ErrorHandler.error() is the best solution, but then
that leads to the issue of how to report namespace URIs that aren't
available.  (And as I recall, there were more errors to deal with than
just unresolved namespace prefixes.)


David Megginson wrote:
> 
> Richard Anderson writes:
> 
>  > >   public void startElement (String nsPrefix, String ns, String name,
>  > >                             AttributeList atts)
>  > >     throws SAXException;
>  > >
>  > >   public void endElement (String nsPrefix,String ns, String name)
>  > >     throws SAXException;
>  >
>  > We can build ours DOM more easily this way dont have to buffer the other
>  > namespace events.  I also would be surprised if at least 80% of SAX2 users
>  > a) wouldnt mind this being present b) would probably use it
> 
> ...  James's suggestion was that, at
> user option, the parser leave the original prefix on the name:

A problem with this approach is that it expects that what's generating
those SAX callbacks is a parser.  If namespace support is added by a
filter layer, then anything generating SAX callbacks can be combined
with the filter.


>   startElement("http://www.w3c.org/1999/xhtml", "html:p", atts);
>   characters("Hello.");
>   endElement("http://www.w3c.org/1999/xhtml", "html:p");
> 
> This would never be enabled by default, but for the relatively small
> class of apps that needed to know the original prefix, the prefix
> would be available simply by splitting the name argument.

Clearly that class includes "DOM-using applications", which for better
or worse (opinions do vary :-) isn't a small class.

DOM L2 applications explicitly have the same option that I noted above:
use (or non-use) of namespace information is the choice of the application,
not the choice of some version of an XML infrastructure.


> I like this approach because it doesn't throw the prefix in the face
> of apps that don't need it -- to paraphrase Larry Wall, it makes common
> tasks easy and uncommon tasks possible.

A third issue:  building a DOM is quite "common" though, and it needs
those prefixes.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)