[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
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 26/08/2000 - 17:12

Hi Paul,

Paul T wrote:
>
> Back to the point.
>
> > Just my 2d worth (for Eric - I like that one Eric)
>
> I have messy feelings on Eric's proposal. On one hand what is says is :

I think Dave was just referring here the "My 0,02 Euros" with which I
use to end the messages in which I give a personal opinion ;=) ...
 
> XML ( aka data ) is node-set. XSLT ( aka code ) is also node-set. Very consistent ( but it is not 'really true'. The 'really true' thing is that 'on the level of lexer both are streams of SAX events - see below ;-)
>
> Turning string into Xpath with xt:evaluate is just a "generate the *small part* of the stylesheet on the fly", when Eric's suggestion means "generate the *entire* stylesheet on the fly".

More exactly, I meant generating A stylesheet (not THE stylesheet) on
the fly.

xt:transform-node-set(nodexml, nodexsl) would require 2 parameters which
can be any nodeset or maybe rather RTF and we could probably find many
more uses than a workaround for a xt:evaluate.

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

xt:evaluate would create kind of internal loops.

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

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

> What really happens inside XSLT engine is that *data* ( XML ) is compiled into one structure ( engine-specific node-set ), but *code* ( XSL ) is compiled into different internal structure. Yes, both code ( XML ) and data ( XSL ) have common 'access' with SAX when engine reads XML or XSL - both are turned into the stream of SAX events - but this 'common' happes only on the level of syntax parsing, not on the level of semantcis aka internal representation.
>
> 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...

Anyway, I was just trying to find a bridge between your request and
James' answer !
 
> I don't understand why generation of 'the entire stylesheet' is in any way better than 'generation of small part of the stylesheet == xt:evaluate" and I don't understand why xt:evaluate is evil.
>
> Rgds.Paul.
>
Best regards,

Eric 

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://keysbirdingfest.org
http://motomerchantaccount.com -           http://twitpay.com              http://motomerchantaccount.com
------------------------------------------------------------------------

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

Archive générée par hypermail 2b28 le 02/04/2001 - 19:28 CEST

webmaster@4xt.org
A site designed by Dyomedea