W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2015

[Bug 27908] K2-SeqDocFunc-12

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Dec 2015 15:24:45 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27908-523-J7yUsxQ39p@http.www.w3.org/Bugs/Public/>

--- Comment #7 from Michael Kay <mike@saxonica.com> ---
The minutes of yesterday's telcon record "Mike Kay to resolve bug 27908 after
verifying that FODC0005 should be allowed for K2-SeqDocFunc-12."

The sense of the meeting was that I ought to look at it carefully again before
closing it in this way.

Looking first at the original query, K-SeqDocFunc-12, there seem to be three
possible things that might happen.

(a) the doc() function is not evaluated, because $fileToOpen//* is an empty
sequence. In this case the result of the query is an empty sequence.

(b) doc() is loop-lifted out of the predicate, is evaluated as doc(""), and
succeeds. The string "" is a valid relative URI, the test suite documentation
says that the base URI of the query is that of the containing XML document, so
the resolved URI is the URI of the metadata file fn/doc.xml, and doc("") will
return the content of this file. In this case the query again returns an empty

(c) doc() is loop-lifted out of the predicate, is evaluated as doc(""), and
fails. I don't think this should happen. The test suite documentation says
(under "Accessing Source Documents") "Source documents (including XML files and
text files) accessed by a query are generally described as part of the
environment... There are a few exceptions to this rule..." I think the
implication of the test suite documentation is that if a call on doc() is
executed with a URI that points into test suite filestore, it should
successfully retrieve the file identified by that URI. There are other tests
that assume this behaviour, for example all the tests in app-CatalogCheck.

So I don't think that the call on doc() should fail even if it is loop-lifted
(and as stated earlier, I think it's poor practice to loop-lift it anyway).
Therefore I want to push back on allowing FODC0005 as a valid result for this

Now consider the two tests fn-doc-038 and fn-doc-039 which were added in
response to this bug entry. (They are mis-dated 2007. I have re-dated them
2015-01-28, which is the date of the comment reporting their addition to the
test suite).

Despite my comment 5, I think it would be very undesirable for an
implementation to actually evaluate the call on doc() in either of these two
tests. However, expressions in predicates are not protected from evaluation in
the same way as expressions in conditional expressions and typeswitch clauses
(and that's a conscious WG decision). So I think we are obliged to allow
FODC0005 in the case of fn-doc-038, and FODC0002 in the case of fn-doc-039. I
have made these changes.

I am leaving the bug open for further WG review.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 2 December 2015 15:24:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 December 2015 15:24:51 UTC