Cart
[Home] [By Thread] [By Date] [Recent Entries]
From: roddey@u... <roddey@u...> >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@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...)
|
