Re: [xml] Some words about libxslt

Date view Thread view Subject view Author view

From: Daniel Veillard (veillard@redhat.com)
Date: Mon Mar 05 2001 - 10:24:12 EST


On Mon, Mar 05, 2001 at 03:32:21PM +0100, Tom . wrote:
>
>
> Le 05/03/01 14:48:43, Daniel Veillard a écrit :
> > > I'm writing such an API and will keep you informed.
> >
> > Humm, open source projects don't work that way ... You can't say
> > "hold on I'm writing some code you may look at later", sorry :-)
>
> Well, it hasn't yet passed the stage of ideas and drafts. I'll first write
> a paper explaining its goals etc. I think of proposing it on the
> www-xpath-comments@w3.org mailing list for discussion and improvements.

 Hum, no. www-xpath-comments@w3.org is dedicated to comment on the
specification itself, not about how to write an interpreter for this
language. Other channels like xsl-dev and xml-dev mailing-lists are
far more relevant.

> Then will begin the implementation stage with whoever will want to
> participate: for libxml, in Java, etc.
> I think this is open-source-oriented, isn't it? ;o)

  yes maybe,

> Its first goal is XPath evaluation improvement.

  FYI when profiling a number of run of xsltproc the XPath evaluation
functions were not in the top 10 !!! You may waste quite a bit of time
focusing only on this.

> One important point is a "compilation" phase, to separate parsing from
> evaluation and allow reuse of the expression without parsing it each time.

  my approach was to compile patterns not the generic XPath calls.
Less complex, minimize change in the xpath module. i may switch to
a full compilation of XPath expression at some point, but it doesn't seem
urgent so far.

> Imagine you have a huge DOM tree and you want to apply an non-well-formed
> expression. Without separating parsing from evaluation, you may have done
> 90% of the work (expensive for a huge document) to finally abandon it :
> there is an error in the expression. It seems to me it's too much work for
> nothing in result, and it can be prevented by parsing the expression before
> trying to evaluate it.

  Who cares about optimizing the error cases ?
Compiling XPath expressions can be an useful optimization but:
   - currently it doesn't seems the bottleneck
   - your example ain't the best one. Conformance may be, proper
     evaluation of 'and' and 'or' expressions would be simpler
     with a precompiled form

> A second goal is to provide a single parser for every XPath-like expression
> : XPointer XPtrExpr's, XSLT Pattern's, etc. and their future evolution. I

  No, XSLT patterns *have to* be interpreted differently. A generic XPath
evaluation for a pattern leads to a node-set. What one need for patter matching
is the different evaluation 'would node x pertain to the node set result ?'.
My take is that current poor performances of a lot of XSLT processors
is that they compute those full XPath expressions ...

> > yes and it seems quite simpler.
>
> Sure, and I know you're a KISS follower ;o) , but quite more time
> consuming...

  and running *NOW*, I'm a believer in running code too ...

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
----
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 : Mon Mar 05 2001 - 10:43:37 EST