Michael Kay wrote:
What would it offer over and above doc() and xml-over-http ?
I think the challenge is that simple RESTful services can
indeed be done using doc(), and anything more complex gets you
into issues of side-effects. But Florent Georges and others
are working on ideas, and I'll be more than happy to support
them if they produce something good.
Thanks, Mike. But clearly, REST cannot be supported by doc().
You can issue simple GET requests, but REST is based on more
HTTP verbs than GET. Not mentioning headers yet.
And once you have the technical tools to issue general HTTP
requests, you can go further and provide libraries that wrap such
requests within a more simple API (dedicated to REST WS, SOAP WS,
Google APIs, etc., taking care of authentication based either on
standard or proprietary headers, OAuth, OpenID, etc.)
Aside being able to write web services clients in XSLT (and
other XML technologies like XQuery and XProc), there is also the
interesting possibility of writing web services themselves using
those technologies. And again the principle is the same:
providing the technical tools to write a stylesheet to respond to
HTTP request (so the other way around: on the server), then
building up on those tools more specialized frameworks (XRX, REST
WS, part of the WS-* stack, etc.)
And yes, side-effects are a key point. I think XSLT has all
the machinery to handle them (like the output state) and XQuery
will have too (with XQuery SX). But the output state is maybe
too much restrictive (e.g. regarding function calls); for now,
just using the HTTP Client naively has showed up to not cause any
problem.
Rendez-vous in XML Prague for more information ;-)
Regards,
--
Florent Georges
http://www.fgeorges.org/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--