This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Future XSLT expansion. ( Re: Microsoft XSL and Conformance )
- To: xsl-list at mulberrytech dot com
- Subject: Re: Future XSLT expansion. ( Re: Microsoft XSL and Conformance )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Sat, 18 Mar 2000 10:02:09 -0800
- Organization: The Qub Group
- References: <NBBBJPGDLPIHJGEHAKBAAEHLFBAA.martind@netfolder.com>
- Reply-To: xsl-list at mulberrytech dot com
> Didier replies:
> Do you mean here that a vendor may choose to return text from a document()
> function and an other a node set? I guess that we are still talking within
> the boundaries of XSLT 1.0 recommendations.
1. There is no ( 'portable and standard' in your terms ) way to return
node-set from the extension.
2. If giving that way ( node-set typecast in the core ), having document()
function in the core will be like having 'send/recv' together with 'read/write'.
> Conclusion: Based on my experiments I discovered that the document()
> function is very useful. I just say that: useful. If you think this is not,
> the choice is obvious, do not use it.
Yes, send/recv in the perl core are also useful. And yes, I prefere not to use
suspicious places. Send/recv behavior in perl was a bit different comparing
to read/write, this caused big problems. The same happens with document() hack.
I think there is an impression that 'document()' implemented by current 'conformant'
XSLT engines, like XT is 'way to go'. I suggest to read changes, readme's and other stuff
to see what realy happens with that hack in different implementations.
Of course, that all not the problem. As I said before:
a. If you like send/recv + read/write in the core - you will not understand me.
b. I'm not using document() and many other things + because almost
everything could now be done with extensions, I don't care too much
about the problems XSLT core engine has.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list