Re: Future XSLT expansion. ( Re: Microsoft XSL and Conforman

> 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