This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15791 - [XQ30] XQST0054
Summary: [XQ30] XQST0054
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Blocks: 17272
  Show dependency treegraph
Reported: 2012-01-30 12:05 UTC by Tim Mills
Modified: 2012-07-24 14:56 UTC (History)
2 users (show)

See Also:


Description Tim Mills 2012-01-30 12:05:34 UTC
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()


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.
Comment 1 Michael Kay 2012-02-06 17:03:01 UTC
I have created test case function-lookup-013 based on this scenario (with a provisional outcome)
Comment 2 Tim Mills 2012-02-07 15:12:29 UTC
Thatnks for adding the test.

However, it needs to be marked as XQ30+ only, as it contains an XQuery prolog.
Comment 3 Michael Kay 2012-02-07 15:27:25 UTC
Dependency added as suggested.
Comment 4 Jonathan Robie 2012-02-14 12:13:25 UTC
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.
Comment 5 John Snelson 2012-02-14 12:22:47 UTC
The phrase "directly or indirectly relies on" is not defined adequately to handle this case.
Comment 6 Tim Mills 2012-02-20 11:44:55 UTC
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

Comment 7 Tim Mills 2012-02-28 19:58:15 UTC
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 

Comment 8 Jonathan Robie 2012-05-22 16:44:47 UTC
This may be resolved by the following proposal, which was adopted today:
Comment 9 Jonathan Robie 2012-06-07 22:28:29 UTC
(In reply to comment #8)
> This may be resolved by the following proposal, which was adopted today:

Tim - do you believe that the proposal resolves this bug?
Comment 10 Tim Mills 2012-06-08 14:50:40 UTC
Ghislain followed that up with a later message which covered XQST0107.
Comment 11 Jonathan Robie 2012-07-24 14:56:26 UTC
(In reply to comment #10)
> Ghislain followed that up with a later message which covered XQST0107.

This was adopted. We believe that this issue is now fixed.