From: Bjorn Reese (breese@mail1.stofanet.dk)
Date: Sat Oct 14 2000 - 07:00:21 EDT
Daniel Veillard wrote:
> In 1/ you may be able to gain over the current implementation memory
> use but as i pointed out, not that much (or it will be really slow if
> you don't have simple pointer walk to traverse XPath axis). And unless
> you know in advance the XPath function that you will target (which
> may even be computationally impossible depending on the use case) one
> really need to store the informations for the full document "/.." is
> alaway possible in any XPath step !
True, the ancestry and sibling axes may require access to already
parsed (and ignored) parts of the document.
However, I still find the idea interesting because we have documents
that can be as big as 20Mb, where only a few pieces of information
has to be extracted. Furthermore, we only use a subset of the XPath
functionality, none of which use ancestry.
> In 2/ that will be an awful lot of function calls, but this is
> realistic. Maybe a good starting point is to look at the XML Infoset
> draft
> http://www.w3.org/TR/xml-infoset
> and map all the information items to associated functions. Then try
> to refine to eliminate unused functions and build the implementation
> on this function set.
This is an interesting approach. I will be looking into this in the
future. Thanks.
---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Sat Oct 14 2000 - 09:43:39 EDT