[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX RFD: ModSAX Predefined Features
> 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@i... 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@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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|