In fact, as you point out, my main goal is to construct a DTD/Schema directed document creation system where the parser can help the application in writing the XML document. To be able to accomplish this, several things need to be implemented (in decreasing order of importance):
Incremental parsing (pull-parsing, for example) which does not require the buffering of the entire document and where the chunks can be of various sizes. Ideally, if the parser could read from a stream and just bloc when more data is needed (at the applications request) would be perfect. Error correction on the fly. Although this is certainly interesting... I believe that if execution time is not a constraint, simply resubmitting the document with the error corrected could be a good starting point. DTD/Schema directed document creation. Well this could take many forms... from a basic point of view, simply being able to query the parser with questions like : "Ok, what elements can finish now, what elements can start, what are the ancestor of the current opened element" is good enough for me. These questions are linked to the current parsing stage. On the other hand, the more general DTD/Schema API can answer the rest of the questions like "can this element contain CDATA, what does this element contain, etc...". The problem I hope I will not have is late error reporting. I don't know how much Xerces buffers things, but if I submit a chunk of data that contains an error, I would like to know it right away. I understand that Xerces does not offer 100% guarantee that the error will be detected at the exact character where the error occurred, right? I have to take this into consideration, because if my chunk ends at that exact character it could give the wrong signal to the application. Daniel Shane At 10:41 AM 7/2/2002 -0400, Joseph Kesselman wrote: >Note that incremental parsing is a different matter from being able to >correct errors on the fly (not supported, as far as I know), which is in >turn different from doing DTD/Schema-directed document creation (may be >possible, thought the schema APIs are still evolving). > >______________________________________ >Joe Kesselman / IBM Research --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
