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.
A silly extension to this would be to enable a variable
to be incremented.
I'd speak against this, and for keeping the side effect free nature
of XSLT.
An XSLT processor does not act in isolation;
I agree. Equally I'd like to see other W3C recs built up on
clean implementations of other recs. Not to screw up rec 1 simply
for the convenience of rec number 2.
I think it is worth it.
I think its a route to spoiling a good tool.
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.
Wholly agree. I firmly believe that the idea of limiting
its functionality in rev 1.0 was right. 2.0 is now building
on that. I won't go into the mess being created by the query mixup.
I find that another case for seperation.
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 an implementor wants to take a clean XSLT implementation,
and build on it for the above purposes then fine. Don't mess up
a good tool for other purposes.
My 2 Euro's.
regards DaveP.
*** snip here ****
-
NOTICE: The information contained in this email and any attachments is
confidential and may be legally privileged. If you are not the
intended recipient you are hereby notified that you must not use,
disclose, distribute, copy, print or rely on this email's content. If
you are not the intended recipient, please notify the sender
immediately and then delete the email and any attachments from your
system.
RNIB has made strenuous efforts to ensure that emails and any
attachments generated by its staff are free from viruses. However, it
cannot accept any responsibility for any viruses which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list