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.

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.

 > If it isn't (for example,
> if it is simply a string in a Java program) then the initial base URI will
> be undefined, and that any attempt to access it will be an error. However,
> an alternative approach would be to use the "current working directory" if
> the operating system has such a concept. Many JAXP implementations adopt
> this approach, but I think it's a bit questionable.

Perhaps it's more questionable in terms of the specification, but
"current working directory" seems less problematical.

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?

An implementation could try a "search path":
1. If the query has a known URI, use its URI as the base-uri.
(As I mentioned, this may need some tweaking in the case of
separate compilation and execution.)
2. If current working directory is defined, try that.
3. Otherwise signal an error.

A factor is that fn:resolve-uri("") is supposed to return the base-uri.
That means the above "search" has to be done independently of a
specific document being searched for.  It appears that Java's resource
searching doesn't let you do that: you can get a URL for a specific
(found) "resource", but nothing corresponding to a "base-uri".  In
Qexo I use a special magic URI like "class-resource:/foo/bar" for a
query that gets compiled into a class "foo.bar".
-- 
	--Per Bothner
http://xquery.com/mailman/listinfo/talk   http://per.bothner.com/