Hi Jenni,
Jeni Tennison wrote:
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).
How could xsl:result-document *not* cause changes on the server?
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.
I sometimes think that language designs can become fetishistic about
things like idempotency (in the technical sense - a fetish being
something originally associated with an aim - good language design in
this case - which ends up becoming a non-functional [no pun intended]
substitute for the original aim). Useful languages end up having to deal
with things that change state. Even a "purely" functional language like
Haskell has monads. I think at the very least it would be useful to
report a success or error on executing the GET, and if you concede even
that then idempotency has gone for this function.
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).
That's true. I'd say bite this bullet, XSLT would simply document the
fact that there would be certain cases, for example inside
xsl:apply-templates or xsl:for-each, where execution order is guaranteed
to be uncertain and non-portable.
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.
Or just say that this function is not idempotent. Which, in reality, it
isn't - you might get a time-out one time and success the next.
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.
Except that assumes that all useful idempotent web services are
restricted to - and will in fact be implemented - using "flat" non-XML
queries that do not require any kind of nested structure. I have never
seen anyone make a convincing attempt to justify this assumption.
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.
I think there comes a time when you should draw a line and say there's a
useful, stateful XML world out there and we should find as clean a way
as possible to let XSLT users interact with it.
Francis.
--
"Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list