[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A proposal:xsl:result-document asynchronous attrib

Subject: Re: A proposal:xsl:result-document asynchronous attribute
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Mon, 10 Mar 2003 09:55:35 +0000
post idempotent
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.