Re: [xml] Some words about libxslt

Date view Thread view Subject view Author view

From: Tom . (ptittom@free.fr)
Date: Mon Mar 05 2001 - 12:26:57 EST


Le 05/03/01 16:24:12, Daniel Veillard a écrit :
> > 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.

Thanks, I just had a really rapid look at the XPath Rec while writing this
message and just saw a reference to www-xpath-comments. I didn't take
enough time to go farther in investigations...
However, I am proposing a parser API, not a parser or an interpreter, not
even (for the moment) a "compiled" representation of expressions. Such an
API should still allows one to evaluate an expression at parsing. This API
is intended as a SAX or SAC for expressions sharing equivalent syntaxes:
XPath, XPointer and XSLT patterns; very low-level.
It isn't either designed for libxml and my goal isn't to have it replace
the actual libxml's XPath implementation, just a proposal for another mean
of solving some problems...

> 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

I know. This isn't for now what I'm talking about. I was just dealing with
separation between parsing and evaluation, and some simple generic parsing
API. If you want to discuss on evaluation, I also have some ideas ;o)

> > 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.
>
> No, XSLT patterns *have to* be interpreted differently.

Interpreted differently on each "pass", sure, but parsed once, and that's
what you're doing in libxslt with a "compilation" phase.
XPath's Expr, Xpointer's XPtrExpr and XSLT's Pattern share almost the same
syntax. My view is: why then writing a parser/scanner/lexer for each of
them? with many duplicated code? Why not sharing a single parser and "plug"
different sets of callbacks to handle tokens differently?

> > > 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 ...

And you're right.
I just gave my opinion on the way I'd have solve the problem...

Tom.

----
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 - 12:43:31 EST