Michael,
On Oct. 17, 2006, the Query Working Group considered your comment and decided to replace the sentence in XQuery Section 4.14 dealing with "circularity" with the following specification:

A variable $x "depends on" a variable $y or a function f2 if $y or f2 appears in the initializing expression of $x. A function f1 "depends on" a variable $y or a function f2 if $y or f2 appears in the body of f1. If a variable depends on itself by any combination of direct or transitive dependencies, a static error is raised [XQST0054].

The working group believes that this change addresses your issue. If you agree, please change the status of this bug report to Closed.

Regards,
Don Chamberlin (for the Query Working Group)

That certainly goes a long way toward addressing my issue, but I think there's still some uncertainty left. Consider:

    declare variable $x = f();
    declare function f()
    {
        let $x := 42 return $x
    };

$x depends on f(), and f() depends on $x, so $x would appear to depend on itself, except that the two $x's aren't really the same variable. Or are they?

Similarly:

    declare variable $x = f(42);
    declare function f($x)
    {
        $x
    };

No, I don't think there's any uncertainty. The sentence clearly describes a relation between variables, not between variable names. The fact that two variables can have the same name is completely irrelevant. 

A more pendantic definition might be

A variable binding $x "depends on" a variable binding $y or a function f2 if a variable reference bound to $y or a function call bound to f2 appears
in the initializing expression of $x. A function f1 "depends on" a variable binding $y or a function f2 if a variable reference bound to $y or a function call bound to f2 appears in the body of f1. If a variable binding depends
on itself by any combination of direct or transitive dependencies, a static
error is raised [XQST0054].

... but I would have thought any reader capable of understanding that would also understand the text that Don proposed.

Michael, we are trying very hard at the moment to close out the last few issues and get the specs finished. Technically, we closed to new comments months ago, but we are still keeping the lists open so that serious errors can be reported. We can't keep wordsmithing for ever: there are people who want these specs finished.

(In reply to comment #3)
>
> No, I don't think there's any uncertainty. The sentence clearly describes a
> relation between variables, not between variable names.

I disagree re "clearly". True, it uses the word "variable" and not "variable name", but it also refers to "$x" and "$y", which are variable names (or, strictly speaking, *contain* variable names), not variables. (You could avoid that particular problem by referring to, say, "V<sub>1</sub>" and "V<sub>2</sub>", i.e., by making them look as different as possible from concrete variable references, but I don't think it would increase the clarity that much; the problem is that on the whole, the spec doesn't make that much of a distinction between variables and variable names.)

> The fact that two variables can have the same name is completely irrelevant.

That might be worth saying in the spec, but I think I have a better suggestion...


> A more pendantic definition might be
> 
> A variable binding $x "depends on" a variable binding $y or a function f2 if a
> variable reference bound to $y or a function call bound to f2 appears
> in the initializing expression of $x. A function f1 "depends on" a variable
> binding $y or a function f2 if a variable reference bound to $y or a function
> call bound to f2 appears in the body of f1. If a variable binding depends
> on itself by any combination of direct or transitive dependencies, a static
> error is raised [XQST0054].

Well, if we're getting pedantic, then:

-- The only bolded occurrence of "variable binding" (in 4.14) strongly suggests that a variable declaration is not a variable binding. So a "variable binding" is exactly what the definition of "depends on" should *not* be concerned with. (Moreover, the spec seems generally undecided on whether a "variable binding" is a static or dynamic thing, and whether it binds a variable to a value or an expression.)

-- According to 3.1.2, a variable reference is not "bound to" a variable binding, it "matches" or "refers to" a variable binding.

-- There's no basis for the phrase "a function call bound to [the function] f2". (Mind you, I don't think the spec provides any verb for that relation.)

> ... but I would have thought any reader capable of understanding that would
> also understand the text that Don proposed.

I think the second one, despite my pedantic objections, would have given me less uncertainty about your intent than the first one did.

However, I think you can do better (convey your intent without uncertainty, and without pedantry): instead of making "depends on" a relation on variables and functions (or variable bindings and functions), make it a relation on variable declarations and function declarations. E.g.:

     A variable declaration V1 "depends on" a variable declaration V2
     or a function declaration F2 if a use of V2 or F2 appears in the
     initializing expression of V1.
     etc.
     [or maybe "reference to" instead of "use of"]

This gets away from the not-that-well-defined notions of "variable" and "variable binding", and instead couches the definition (as much as possible) in the nice solidly static world of syntax, where it's clear that (e.g.)
    let $x := 42 return $x
does not contain a variable declaration or a use of one, and so does not enter into the "depends on" relation.

(In reply to comment #3)
>
> Michael, we are trying very hard at the moment to close out the last few
> issues and get the specs finished.

Good luck with that!

> Technically, we closed to new comments months ago,

Oh? Was there an announcement to that effect? The spec itself didn't give a deadline for comments.

And technically, this isn't a new comment, it's an old comment that never got properly resolved.

> but we are still keeping the lists open so that serious errors can be
> reported.

Am I to infer that this wasn't a serious error, and shouldn't have been reported?

> We can't keep wordsmithing for ever: there are people who want these specs
> finished.

I've been unable to find a polite reply to that statement.

The Working Group is grateful for your interest in the documents. After serious discussion, the WG has decided not to make the change suggested in comment #5. 

In response to your comment "Was there an announcement to that effect? The spec itself didn't give a deadline for comments.", we would like to point to the following text in the Status section of the CR documents: This specification will remain a Candidate Recommendation until at least 28 February 2006.

That sentence means that all comments submitted prior to that date must be handled by the WGs before progression is possible. Comments submitted after that date may be handled at the discretion of the WG. If they are not handled in version 1.0, they must be addressed either in an erratum or in some future version of the spec. This particular bug was entered on 17 October, long after the comment period had elapse. 

Again, thank you for your interest. 

(In reply to comment #6)
> The Working Group is grateful for your interest in the documents.

That's nice to hear.

> After serious discussion, the WG has decided not to make the change
> suggested in comment #5.

Okay. Although I think you mean Comment #4.
 
> "This specification
> will remain a Candidate Recommendation until at least 28 February 2006."

Yes, "this CR will remain a CR until at least 3 months ago". Not very informative on the face of it.

> That sentence means that all comments submitted prior to that date must be
> handled by the WGs before progression is possible. Comments submitted after
> that date may be handled at the discretion of the WG. If they are not handled
> in version 1.0, they must be addressed either in an erratum or in some future
> version of the spec.

Perhaps the spec should have said that then.