SAX RFD: ModSAX Predefined Features

[Glenn Vanderburg]

> We should take this off-line.  I'll simply say: exceptions are
> suitable for reporting exceptional conditions.  Having an object
> request its own replacement is certainly exceptional.

Well, yes and no.  But I'd prefer to go the cleaner route of not
allowing the object to request its own replacement.

> The idea here is that an application may request a feature which
> a parser does not itself support, but can be adapted to support
> by pushing a filter between itself and the application.  

Yes, I understand.

>                                                          That
> of course requires that the application now talk to the filter
> instead.  (In principle, the parser could act as an adapter for
> the filter, but that would complicated the bejesus out of it.)

It's not complicated at all --- merely a little tedious.  It would
be easy to provide a class in the helpers package that would make it
almost trivial.

My primary objection to the idea is precisely what you mentioned above:
that it is an extremely unusual thing to happen.  Programmers will be
surprised by this behavior.  Coupled with the fact that it's very easy
to make it all transparent, I think exposing the parser's internal
tricks is a bad idea.

---glv

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/ and on CD-ROM/ISBN 981-02-3594-1
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)