Future XSLT extensions. document(). Summary.

I'm sorry if this letter is disturbing, but I think I should write a summary, 
because as a private correspondence shows - definately, some points 
from my previous letters were expressed in fuzzy way. 

I'm not commenting on  ECMA-script and / or JNI / CORBA 
stuff ( not because it is not reasonable, but because 
it is another problem domain ).

Also not commenting on the possible unified node-set
world ( not because it is not reasonable, but because it is 
another problem domain ).

Just expanding the sentence: 

"The proposal was to bring the node-set typecast into the core
and then rethinking the semantics of all the functions returning 
node-sets and in particular document() function".

A. 
----

Things added to the core:

1. to-nodeset ( string )
2. to-string ( node-set  ) 

B. 
----

Features under Consideration for Future Versions of XSLT (Non-Normative)

* allow for result tree fragments all operations that are allowed for node-sets;

becomes true  ( including the to-string( r-t-f  ) )

C. 
-----

The semantics of document() is reduced to:

node-set document(URI) 

I wish document (" ") hack goes away, because there will be 
no actual need in it, I think, most of the things could be done 
with the variables, because of (B) - but that looks optional to me....
.... Maybe there is realy some person using old assembly language
tricks with XSLT .... 

I agree that (C) may be too strong.  I'm sorry, but I see it this way. 

I would like to get some examples of why document(URI) *only* 
it is not enough. I think the desired extra functionality could be 
achived in more natural fashion with the help of  A and B or 
should go to some other function. 

Rgds.Paul.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list