[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: 29/08/2000 - 09:53

Paul,

Just a couple of thoughts about the necessity of the filename
trickery...

Basically, I don't understand why you can't set this parser only for
this purpose, avoiding testing for the filename.

If you are working at a text level, parsing a stylesheet stored
somewhere as a text, can't you use an EntityResolver instead ?

If your HackedXMLParser sends SAX events generated from variables or
context, couldn't you just install it through "setParser" without
needing any trickery on the name ?

Eric (confused)

your HackedXMLParser will send SAX events

Paul Tchistopolskii wrote:
>
> 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://ebiz-consulting.com)
> (mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe) 

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://bluegrasscommunitybank.com
http://advantageprocessors.com -           http://nationalassociationofwomen.com              http://thedukecigaretterollingmachine.com
------------------------------------------------------------------------

--
Mailing list for the XT users community.     (http://creditcardprocessingtravelindustry.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
A site designed by Dyomedea