Lists Home |
Date Index |
- From: Gabe Beged-Dov <email@example.com>
- To: Lars Marius Garshol <firstname.lastname@example.org>
- Date: Thu, 25 Mar 1999 11:29:52 -0800
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
> | 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?
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)