Cart
[Home] [By Thread] [By Date] [Recent Entries]
Lars Marius Garshol wrote: > This whole issue just strengthens my conviction that we need to > specify filter handling within the SAX2 core. This will need to deal > very carefully with parser encapsulation for approaches like this one > to be really feasible in implementations. > > It wouldn't be much fun if a filter did the normalization without > telling the parser and thus caused trouble with the LexicalHandler, > and no hint of this trouble ever reaching the application. The SAX filter registration interfaces don't allow multiple filters to be registered for the same feature. I don't see how you can have more than one owner for all the registered handlers without getting into severe trouble. This is not a bad thing as you probably want something like MDSAX to handle the filter networks. It allows SAX(2) to be lean and mean. If the same logic is managing all the callbacks, it can gracefully handle the variations of CDATA notification (or lack thereof) and text-normalization on behalf of the client of the filter network. > | The fact that it would need to be configureable (concerning CDATA > | handling) might make it a more useful pedagogical aid. > > As to how filters work, you mean? Well, we should let ourselves be > affected by that. And, besides, whitespace normalization is a far > better example, I think. Does whitespace normalization require aggregating notifications or just scrubbing the contents of a particular notification? Gabe Beged-Dov www.jfinity.com 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...)
|
