Hi Jenni and Francis,
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.
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.
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>).
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.
An XSLT processor does not act in isolation; it is usually part of a protected
(sandboxed) environment where certain actions, such as writing to a specific
URL to which the processer does not have permission, will generate errors
that can be caught by the processor. In some cases they may make for code
that is somewhat less efficient, but if the tradeoff is more flexibility then
I think it is worth it.
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.
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.
I'm falling into ranting mode, so I'll stop now, save for this one comment -
XSLT is perhaps the first XML based language for manipulating XML, and for
all the hype of vendors, it is still one of the best. However, the whole web
services infrastructure did not exist per se when XSLT 1.0 was finalized.
XSLT is a superb mechanism for state transition devices, for generalized XML
transformations, and for mediating XML streams - all important aspects of a
web services architecture. If the XSLT implementation is too timid, XML
developers will cease using it within the pipeline infrastructure in favor of
proprietary solutions, which will only lead to the fracturing of the W3C
standards and the increasing irrelevancy of XSLT.
My two cents,
Kurt Cagle
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list