Marko Rauhamaa <ma...@pacujo.net>: > Alain Ketterlin <al...@dpt-info.u-strasbg.fr>: > >> Marko Rauhamaa <ma...@pacujo.net> writes: >>> Sometimes the XML elements come through a pipe as an endless >>> sequence. You can still use the wrapping technique and a SAX parser. >>> However, the other option is to write a tiny XML scanner that >>> identifies the end of each element. Then, you can cut out the >>> complete XML element and hand it over to a DOM parser. >> >> Well maybe, even though I see no point in doing so. If the whole >> transaction is a single document and you need to get sub-elements on >> the fly, just use the SAX parser: there is no need to use a "tiny XML >> scanner" (whatever that is), and building a DOM for a part of the >> document in your SAX handler is easy if needed (for the OP's case a >> simple state machine would be enough, probably). > > An example is <URL: > http://en.wikipedia.org/wiki/XMPP#XMPP_via_HTTP_and_WebSocket_transports>. > > The "document" is potentially infinitely long. The elements are > messages. > > The programmer would rather process the elements as DOM trees than > follow the meandering SAX parser.
In fact, the best thing would be if the DOM parser supported the use case out of the box: give the partial, whole or oversize document to the parser. If the document isn't complete, the parser should indicate the need for more input. If there are bytes after the document is successfully finished, the parser should leave the excess bytes in the pipeline. IOW, if the DOM parser knows full well where the document ends, why must the application tell it to it? Marko -- https://mail.python.org/mailman/listinfo/python-list
