[xquery-talk] default base-uri?
per at bothner.com
Sun Jan 8 17:03:08 PST 2006
Michael Kay wrote:
>>>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.
That assumes the URIs name "resources" that are part/bundled with the
"application". The other model is when you want to name the "data" for
the application. In an environment where there is a "current directory"
one assume that a relative pathname (traditionally filenames but could
be generalized to URIs) is relative to that directory.
>>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
> 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"
I do use an absolute URI. If (say) "app/query.xq" compiles to the Java
class "app.query" then the default base-uri is:
If you resolve "foo.xml" you get "class-resource:/app/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
I agree you have to have a static URI more module and scheme imports.
One could probably use a different, dynamic, URI for dynamic lookups.
Even if that doesn't follow the specification, it may be a practical
>>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.
Yes. That is why Qexo's "magic" class-resource: URI scheme is used for
A partial tentative conclusion is that one can use a default base URI
that is "magic" (implementation-specific), as long as it is absolute.
But that doesn't quite answer the question of what this magic URI
If the execution environment differs from the compilation environment,
then one may want a relativization mechanism. I.e. if I compile
"../a/b.xq" relative to the current compilation directory, then
"foo.xml" when resolved at run-time should probably resolve to
"../a/foo.xml" - relative to the execution environment's current
directory. One could handle using (say) "lookup:../a/b" as the
This handles the case of "resources" - but for "data" one may
not want to relativize against the compilation path. Hence,
perhaps "lookup:" may need to look at multiple places.
Clearly there is no "right" answer ...
per at bothner.com http://per.bothner.com/
More information about the talk