RE: [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).

I think you are referring to URI dereferencing rather than resolution. We
already have a resolve-uri() function that does URI resolution - this is
purely a synactic manipulation of a relative URI and a base URI.

# 
# 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 JAXP API defines a URIResolver that the user can supply to take a URI
and return a document. Microsoft have imitated this in .NET with their
XmlResolver class. This mechanism works perfectly well, and is abstracted in
our definition that the context provides a mapping from URIs to documents. I
think there are so many potential complexities in this area that this is the
right way to do it: we shouldn't try to bring it back inside the boundary of
the system.

Michael Kay

Received on Thursday, 4 March 2004 18:14:12 UTC