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


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

But this is very subjective!

I can read one XML file and get <xsl:variable name="secondxml" select="'filename'" /> (1)
out of it.

Then I can <xsl:apply-templates select="document( $secondxml )/some-node" /> (2)

The stylesheet is 'compiled' once, but the value of Xpath in (2) 'depends on the XML'

Was it possible to say : " document can *not* accept variable" ? Sure it was possible.

Why document() has no such restriction? I think that was because from the real-life
experience it was obvious that in some cases 'fixed document' will be a pain.

Exactly the same happens with xt:evaluate. Nobody was thinking about pipes.
I think I was the first person starting bulding complex pipes of stylesheets - and
I got the situations ( real life ) which show me that in this 'piped' universe
the importance of 'flexible Xpath' is much higher than it is in the absense
of pipes. Again, as i said - if throwing pipes away - xt:evaluate is very
optional.

If considering XSLT a tool for 'one XML -> one XSL' the document( $var )
is also very optional.

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

I'm now replacing 'pass variables with RTF with java buindings' with
'pass variables by SAX with Ux stream', so this another advantage
is not very appealing to me ;-)

I don't see the usecases when 'generate stylesheet into a variable'
is a way to go. As I said, I'm very stupid and I understand some things
only when I hit the particular wall. xt:evaluate is a solution for some particular
wall which I hit. The wall is a | grep some | go ahead. In the absense of Ux this
usecase will not appear, I think, so I will be thinking that 'generate the stylesheet'
is a good workaround.
  
> > 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.

I don't think it is bad to be political and I was not blaming you for
being 'poltician' ;-) I'm sure you are thinking about the technology
first of all ;-) Sorry for being not accurate with my wording - I think
you know that my English is terrible ;-)
  
> > 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 ?

Even I do - I think this is not a biggest problem now.

Yes, XT is Open Source. But xt:evaluate is not that trivial
to implement and implementing it without James' blessing
is to fork 2 branches of XT - I don't want to do that. It is not worth
the benefits.

Let me explain by example. Very long time ago ( 7-10 years? )
I was used to write a free open-source C++ browser. Because
at that point there was not a big number of such tools available
on the market, I got a big number of users. Of course, they were
submitting the requests for new functionality. When I was
receiving the request, not all of the requests were acceptable
from my point of view. When I received the request
which I thought shoud not be implemented, I usually wrote into the
mailing list that "I'l not do that because of this and that, but I think
you should solve your particular problem in this and that way ".
Sometimes that was enough, and user said : "yes, I can live with that".
But sometimes, somebody was explaining to me why the way I'm
proposing is not a solution from his point of view and ( rarely ) I got
convinced that there is some rationale behind this request.
When I had some time to implement that request myself I
just implemented that request - very simple. If the request was
not easy to implement and I had no time for it ( but I agree that
request is reasonable ) I wrote some brief roadmap how could
it be implemented by other person and if the person asking for
the feature had a strong desire to get the functionality - he
implemented the functionality and then submitted the patch
to me - after reviewing the patch I could make some changes
to the patch - and then I was including this patch into next release.

1. In any case there was no branching.

2. At least there was clear understanding on the status of some
request:

    "reasonable"
    "not reasonable because of this and that"

If xt:evaluate is not reasonable from James' point of view
( with at least one argument why it is not reasonable ) -
to me there is no point to implement it.

There is no point , for example, because it should be
not xt:evaluate but something-else:evaluate
( for legal reasons ).

In this case - why should it be something-else:evaluate?
It could be just saxon:evaluate.

Rgds.Paul.

--
Mailing list for the XT users community.     (http://cybersummit2011.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