document-uri(X) is required to return a URI u such that doc(u) is X. It has nothing to do with base URI. I guess one could invent some algorithm whereby dynamically-generated documents have a unique document-uri generated, and this document-uri/document pair is dynamically added to the set of Available Documents in the dynamic context. This might just about be conformant, but it's certainly not the way things are intended to work. 

XDM §5.4 says "The dm:document-uri accessor returns the absolute URI of the resource from which the Document Node was constructed", and in this test case there is no such resource or URI, so document-uri() should be null/empty.

Maybe I'm missing something, but in the fn:parse-xml section in F&O we write:

<quote>
The Static Base URI property from the static context of the fn:parse-xml function call is used both as the base URI used by the XML parser to resolve relative entity references within the document, and as the base URI of the document node that is returned.
</quote>

Doesn't that mean that the base URI from the static context *becomes* the document URI of the returned document node?

Or are you suggesting we have a bug here and the spec is overspecifying something that ought not be set this way because here "document-uri(X) is required to return a URI u such that doc(u) is X" will clearly not hold?

In fact, I think we even make this specific, in F&O on fn:document-uri we way in a Note:

<quote>
In the case of a document node $D returned by the fn:doc function, or a document node at the root of a tree containing a node returned by the fn:collection function, it will always be true that either fn:document-uri($D) returns the empty sequence, or that the following expression is true: fn:doc(fn:document-uri($D)) is $D. It is ·implementation-defined· whether this guarantee also holds for document nodes obtained by other means, for example a document node passed as the initial context node of a query or transformation.
</quote>

So: "It is ·implementation-defined· whether this guarantee also holds for document nodes obtained by other means".

But that does not answer whether the description of fn:parse-xml makes it mandatory or not, or implementation-defined to set this "resource URI".

The base URI of a node plays no part in determining its document URI.

Many documents can have the same base URI, and frequently do. It is not possible for two distinct documents to have the same document URI.

I think I see it now, I was confusing the document-uri with the base-uri in the spec texts. That said, we do say that whatever the document-uri is in this case is implementation-defined:

<quote>
It is ·implementation-defined· whether this guarantee also holds for document nodes obtained by other means, for example a document node passed as the initial context node of a query or transformation.
</quote>

So, an implementation could, for instance, use a base-uri equal to the base uri of the static context and (may) add some kind of uniqueness (say, generate-id($doc), or whatever) to create an identifiable and unique document-uri.

I don't agree however that "It is not possible for two distinct documents to have the same document URI.", simply because I believe the spec says otherwise, see quote above and in comment#3.

Perhaps that particular Note is not specific enough?

>I don't agree however that "It is not possible for two distinct documents to
have the same document URI."

We guarantee that document-uri(D) = "X" implies doc("X") is D, and we guarantee that two calls on doc with the same argument deliver the same document. These guarantee cannot be met if there are two documents D and E such that document-uri(D) = document-uri(E) and not(D is E).

(In reply to Michael Kay from comment #6)
> We guarantee that document-uri(D) = "X" implies doc("X") is D, and we
> guarantee that two calls on doc with the same argument deliver the same
> document. These guarantee cannot be met if there are two documents D and E
> such that document-uri(D) = document-uri(E) and not(D is E).

If so (and don't get me wrong, I understand your reasoning and it makes sense), we should say so, because we now say something different in the spec.

Section 2.6 fn:document-uri makes an explicit exception for documents not retrieved through fn:doc or fn:collection (see comment#3).

Section 14.6.1 fn:doc allows leniency at user option, or allows FODC0003 to be raised if the deterministic guarantee does not hold if such an option is not available.

I am requested that this bug be added to the agenda

As discussed at today's telcon, changing this bug to a spec bug.

As discussed at today's telcon, we came to the conclusion that fn:parse-xml MUST normatively return a document with absent document-uri, as is written in the current version of the spec.

On the perceived discrepancy with fn:document-uri: the fn:document-uri MUST return the empty sequence if the document-uri is absent (as per the data model and the document-uri accessor).

Conclusion: both test and spec are sound, no action needed.