ModSAX: Proposed Core Features (heretical?)

[Bill la Forge]

From: roddey at us.ibm.com <roddey at us.ibm.com>
>That would have some pretty large performance implications. For our new
>generation parsers, we can validate the event stream *very* fast as its
>going out of the parser. Doing it after the fact, way up stream, would be
>much, much slower. I could imagine that this would be true of other parsers
>as well, that once the stuff has gone out into the 'real world', validation
>becomes much more work becuase now it has to be in terms of text
>comparisons instead of internal element ids.


It would be nice to have a lower-level interface where such things could
be done efficently. This is one of the reasons why I sometimes speak of
parser-kernel, as an oblique reference to Simon's layered architecture
proposal.

>I understand that the filter sequence could change the document, but
>wouldn't it be just as important to know that it died because the original
>document was hosed (and therefore the filters spat out junk)?


Too true.

Bill


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)