Re: [xml] prerelease of 2.2.5

Date view Thread view Subject view Author view

From: Daniel Veillard (Daniel.Veillard@w3.org)
Date: Fri Oct 13 2000 - 11:36:00 EDT


On Fri, Oct 13, 2000 at 03:17:37PM +0000, Bjorn Reese wrote:
>
> Daniel Veillard wrote:
> >
> > On Fri, Oct 06, 2000 at 04:32:54PM +0200, Helge Hess wrote:
>
> > > or does it use callbacks,
> >
> > no
>
> I am probably off-target on this issues, but theoretically it
> should be possible, at least to a certain degree. I am not
> proposing that this should be part of libxml, but rather that
> it could be built on top of libxml.
>
> I recently had a discussion about how to use the SAX interface
> to build a parse tree that only contains the parts of an XML
> document that satisfies a set of XPath expressions. This can,
> theorically, be done by using state machines (something similar
> is done in Constraint Based Programming).
>
> I have not given this detail thought, but I believe that this
> could also be used to create a callback based system for XPath
> expressions.
>
> Disclaimer: I do not claim that this is an easy task.

  The problem is that XPath data model and versatility
forces to keep enough information about your document state that
enarly every bits of the DOM constructs are actually used by the
XPath interpretation engine. There is 2 things you may want to do
in building another XPath implementation:
  1/ try to limit the overall memory usage
  2/ find the minimal interface needed to be able to implement
     it using a procedural interface instead of relying on direct
     data access.

 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 !

 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.

  But this will be a lot of functions anyway !

Daniel

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe
----
Message from the list xml@rpmfind.net
Archived at : http://xmlsoft.org/messages/
to unsubscribe: echo "unsubscribe xml" | mail  majordomo@rpmfind.net


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Fri Oct 13 2000 - 11:43:56 EDT