[xquery-talk] default base-uri?
mhk at mhk.me.uk
Sun Jan 8 23:42:34 PST 2006
> > I would expect that if the query is read from a resource
> that has a known
> > URI, then that URI will be taken as the base URI.
> That's what I would expect too. Unfortunately, it may be meaningless,
> wrong or unavailable if a query gets compiled and then "deployed"
> in a different location or machine.
That, of course, is the general problem with relative URIs. The assumption
when you use relative URIs is that they represent links within a family of
related resources that when they are moved, will be moved en-bloc, retaining
their internal relationships.
> In the Java world one approach is to view fn:doc("foo.xml") as
> accessing a "resource" named "foo.xml" and so look for "foo.xml"
> using the ClassLoader of the compiled code. That what I'm trying
> in Qexo.
You can try this, but I think it's likely to lead to difficulties. I think
it would be architecturally cleaner to use a (so-called) absolute URI for
this, such as "classpath:///foo.xml"
> It seems like an implementation could provide the "current working
> directory" as the default base-uri. Or would that be against the
> letter or spirit of the specification?
There's only one base URI for a query, and for resolving some relative URIs
(for example, module URIs) it has to be known statically. Having a base URI
that's determined dynamically is likely, I think, to get you into some murky
> An implementation could try a "search path":
I like the idea of a search path, and advocated use of the concept in a
number of areas such as resolving function prefixes and collations. But
people felt it was stretching the web architecture too far. URIs, and the
mechanism for resolving relative URIs, were designed for hyperlinking. We
almost certainly need better indirection mechanisms for some of the things
XSLT and XQuery are trying to do, but I think it's a mistake to try and
stretch URI concepts too far from their origins in the architecture of the
Remember that given an absolute URI, you can dereference it to a resource
any way you like. But with a relative URI, there are rules about how it is
resolved against a base URI before it can be dereferenced, and in that area
you have less flexibility.
More information about the talk