[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 - 22:02

Paul Tchistopolskii wrote:
>
> > > 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.

Sorry I haven't been clear.
I meant like Dave said that it's one way and once you've 'compiled' your
transformation it becomes static and do not depend on the XML.
 
> 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 ).

It depends on what you need xt:evaluate for. In some cases, it can be
very powerful.
 
> > > 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.

Just like you can use XSLT to generate a XSLT stylesheet, but generating
it into a variable.
You could also pass RTF Java objects as parameters, giving way to other
applications.
 
> 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. ;-)

I wasn't trying to be political but I tend to value James' technical
judgment.
 
> 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?

I have no firm position on this...
Do you have a lightweight implementation in mind ?

Eric

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

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://advantageseoservices.com
http://merchantaccountforums.com -           http://merchantsolutionsgroup.com              http://travelagencymerchantaccount.com
------------------------------------------------------------------------

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

Archive générée par hypermail 2b28 le 01/06/2001 - 09:01 CEST

webmaster@4xt.org
A site designed by Dyomedea