SAX 2.0 extension proposals.

[Toby Speight]

Miles> Miles Sabin <URL:mailto:msabin at cromwellmedia.co.uk>

0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A6752A7 at odin.cromwellmedia.co.uk>,
0> Miles wrote:

Miles> Toby Speight wrote:

>> [snip: XMLImplementation and filters]
>> It would be nice if Miles gave some thought to this issue.  Perhaps
>> it's an insoluble problem; perhaps filters need some additional
>> feature types (or additional queries on those features) to indicate
>> how the the upstream parser's behaviour is modified.

Miles> Actually, I don't think there's a problem here.
Miles>
Miles> The org.xml.sax.helpers.XMLFilter itself isn't intended to be
Miles> used directly ... it's meant to be extended by SAX applications
Miles> (David: I think it should be marked as abstract).

I agree with this statement.


Miles> That being so, there's no reason for it to have a corresponding
Miles> concrete XMLReaderImplementation.
Miles>
Miles> Now, if you extend it,
Miles>
Miles>   public class MyFilter
Miles>     extends XMLFilter ...
Miles>
Miles> you could do something like this,
Miles>
Miles>   public class MyFilterImpl
Miles>     implements XMLReaderImplementation
Miles>   {
Miles>     private XMLReaderImplementation itsBaseImpl;

That assumes you only use filters with particular upstream classes.
What if a factory wants to know about filters so that it can build a
parser/filter combination with the required features?  (Assume none of
the parsers it manages provides the right feature-set).  Perhaps this
is an ambitious requirement for a factory, but it would certainly be
useful.

I'm not going to be hugely upset if we can't do this stuff, but I'd
hate to see it go simply because it hasn't been considered.

-- 


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/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.