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: 25/08/2000 - 09:44
From: James Clark
> Paul T wrote:
>
> > If there is any probability to get xt:evaluate() in the XT core -
> > I'l dance and be the happiest person in the world.
>
> I would fight very hard to keep xt:evaluate out of XT (and XSLT). I
> think it misconceived and completely at variance with the design of
> XSLT.
Why?
Sorry for opening the can of something. I mean that I myself
was always feeling that evaluatable Xpath is 'evil' ( and I was thinking to
use the xt:evaluate hack very rare, not abusing it ). But I now
think that allowing variables in document() is *already*
evaluatable Xpath.
What is in fact document() ? Even it is not the part of XPath specs and
XSLT WD describes it in some fuzzy style, I think that it will be fair to say
that document( URL ) ( the form used by 99% of the stylesheets )
is a 'hidden' part of XPath. And it is *valid* to have document ( $variable)
but not only document ( "a.xml" ).
What is the critical difference between document( $filename ) and xt:to-xpath( $var ) ?
> > Current Ux grep is implemented in ugly 2-step transformation,
> > when first transformation generates the stylesheet-to-be-applied and then
> > stylesheet-to-be-applied gets executed.
>
> I don't think that's ugly at all. Using a stylesheet to generate
> another stylesheet to be applied is a very powerful and general
> approach, which XSLT was designed to support (via xsl:namespace-alias).
I'l say that without namespace-alias it is almost impossible task .... Right?
> I would much prefer to improve XT to make 2-step transformations more
> convenient and efficient (eg allow them to be done with one invocation
> of XT).
I think that before finding the most convnient way for 2-step transformations
in XT ( *not* easy to design ) it will be great to understand why evaluatable
Xpath is evil ( I still think it is not, but I may be wrong, of course, as I was
wrong with updateable variables AKA access by pointer ).
I may explain why I got a mess in my grep ( which is using namespace-alias,
of course ).
When I was *thinking* about this generate-and-run - it was very reasonable.
When I implemented version one
grep something filename
it was OK ( not a mess ). When I then added the support for
component1 | grep something | go ahead
it turned into mess ( because general generate | execute scenario
in the presense of standard input and output looks
not trivial to me ).
> > The third workaround is to drop
> > pipes and forget it all. Unfortunately, it is not a workaround to me - I can not >
drop pipes. They are extremely important entity.
>
> The 2-step process you describe a ugly seems to me to be exactly like a
> pipe.
I think it is not. It is kind of fork inside 'grep' node.
> There are two inputs to an XSL Transformation, a stylesheet and a
> source document; if the latter can come from the result of an XSL
> Transformation, why shouldn't the former also?
And what to do when both are needed?
I still think that with evaluatable Xpath everything remains clean,
clear and consistent. I could ve subjective, of course. What is clean
and what is not is subjective. When saying 'everything remains clean'
I mean that to me 'programm generates programm' is no less the
hack than xt:evaluate. I think 'programm generates programm' is
more hack. Harder to debug, for example.
Rgds.Paul.
--
Mailing list for the XT users community. (http://nedco-mesa.org)
(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
|