[
Lists Home |
Date Index |
Thread Index
]
Adam Turoff wrote:
> One of Joshua's comments got me thinking. Which is *more* broken:
> SOAP or XSLT? That is, is it a misfeature of XSLT that document()
> can't send SOAP requests, or that idempotent SOAP requests don't
> use a simple GET? I ask that rhetorically not to ascribe blame, but
> to understand the issue more fully.
>
> That leads to another question: is the lack of POST/PUT/DELETE
> support with XSLT simply an oversight? Or is there a well thought
> out reason why XSLT's document() function is limited to GET requests?
> (And should this discussion be added to the XSLT 2.0 REC?)
It wasn't really accurate to say that document() is limited to GET requests.
A URI in general doesn't convey the retrieval mechanism with any more
granularity than the scheme ('http', 'ftp', etc.), and that's only when the
URI is a URL. Remember it might be a URN. The idea is not to convey how to
retrieve the resource, but *which* resource.
If you just think of what a URI actually is, and think of the URI passed into
the document function as being an XML document's ID/name, rather than
necessarily being its address/location, it should be more clear why XSLT is
wise to leave the retrieval mechanism, and rules for URI resolution, up to the
implementation.
"How do you obtain a resource that is identified by a URI that is an HTTP
URL?" might as well be "How do you obtain a resource that is obtained by a URI
that is a URN that looks like urn:go-get-doc-number-12345?" as far as
document() is concerned; it doesn't care, and there's technically no
obligation to support *any* URI resolution. For that matter, an XSLT processor
is allowed to abort processing and raise an error if for any reason the
document function can't obtain the resource or produce a root node from it! :)
- Mike
____________________________________________________________________________
mike j. brown | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
|
