[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 Francis and Kurt, Kurt wrote: > I'd second Francis's note on the idempotency issue. Consider the > canonical HTTP GET based web service - the stock market ticker. Such > a service will be returning a different result set at any given > moment in time, to an extent that you could effectively argue that > time itself becomes a parameter in any such service, regardless of > the specific implementation. My experience with web services is that > most meaningful web service results vary with time. As designed, the document() function will only GET such a document once, so the result of calling the document() function with a particular URL is always the same. Of course if you run the transformation several times you will get different answers each time, but within a transformation, there aren't side-effects. Francis wrote: > How could xsl:result-document *not* cause changes on the server? and Kurt wrote: > Likewise, <xsl:result-document> WILL cause changes on the server. > It's difficult to determine from the specification what happens when > an XML document is posted to an external location, but at the very > least the assumption is that you are creating an XML document at > that point, probably via HTTP PUT via WebDAV. To be facetious, <xsl:result-document> doesn't necessarily create a physical document -- it just creates a result tree, identifiable via the URL specified in the href attribute, that the processor must make accessible to whatever processes are managing the transformation. So <xsl:result-document> wouldn't cause any changes on the server if you ran the transformation and then immediately dropped all the result trees from that transformation. Conceptually, <xsl:result-document> only causes changes to the server after the transformation is complete, when all the result trees are serialised. But, as with the main result tree, <xsl:result-document> you might have a streaming transformation and thus you may cause changes on the server during the transformation process. However, it's an error for you to try to access that document, so as far as the transformation is concerned, such changes are invisible, and thus the transformation is side-effect free. (Or as much as they can be: if the document were accessible via an alternative URL, I don't think that there'd be anything the processor could do to stop you accessing it. However, I think it's fairly clear that it's unwise to rely on this behaviour.) By contrast, POST is explicitly about making changes immediately -- that's its whole purpose. It would be impossible to wait to do all the POSTing until the end of the transformation, since that way you wouldn't get the results of the POSTs during the transformation. The situations are very different. Kurt wrote: > The WSDL architecture does not in fact make any distinctions with > regard to whether an HTTP GET is being used to query as opposed to > being used to update. It is quite permissible (albeit again not > necessarily "good practice") to have a web service invocation of the > form: > > http://www.myservice.com/updateValue?newValue=foo > > The argument that the document() function should be the primary > interface for such web services then contradicts the fact that you > are changing state on the server; if this holds true for document(), > then it should be just as permissible for <xsl:result-document>). I think that's it's reasonable for us to allow bad practice (using GETs for unsafe and unidempotent requests) in order to support good practice (using GETs for safe and idempotent requests). I don't think that it's reasonable for us to support bad practice (using POSTs for safe and idempotent requests). Francis wrote: > 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. and Kurt wrote: > One of the major flaws in the XSLT 1.0 spec was that there were a > great many number of features than became incorporated into the spec > that were intended to prevent people from doing "dangerous" things - > the creation of XML fragments, for instance, rather than allowing > the creation of intermediate node-sets. The fact that most > implementations built work arounds for these limitations indicate to > me that far from being dangerous functionality, the attempt to > protect programmers from their own stupidity was itself pretty > misguided. I disagree, but I suspect that's because I'm not facing the real challenges of using XSLT with SOAP messaging day-in day-out whereas I do deal with questions from newcomers to XSLT (often confused having come from a procedural programming background) day-in day-out. Basically, I don't think that it's XSLT's job to perform any actions aside from transformations. POSTing is an action that should be taken by the surrounding application, with the results passed into the transformation. Francis wrote: >>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. So you would be happy with the situation where, given the variable declaration: <xsl:variable name="foo" select="post($myURI, $myMessage)" /> You could have something like: <xsl:if test="$foo"> <result> <xsl:copy-of select="$foo" /> </result> </xsl:if> and have the $foo that was tested be different from the $foo that was copied? Not to mention the fact that having such a post() function return different results each time would mean that processors couldn't perform the optimisations they could otherwise. Francis wrote: >>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. I have been pretty much convinced by Paul Prescod's arguments that this is how idempotent web services *should* be designed. It seems that the designers of SOAP 1.2 agree. Reality may be very different, but I'd be very concerned about adding functionality to XSLT whose only purpose was to support bad practice, no matter how common this bad practice might be. > Here is another example, albeit one that I'm sure will raise more > than a few hackles: > > <xsl:apply-templates select="$myContext/{$anXPathExpression}"/> > > This structure is illegal in both XSLT 1.0 and 2.0, no doubt because > the cost of multiple evaluations of XPath context add overhead to > the work involved in the parser. However, such an expression has a > lot of potential usage, for instance, designing an XSLT processing > template in which the details of a given XML "record" are not known > until the time of evaluation, utilizing an external configuration > file to determine what makes up the requisite records, identity > attributes, and so forth. The fact that such a feature does exist in > the Saxon parser (and I believe in EXSLT, though obviously I may be > wrong here) indicates that it has utility that may outweigh its > "potentially" disruptive effects. I am in absolute agreement that dynamic evaluation of strings as XPath expressions is incredibly useful. It is something that I have argued for in the past. The dyn:evaluate() function defined in EXSLT is currently supported in Xalan-J, 4XSLT and libxslt. > In a related vein, there has been an implicit assumption that the > href value in the <xsl:result-doument> contains either an http: or > file: protocol, but I'm not necessarily sure that this is a valid > assumption. Suppose that you had the following construct: > > <xsl:result-document href="mailto:{url}?subject={subject}"> > <html> > <body> > <xsl:copy-of select="body"/> > </body> > </html> > </xsl:result> > > Is this construct invalid? It's possible it may be unsupported, of > course, but this is just as true of an http: protocol message. There is nothing in the XSLT WD that says that the URI must use the file or http protocol. The spec says: "There may be implementation-defined restrictions on the form of absolute URI that may be used, but the implementation is not required to enforce any restrictions. Any legal relative URI must be accepted." As I pointed out above, the URI is really just an identifier that the implementation uses to label the result tree. The application controlling the transformation can do what it likes with the result trees, including posting them (via HTTP or email). If the processor is in charge of serialising the result tree, the spec says: "The location to which result trees are serialized (whether in filestore or elsewhere) is implementation-defined (which in practice may mean that it is controlled using an implementation-defined API). However, these locations must satisfy the constraint that when two result trees are both created (implicitly or explicitly) using relative URIs in the href attribute of the xsl:result-document instruction, then these relative URIs may be used to construct references from one tree to the other, and such references must remain valid when both result trees are serialized." It's really up to the implementation what it does with the result. I think it would be perfectly reasonable for an implementation that recognises a mailto URI to email the tree as XML, or an implementation that recognises an ftp URI to upload the tree as an XML document. By the way, I'm arguing about this here because these comments have been posted to XSL-List. If you want to make a comment or suggestion about the WD that will be read by the members of the XSL WG, you should post it to public-qt-comments@xxxxxx, or let me know if you'd like me to forward your message there. 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
|