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: 29/08/2000 - 03:54
----- Original Message -----
From: James Clark
> > 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 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).
> > 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. 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?
Even I still think that xt:evaluate will result in more readable ( and
more 'compilable' ) code than "generate | execute" pattern, I think
I now see how to support "generate | execute" without any
changes to XT and I think I should write it down. Those who
are not yet familiar with basic XT APIs ( XSLProcessorImpl) are
better to skip this letter ;-)
So what I need is
some process | grep xpath | go ahead
In fact what I *really* need in 'grep xpath' node is to generate
some *new* stylesheet on the fly and apply that *generated*
stylesheet to the stdin which I get from 'some process'.
This could be written as :
some process | [ gengrep xpath ] | go ahead
This means that at some point I'l ask XSLProcessorImpl to
load the stylesheet with the name "[ gengrep xpath ]" ( in fact
there is no such stylesheet, but this is not a problem - see
below ;-)
The desired functionality is acheiveavble with good old
Ux ( and XSLScript ) trick :
- provide the HackedXMLParser extends CommentDriver.
- in parse( InputSource) method of HackedXMLParser look at
InputSource.getSystemId() if the 'file' to be processed
starts with '[' - there is generate | execute pattern invoked,
so instead of invoking super.parse( inputSource ) I should
create the new ( one more ;-) copy of XSLProcessorImpl in
SAX mode and bypass the SAX events, so that original
stylesheet loader thinks that it is loading some XSL file
( not existant, 'logical' file with the name "[ gengrep xpath ]" ).
It may be hard to understand - but this will work and no changes
to XT needed, everything could be done on the level of Ux. This
will result in better code of grep than I have now ( because
stdin / stdout will be kept ). Well, at least I understand
how to decrease my current mess ( placing the mess into
Ux code ;-) ....
Sorry if this is not clear - I don't know how to express it better ...
UxSpecialXMLParser shows how this trick works for XSLScript
( there is the same situation with XSLScript - XT is executing
XSLScript code, generating the XSL code on the fly .)
Rgds.Paul.
--
Mailing list for the XT users community. (http://naughty-xxx-links.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
|