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

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
<- Previous	Index	Next ->
RE: [xsl] Re: A proposal:xsl:result, bryan	Thread	Re: [xsl] A proposal:xsl:result-doc, Francis Norton
Re: [xsl] how to select elements ba, Wendell Piez	Date	Re: [xsl] Re: how to select element, Robert P. J. Day
	Month
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home
Re: [xsl] A proposal:xsl:result-document asynchronous attribute
