This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The query in this test case is: ends-with(document-uri(),"works-mod.xml") We expect true, but I believe that false should be accepted as well. document-uri is always allowed to return the empty sequence. 5.4 document-uri Accessor, in Data Model, says: "The dm:document-uri accessor returns the absolute URI of the resource from which the Document Node was constructed, if the absolute URI is available. If there is no URI available, or if it cannot be made absolute when the Document Node is constructed, or if it is used on a node other than a Document Node, the empty sequence is returned."
>If there is no URI available Your reading of this is more liberal than mine. You interpret it as "document-uri is always allowed to return the empty sequence"; I interpret it as "there are some situations in which no information is available about the URI associated with the document, for example when it was supplied as an input stream or as a DOM in memory. In such cases, document-uri is allowed to return the empty sequence." In this case the catalog contains a URI for this document and I think an application/processor can reasonably be expected to treat this URI as being "available".
Michael, I agree that we want implementations to behave as you describe in comment #1. I'm looking now at the note at the end of section 2.6, fn:document-uri: "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." The first sentence describes behavior for both fn:doc and fn:collection. I suggest that these two cases should be separated. Add the following sentence to Rules: "In the case of a document node $D returned by the fn:doc function, it will always be true that the following expression is true: fn:doc(fn:document-uri($D)) is $D." Change the Note to read: "In the case of a document node $D 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."
You're saying that this always holds: fn:doc(fn:document-uri($D)) is $D I'm wondering how this relates to: Such functions (as fn:doc and fn:collection) are guaranteed to be ·deterministic· with the exception that an implementation is allowed to make them non-deterministic as a user option. If doc() is non-deterministic, does the guarantee still hold? I think not. And I'm wondering how it relates to XSLT streaming. I think the answer is that in general, with streaming, our intent is that you can't ask the question whether two streamed nodes are the same node. But actually, I can't see that the streamability rules actually prevent you using the expression fn:doc(fn:document-uri(.)) is . In this expression the syntactic context of both occurrences of "." is an "inspection context" and therefore the expression is motionless, which means it is allowed in a streaming context. Perhaps we can fix this in the streamability rules. But I suspect that we're going to have to say that in a streaming environment, some of the determinism rules don't apply.
The part of section 1.6.4, Properties of functions, that you cite is troubling: "Such functions (as fn:doc and fn:collection) are guaranteed to be ·deterministic· with the exception that an implementation is allowed to make them non-deterministic as a user option." We haven't defined user options in our process model. We haven't defined the scope of this user option. Perhaps this user option should be added to the static context. With the use of this option, our "guarantee" is negated. Not much of a guarantee. My proposal certainly needs to be modified. The first sentence describes behavior for both fn:doc and fn:collection. I suggest that these two cases should be separated. Add the following sentence to Rules: "In the case of a document node $D returned by the fn:doc function, when fn:doc is deterministic the following expression is true: fn:doc(fn:document-uri($D)) is $D." Change the Note to read: "In the case of a document node $D at the root of a tree containing a node returned by the fn:collection function, when fn:doc is deterministic 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." XQuery 3.0, in section 2.1.2, Dynamic Context, says in a note in the definition of Available documents: "This means that given a document node $N, the result of fn:doc(fn:document-uri($N)) is $N will always be true, unless fn:document-uri($N) is an empty sequence." This should be changed to: "This means that given a document node $N, the result of fn:doc(fn:document-uri($N)) is $N will be true when fn:doc is deterministic, unless fn:document-uri($N) is an empty sequence." Another note in the definition of Available node collections will need to be modified in a similar way.
>With the use of this option, our "guarantee" is negated. Not much of a guarantee. If the spec for my electricity supply stated that the voltage was guaranteed to be within 1% of 240v unless I chose to select a tariff in which it was allowed to vary by 3%, I would regard that as a very solid guarantee. I can't see the problem: we put this rule in so that users who wanted to avoid the high costs of determinism were allowed to select a cheaper and less reliable service if they wanted to. We don't have to define the shape and colour of the switch by which they select this option: it's not our normal practice to put all implementation-defined and implementation-dependent parameters in the static or dynamic context. Determinism is particularly expensive in the case of streaming, because when data is arriving streamed say from a satellite the only way to achieve our determinism guarantees is to save a copy of the data either on disk or in memory just in case it is needed more than once. This in fact defeats the whole point of many streaming applications, which is to filter the data before storing it.
The WGs discussed this issue during our Oct. 2 meeting and decided not to change the expected result of this test case, nor to make any change to XQuery 3.0 and F&O 3.0. Some of the issues that were raised may be addressed in a future version of these specifications.