[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A proposal:xsl:result-document asynchronous attrib
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|