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

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

From: <bugzilla@wiggum.w3.org>
Date: Sat, 17 Jun 2006 13:43:28 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1Frb5E-0003MR-NJ@wiggum.w3.org>

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





------- Comment #7 from mike@saxonica.com  2006-06-17 13:43 -------
Let's concentrate on query and stylesheet parameters / external variables
first. If we require

doc(document-uri($param)) is $param

for such cases, the consequences are:

(a) documents supplied as parameters must have unique document URIs (assuming
they have document URIs at all): we need to define a new error condition that
is raised if this condition is violated.

(b) if a document D with document URI U is supplied as a parameter, then
available-documents in the dynamic context must include a mapping from U to D.
This means it is an error if it contains a mapping from U to anything else, and
we must define this error condition. This error condition gives me problems,
because in many real products, the "mapping" is implemented by a user-defined
function (variously called a URIResolver or an XMLResolver) that can map URIs
to document nodes in any way that it likes. The error condition is one that I
therefore find it difficult to enforce.

I think it is simpler not to define these two error conditions, and instead to
relax the rule that doc(document-uri($param)) is $param.

Concerning collection(), we would again need to define some additional error
conditions, and some of these are hard to enforce. The obvious constraint again
is that the document-uri's of the returned documents are unique; but it goes
beyond this. For example, if the user has called doc-available(U) and received
the answer false(), then collection() must not be allowed to return a document
whose document-uri is U. Rather than do the work on the specification to define
all such constraints, I think it would be easier to relax the rules.
Received on Saturday, 17 June 2006 13:43:39 UTC

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