Hi Kurt,
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.
Just to check: by "post" you mean use HTTP POST to the specified URL
with the content of the <xsl:result-document> as the body of the
HTTP request?
The big problem with using POST in XSLT is that it is neither safe (it
may cause changes on the server) nor idempotent (it may return
different results each time you make the same request). XSLT and XPath
are designed (for the most part; <xsl:message> is the exception) to be
side-effect free, such that if you have:
<xsl:variable name="foo">
<xsl:result-document href="foo.html"><foo /></xsl:result-document>
</xsl:variable>
it should not matter whether a processor evaluates the content of the
$foo variable declaration once or many times -- it should always
return the same result. Likewise, if you have two instructions, it
should not matter which is actually evaluated first (as long as their
results are composed in the correct order).
We *could* manage the multiple-evaluation problem in XSLT in the same
way we do for GET by saying that the result of two POST requests with
the same URL and deep-equal message bodies must be identical. This
would force implementations to cache and reuse the results of each
POST. I think that the ordering problem would be harder to manage, and
that it's likely to lead to subtle bugs due to different processors
following different evaluation orders.
There are applications that use POST in safe, idempotent ways, as a
GET-with-complex-arguments. However, SOAP 1.2 explicitly discourages
that practice, and I think that it would be a bad idea to base XSLT
functionality on bad practice. SOAP 1.2 encourages, instead, the use
of a GET request resulting in a SOAP message, and this is already
supported with the document() function in XSLT.
To summarise: if you're GETting, use document(); if you're POSTing,
you shouldn't be doing so within XSLT because it's not safe or
idempotent and therefore undermines the side-effect-free nature of
XSLT.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list