[F&O] LQ-FO-03 - extended access to URI resolver

F&O currently provides limited access to URL resolution via
fn:document() (section 15.5.4).

There's no support for HTTP POST, nor for MIME parameters,
nor for query parameters.

There's also no clear indication of a result code, nor access
to language or media type information, if available.

If resolution fails, or if parsing the resulting resource
representation as XML fails, a fatal error is raised.

In the absence of a try/catch mechanism, having URI resulution
failure be a fatal error means you can't probe for the existence
of a document.

I propose that we supply a resolve-uri function, and that document() be
defined in terms of resolve-uri.  This adds significant functionality to
XQuery without a large additional cost, because implementations already
have such a resolver.

The following proposal is a little half-baked right now.  I'm looking for
the minimum that would be enough for XQ to build on later.  I'm worried
that if we neither support Web Services directly nor open up the URI
resolver it'll be really hard to add WSDL support later - and also that we
may have problems with internationalized queries and content negotiation.

If there's interest, I'm prepared to work on making this a more
robust proposal.  Leaving it for a future version would be a
satisfactory response for me if file-exists() and some form
of WSDL support are defined.

*


function resolve-uri($uri,$method,$http-params,$uri-params)
resolves the given URI using the given method (GET, HEAD, POST, etc) if
appropriate, and with the given parameters, e.g. as key/value pairs for POST.
The URI parameters are a sequence alternating between a string and an item
(ewwww, or is it better to use
    <param><name>xxx</name><value>yyy</value></param>,
since the efficiency loss is minimal compared to the amount of I/O involved?)
They might go after a ? separated by ; or & for an HTTP GET, e.g.
    http://www.example.com/search.cgi?q=frog
The optional Mime parameters are in the same format, and are most likely to be
an Accept list (e.g. to generate Accept: text/*, application/*) but can also be
used for content negotiation to support internationalisation.

resolve-uri returns a sequence:
    (1) a result code, as per HTTP and (compatibly) FTP; for a file: URL,
    the only likely codes are 20x OK, 40x fail, or maybe 30x redirected.
    A code starting with a 2 indicates success.

    (2) a string, the URI actually fetched, which may differ from that
    requested, for example because of symbolic links/shortcuts or because
    of HTTP redirects

    (3) the MIME Media type

    (4) the result, which in the case of error may be the empty sequence
    or may be an (X)HTML document describing the error.  In the case of
    multi-part responses, the result may be a sequence of document nodes.


Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

Received on Thursday, 4 March 2004 13:30:35 UTC