W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2006

[Bug 3173] [F+O, DM] A difficulty with document-uri()

From: <bugzilla@wiggum.w3.org>
Date: Mon, 01 May 2006 20:39:14 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1FafAo-0003kW-SZ@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3173

           Summary: [F+O, DM] A difficulty with document-uri()
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators
        AssignedTo: ashok.malhotra@oracle.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The data model says that document-uri is a property of a document node.

F+O says that the document-uri() function returns the value of this property,
and guarantees that if it is not null, then doc(document-uri($A)) is $A.

These two statements seem contradictory. Does document-uri() look for a
property of the document node, or does it look in available-documents in the
dynamic context? Or is there some unstated constraint that the two are
consistent? 

It seems that to achieve the equivalence doc(document-uri($A)) is $A, we need
to implement document-uri() by doing a reverse lookup on the
available-documents mapping in the dynamic context, rather than by looking for
a property of the document node.

First of all, I think this means that the document-uri() function is
misspecified. It's not obvious from the specification that the result of the
function is context-dependent. And if we change the specification so the
function does a reverse lookup on available-documents, then the document-uri
property in the data model becomes redundant.

Secondly, I think it means that some of the XQTS test cases are making an
unwarranted assumption. A number of tests (document-uri-12, 15, 16, 17, 18, 19)
apply the document-uri() function to a document that was not retrieved using
the doc() function, but was built outside the scope of a particular query. At
the time the document is built, it's not known what the available-documents
mapping will be, which makes it difficult to associate a document-uri with the
document that offers a guarantee that doc(document-uri($X)) is $X will in fact
hold true. I think I can find ways of passing these tests by some rather
artificial manipulation of the dynamic context in the test driver, but it
doesn't feel right. 

I propose the following way forward:

(a) abolish the document-uri property and accessor

(b) describe fn:document-uri() as follows: if available-documents in the
dynamic context contains a mapping from one or more URIs to the specified
document node, the function returns one of those URIs (the choice is
implementation-dependent but stable). If it contains no such mapping, the
function returns an empty sequence.

(c) add a Note to say that if a document node $N was constructed using a call
on the doc() function, then it is guaranteed that document-uri($N) will return
a non-empty result; otherwise, it is implementation-dependent whether it will
return a non-empty result

(d) delete test cases that apply document-uri() to nodes that were not
constructed by calling the doc() function (for example, nodes passed into the
query as parameters).
Received on Monday, 1 May 2006 20:39:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:12 UTC