[XML-SIG] SAX 2.0 resolution?

[Lars Marius Garshol]

* Lars Marius Garshol
|
| [startElement & startElementNS]
|
| The only disadvantages I see are that this may cost an extra method
| call per callback for some generic filters and that it does not make
| it clear that it is not allowed to mix the namespace and
| non-namespace methods in a single document.

* Ken MacLeod
| 
| How does this affect down-line filters?  what happens when a
| non-NS-using filter precedes an NS-using filter or handler?

I don't think this is the right way to look at it, because whether the
filter uses namespaces or not does not matter. If it doesn't use
namespaces it should still support them, and if it can't support them,
then that's the problem and not that it doesn't use namespaces.

So what matters is whether a filter supports namespaces and whether it
supports non-NS-mode. Since you can't use filters that require
namespaces with filters that do not support namespaces anyway, I don't
think this is a problem.

That is, you should be able to assemble the filter stack regardless of
what the participating filters support and do not support. However, if
you try to turn off namespace support with setFeature() the filters
that require NS processing should complain. If you try to run with
namespace support on the filters that do not support it should
complain.

So you should get a proper error message if you do something you
shouldn't. Otherwise things should work, provided filter writers do
their job properly.
 
| With the startElement(namespaceURI, localName, qName, attrs) model,
| you'd expect upline filters to pass all the parameters whether or not
| they themselves used it.  

Agreed. In this model it is expected that filters pass on both the
startElement and the startElementNS events, provided that this makes
sense. 

If you implement XInclude using a filter, this would require namespace
support, and so it would not make sense to pass on startElement
events, because if the filter gets startElement events something is
wrong. (It should actually raise a SAXNotSupportedException in both
startElement and endElement.)

If you implement a filter that joins together consecutive characters()
events so that you never have character data split into several events
this filter should pass on both startElement and startElementNS
events, since those are orthogonal to what the filter does.

| (And, of course, you wouldn't be expected to mix SAX1 and SAX2
| filters.)

You still aren't. A SAX1 filter will not be able to handle the
skippedEntity event, for example.

--Lars M.