Saxon

This change is almost certainly due to the way in which we decided to solve the problem described in bug #4837 - we were returning a document-uri() for documents in situations where we could not guarantee that every document would have a unique document URI.

I haven't looked at the detail of your test case yet, but it's not a surprise that the design change causes some existing code to break. We made the change very reluctantly, but spec conformance always comes first.

Extracting the relevant information from bug #4837, the main problem is that by default in Saxon, the collection() function is not stable, while the doc() function is, which means that if you read the same collection twice, you can get two documents that have the same document-uri(), and this breaks the contract for document-uri(). But even if collections were stable, it's possible for two different collections to include the same underlying file, and there's no guarantee they will include the same version of that file; if both versions of the file have the same document-uri(), then there's no way of guaranteeing the basic equivalence that doc(document-uri($X)) is $X. The only resolution we could find is that documents returned by the collection() function should not have a document URI.

I do appreciate that we've made a change here that inconveniences users for what might seem rather pendantic conformance reasons. However, bug #4837 was not a theoretical problem, it was a real bug affecting a user-written application.

I wonder if base-url() or saxon:system-id() would meet the requirement?

OK, I will replace document-uri() with base-uri() everywhere.

For documents created in memory with xsl:document or temporary trees in general, the result of saxon:system-id() corresponds more closely to document-uri() than base-uri(), so I prefer saxon:system-id().