[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Jenni,
Jeni Tennison wrote:
Francis.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] A proposal:xsl:result-document asynchronous attribute
Subject: Re: [xsl] A proposal:xsl:result-document asynchronous attribute From: Francis Norton <francis@xxxxxxxxxxx> Date: Mon, 10 Mar 2003 17:34:56 +0000 |
Hi Jenni,
Jeni Tennison wrote:
How could xsl:result-document *not* cause changes on the server?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).
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.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.
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.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).
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.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.
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.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,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.
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.
Francis.
-- "Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] A proposal:xsl:result-doc, Jeni Tennison | Thread | [xsl] Re: A proposal:xsl:result-doc, Dimitre Novatchev |
RE: [xsl] Xpath patern question, Hélder Sousa | Date | [xsl] XPATH simple question, Oscar |
Month |