Michael,
I've noticed in the current (Nov 2002) XSLT 2.0 specification the specific
provision for <xsl:result-document>'s return value is given as follows:
<snip>
Technically, the result of evaluating the xsl:result-document instruction is
an empty sequence. This means it does not contribute any nodes to the result
of the content constructor it is part of.
</snip>
I'd like to raise a use-case that may suggest that this needs to be expanded.
One provision that I can see for the use of XSLT 2.0 is in the generation of
SOAP messages for consumption in web services. Such messages could easily be
facilitated within the existing specification in those cases where the
message architecture is asynchronous (i.e., the SOAP message is sent as an
independent packet without expecting any return information), but it is not
terribly useful in situations where a need for a synchronous response would
be required.
I would like to propose that the <xsl:result-document> element be amended with
the creation of a new attribute *asynchronous* with values "yes" (default)
and "no". The behaviour with asynchronous="yes" would be as given in the
current specifications - the result of the command will be to place an empty
string into the output stream.
However, if asynchronous="no", then the processor would post the template
contents of the <xsl:result-document> element to the URL and retrieve the
result of that operation, which would then be placed into the output stream.
Note that the resulting message may very well be an soap fault, but this
would still be an XML message that can be parsed and manipulated. Errors
would be raised in precisely the same situations as would exist for the XPath
2 document() function.
I believe that this change would be easy to implement, and would provide
significant utility in the arena of web services using XSLT.
-- Kurt Cagle
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list