[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: saxon:evaluate

Subject: [list4xt] Re: saxon:evaluate

User: Website

From: Paul Tchistopolskii (pault12@pacbell.net)
Date: 26/08/2000 - 21:09


> > If generating only *small part* of the stylesheet on the fly is evil,
>> why "generate the entire stylesheet on the fly" is *less* evil ???

> I am not sure I fully get James' point, but I think he wants to stick to
> the pure single way SAX streaming diagram:
>
> ------------------
> -- XML stream -->| XSLT |
> | Transformation | --XML output
> -- XSL stream -->| -----------> |
> ------------------

I don't understand this picture at all.

> xt:evaluate would create kind of internal loops.

I don't understand this statement at all. I don't udnerstand why
xt:evaluate should have any ( significant ) impact on current processing
model. It just adds one more level of lazy evaluation. It could be a problem for
particular implementation of XSLT engine, but in general it has no impact on
sax streaming e t.c.

Again, if I'm wrong - I'l be glad to see why xt:evaluate is evil ( especially when
I fould that there are 2 similiar constructions already implemented in XSLT ).

> xt:transform-node-set would externally "fork" another transformation and
> get its result back in a consitent way.

Will the *context* of fork be available to the forked transformation?
What happens with parameters ? E tc. e tc.. - Eric, you'l end up with
some monster ( which could be still less functional than simple xt:evaluate ).

> > Also, I think that implementation of Eric's 'execution of the stylesheet which is
compiled into nodeset' will require much more work than implementation of xt:evaluate.
> >
>
> I am not so sure.
> In the case of RFT, isn't it more or less just creating a new
> XSLProcessorImpl and setting the 2 parameters as Parsers ?
> There can be some connectivity classes to create, but basically a RTF is
> a SAX producer...
>
> Don't you think so ?

I'l say "I was wrong going into technical detail, sorry. The most important thing
is to understand why xt:evaluate is evil".

I don't like the idea of 'generate stylesheet on the fly' because I already
implemented grep in this way and it *is* a mess and it is *not* my fault that it is
a mess. Those who think they can implement sophisticated grep ( which
will accept cat some.file | grep -v element | go ahead ) in *not* messy style
*without* xt:evaluate - I suggest to look at grep.xsl from Ux distribution
( and do it better, if you can ).

> > My conclusion on Eric's suggestion is: even it is logically consistent, implementing
this in the core is more serious disaster to the engine than implementing xt:evaluate
*and* I don't see any benefits comparing to the benefits of xt:evaluate.
>
> Again, I am not sure it's that difficult to implement...

I agree, that you can specify it in the way that will be easy to implement.
I doubt it will be useful, being specified that way. How do you generate
that 'nodeset' of the stylesheet ? I mean when you have transform( xml, xsl ) -
how do you produce xsl ? How do you pass the parameters to xsl
producer? Eric, it is complex and messy, when xt:evaluate is simple.

If you think transform is more powerfull - could you write grep in that
transform style? I'm in easier position than you. I have a particular example
( grep ) and I see that xt:evaluate is the best possible solution for this
particular example. Those who have no particular examples - they
can only *guess* what is good and what is not ;-)

> Anyway, I was just trying to find a bridge between your request and
> James' answer !

Eric - thank you, but I don't think that really good technical
solution ( xt:evaluate ) should be sacrificed for the sake of
any 'political' issue. ;-)

Maybe I'm blind, but now ( 1 day after discussion has started )
I'm *absolutely* sure that throwing away evaluate ( and doing that in
inconsistent manner, because similiar things are allowed in other
parts of XSLT ) was a design mistake with almost no rationale
behind it.

If there is some rationale - where is the rationale?

Rgds.Paul.

--
Mailing list for the XT users community.     (http://mompreneursonline.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)



Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET

webmaster@4xt.org