A further way to access the static context base URI is:

4. fn:resolve-uri

http://www.w3.org/TR/xquery-operators/#func-resolve-uri

"If the base-uri property is not initialized in the static context an error is
raised [err:FONS0005]."

By far the most common use of the static base URI in practice is to resolve
relative URIs passed to the doc() function. This will fail if no static base
URI has been established.

Good point.  

Would you agree that it might make more sense if element node constructors were
to follow the same logic as document nodes?  i.e.

"base-uri is taken from base URI in the static context. If no base URI is
defined in the static context, the base-uri property is empty."

I can't be certain, but I suspect the intended meaning for element constructors
was the same as for document constructors: the base URI of the element is the
same as the base URI in the static context, which means it's
null/absent/empty/undefined/none if the value in the context is
null/absent/empty/undefined/none. (I wish I understood which of these terms we
should use...)

One could argue that this code isn't "using" the value of the static base URI,
it's only copying it...

It could probably be clarified, except that when you go near base URI,
something always breaks.

(Action ACTION A-344-03)

As expected, the more you dig into this the deeper the hole you find yourself
in.

Firstly, I think that XDM should make it more clear that the base URI of a node
may be unknown. In practice this is common, it happens whenever you parse an
XML document supplied as a string in memory. The possibility is also recognized
(more or less) in the Infoset. This seems to require changing (or clarifying
the meaning of) section 6.1.3 where it says "The following infoset properties
are required: [children] and [base URI].". XDM allows the base-uri() accessor
to return (), and we should make it clear that this is what happens when the
base URI property of a node is unknown.

Secondly, XQuery needs to make it clear (as suggested in the bug report) that
for element nodes as well as document nodes, if the static base URI is unknown
then the base URI of the constructed node will be unknown. (I think "unknown"
is a better term here than "empty", which is the term used for document node
constructors.

In fact, there are many, many places in XQuery and XSLT where the base URI of
one thing is taken from the base URI of another. We really don't want to change
all these places to say explicitly that if the first base URI is unknown then
the second base URI will also be unknown. I think it would be best to say it
once, and a good place seems to be XQuery 4.5. Change:

"It is not intrinsically an error if this process fails to establish an
absolute base URI; however, the base URI in the static context is then
undefined, and any attempt to use its value may result in an error
[err:XPST0001]."

to

"It is not intrinsically an error if this process fails to establish an
absolute base URI; however, the base URI in the static context is then
undefined. When the base URI in the static context is undefined, any attempt to
use its value to resolve a relative URI reference will result in an error
[err:XPST0001]. When the base URI of a constructed node is taken from the base
URI in the static context and the latter is undefined, then the base URI of the
node will be unknown."

This makes the current sentence in 3.7.3.3. 4(a) redundant.

I've looked through XSLT to see whether the same changes need to be made there.
Frankly, I don't think it's necessary. There are many places where the base
URIs are copied from one place to another and I think it's reasonable for
readers to infer that if the source base URI is unknown/undefined then the
target base URI will be unknown/undefined.

This bug was discussed by the working groups on 8 Jan 2008. The working groups
agreed to amend the final paragraph of XQuery Section 4.5 (Base URI
Declaration) as suggested by Michael Kay in comment #5. This bug report remains
open pending possible additional changes to the Data Model specification.
--Don Chamberlin (for the XQuery and XSLT working groups)

Anders has stated that he believes no change is needed to the XDM
specification. 

I'm not comfortable with this.

In 6.1.1 and 6.2.1 we say "base URI, possibly empty" which is fine.

But in 6.1.3 (construction from an Infoset) we say:

The following infoset properties are required: [children] and [base URI].
The following infoset properties are optional: [unparsed entities].

with similar text in 6.2.3 and 6.5.3

This gives the strong impression that when creating an XDM document from an
InfoSet, there must be a base URI, and I don't think this is the case. I don't
think it's good enough to argue that "required" leaves open the possibility of
the value existing but being empty; if we want to make that kind of subtle
distinction then we need to be a lot more formal.

The Infoset spec does not explicitly discuss that the [Base URI] property can
be absent or unknown, but it is clearly something that can happen in practice.
I think XDM should make it clear, in discussing construction from an Infoset in
the sections cited, that if the infoset [Base URI] property value is absent or
unknown (these are the terms Infoset uses) then the XDM property will be empty.

Proposed change to XDM:

6.1.3. 

[I'm not entirely sure what the spec is trying to say when it says that some
InfoSet properties are required and others are optional. Is it a statement
about the InfoSet, or about the process of construction from an InfoSet?]

Change

<old>
The following infoset properties are required: [children] and [base URI].

The following infoset properties are optional: [unparsed entities].
</old>

to

<new>
The following infoset properties are used: [children], [base URI], and
[unparsed entities].
</new>

Under "base URI" change

<old>
The value of the [base URI] property. Note that the base URI property is always
an absolute URI (if an absolute URI can be computed) though it may contain
Unicode characters that are not allowed in URIs. These characters, if they
occur, are present in the base-uri property and will have to be encoded and
escaped by the application to obtain a URI suitable for retrieval, if retrieval
is required.
</old>

to

<new>
The value of the [base URI] property, if available. Note that the base URI
property, if available, is always an absolute URI (if an absolute URI can be
computed) though it may contain Unicode characters that are not allowed in
URIs. These characters, if they occur, are present in the base-uri property and
will have to be encoded and escaped by the application to obtain a URI suitable
for retrieval, if retrieval is required.

In practice a [base URI] is not always known. In this case the value of the
<b>base-uri</b> property of the document node will be the empty sequence. This
is not intrinsically an error, though it may cause some operations that depend
on the base URI to fail.
</new>

6.2.3: Make the corresponding changes

6.5.3: Make the corresponding changes

Extract from the minutes of telcon 358:

>J3.1.1 Bugzilla Bug 5207, [XQuery] Accessing
>undefined static context base URI and XPST0001
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=5207
>
>Status: READY FOR DISCUSSION
>See http://www.w3.org/Bugs/Public/show_bug.cgi?id=5207#c8

Mike Kays proposal in c8 discussed.

Decided to accept adding "if available" in first paragaraph.

Also retain the "In practice..." paragraph.

Changing "required" to "used" was rejected.