[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ModSAX: Proposed Core Features (heretical?)
<Bill's Comment> My belief here is that it is perhaps best to abandon validation by the parser- kernel and instead use filters which support the validation needs of the application. Errors so detected may be because of a poorly constructed document, but may also be due to constraints imposed by a particular application. This of course raises the question of how the response to these two different types of errors should differ. I can understand a desire to make such a distinction, but I have not yet come to appreciate the need to make such a distinction. Bill </Bill's Comment> 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. 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)? Another option, though also frighteningly bad for performance and requiring compliance by parsers, would be way to plug filters in 'under' the input into the parser. That way, the filtering would happen before the parser passed judgement on it for either well-formedness or validity. Otherwise, even if you validate the end product of the filter sequence, how do you know it remained well-formed? That check is usually implicit in the call stack of the parser on the original content. But, of course, how would the filters operate on the text that has not been parsed yet? :-) Its almost like you'd want to parse it lightly to get it to the filters, let them shake and bake it, then parser it for real and validate it. But that would be really rough for performance also. For just the scenario where an application wants normal wf/valid checks but needs to add more to it, that's an obvious application of a validation filter that wouldn't be a performance pig hopefully. I think that makes a lot of sense. But if the content gets changed along the way, knowing whether it got hosed in the process seems important. Anyway, that ramble seemed incoherent even to me, but I think there was a point in there somewhere :-) 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
|