This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In XQuery 3.0: "If the initializer of a variable V depends on V, a static error is raised [err:XQST0054]" I believe that the existance of fn:function-lookup may mean it is possible to construct a query in which a variable depends on itself, but that this cannot be determined statically. Suppose the existance of a document 'some.xml' with root element functionQName of type xs:QName with value 'local:return-v'. The following query shows how the initializer of $v might dynamically depend on $v. declare variable $v := function-lookup(doc('some.xml')/functionQName, 0)(); declare function local:return-v() { $v }; $v I suggest making this error a dynamic error, as it is in XSLT: [Definition: A circularity is said to exist if a construct such as a global variable ... is defined in terms of itself. ... ] [ERR XTDE0640] In general, a circularity in a stylesheet is a non-recoverable dynamic error. However, as with all other dynamic errors, an implementation will signal the error only if it actually executes the instructions and expressions that participate in the circularity. Because different implementations may optimize the execution of a stylesheet in different ways, it is implementation-dependent whether a particular circularity will actually be signaled.
I have created test case function-lookup-013 based on this scenario (with a provisional outcome)
Thatnks for adding the test. However, it needs to be marked as XQ30+ only, as it contains an XQuery prolog.
Dependency added as suggested.
In the XQuery specification, I think the simplest approach is to add the following text: If a global variable directly or indirectly relies on a dynamic function call which at runtime turns out to directly or indirectly rely on the global variable itself, an error is raised [err:TBD] Are there other cases that we need to handle? If so, let's enumerate them.
The phrase "directly or indirectly relies on" is not defined adequately to handle this case.
Here's another example, but this time for XQST0107. declare variable $n external := xs:QName('local:return-p'); declare variable $v := function-lookup($n, 0)(); declare function local:return-p() {$p}; declare variable $p external := fn:position(); declare context item := $v .
Here's a further example which I don't think should cause an error. declare variable $n external := fn:QName("local:f"); declare variable $v := fn:function-lookup($n)(1); declare function local:f($arg) { If ($arg = 1) then $arg else $v }; $v
This may be resolved by the following proposal, which was adopted today: https://lists.w3.org/Archives/Member/w3c-xsl-query/2012May/0118.html
(In reply to comment #8) > This may be resolved by the following proposal, which was adopted today: > https://lists.w3.org/Archives/Member/w3c-xsl-query/2012May/0118.html Tim - do you believe that the proposal resolves this bug?
Ghislain followed that up with a later message which covered XQST0107. https://lists.w3.org/Archives/Member/w3c-xsl-query/2012May/0165.html
(In reply to comment #10) > Ghislain followed that up with a later message which covered XQST0107. > > https://lists.w3.org/Archives/Member/w3c-xsl-query/2012May/0165.html This was adopted. We believe that this issue is now fixed.