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

Dear Liam:
Thank you for your comment.  The Joint WGs discussed this on 4/13/2004
and decided not to add the functionality requested.  Norm Walsh said
that such a function should be provided by the system you are running on
and not XQuery.

I trust this is satisfactory.

All the best, Ashok

-----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Liam Quin
Sent: Thursday, March 04, 2004 10:28 AM
To: public-qt-comments@w3.org
Subject: [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 Monday, 19 April 2004 08:35:17 UTC