Details
-
Suggestion
-
Resolution: Won't Do
-
P3: Somewhat important
-
None
Description
Instead of adding expand(), add a pull interface(as planned) for QtXmlPatterns, and implement document projection. It makes this kind of optimization transparent to the user, and is also broader in what it applies to.
From #koffice
--------------------------------------------------------------------------
[14:24] <astan> fenglich: ah. okay! just a shameful plug here; an "expand" kind of function in Qt's pull parser similar to the one in libxml2's and .NET's would be awesome
[14:25] <astan> e.g. one that will expand the currently held "window" of the document into a structure on which you can do XPath et.c. (http://xmlsoft.org/xmlreader.html#Mixing).
[14:25] <astan> okay, enough OT now
[14:26] <CyrilleB> yeah ! ;p
[14:28] --> ltinkl has joined this channel (n=ltinkl@194.212.22.14).
[14:29] <fenglich> astan: the purpose would be speed?
[14:31] <astan> fenglich: no, convenience. it's a really nifty piece of API. say you have a huge but pretty flat XML document, e.g. a catalog of books. then you could use the pull parser for the small mem footprint..
[14:31] <astan> ..but you could expand each book temporarily and do XPath or DOM work on it. then discard it.
[14:32] <fenglich> aha, document projection in document loading achieves the same thing, although it has to very good to achieve the same kind of low granulaity as a hand written approach.
[14:32] <fenglich> Document projection analyses the query/XPath to build a document that only contains what's actually needed for evaluating the query.
[14:34] <astan> ah i see. the expand function in the libxml2 and .NET APIs expands the current node full in memory, and of course only gives XPath access to a limited piece of the doc (the expanded part).
--------------------------------------------------------------------------