[xquery-talk] default base-uri?

[Per Bothner]

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
>>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"

I do use an absolute URI.  If (say) "app/query.xq" compiles to the Java
class "app.query" then the default base-uri is:
   class-resource:/app/query
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
> territory.

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
extension.

>>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
> web.
> 
> 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
abolute URIs.

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
should behave.

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
base uri.

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 Bothner
per at bothner.com   http://per.bothner.com/