W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2011

Re: Question on XQuery formal semantics

From: Michael Dyck <jmdyck@ibiblio.org>
Date: Fri, 11 Mar 2011 12:23:30 -0800
Message-ID: <4D7A84C2.4050805@ibiblio.org>
To: Axel Polleres <axel.polleres@deri.org>
CC: public-qt-comments@w3.org, Nuno Alexandre Lopes <nuno.lopes@deri.org>, Stefan Bischof <stefan.bischof@deri.org>
[Sorry for the delay -- I meant to reply last week, but it fell off my 
radar. Liam's reply reminded me.]

Axel Polleres wrote:
> ... we would appreciate a small clarification (or pointers to earlier
> discussions in this regard) on the "function" fs:new:
> First of all, fs:new appears in the document several times, before it is
> actually explained (in acouple of normalization rule).

Yes, it might have been better to explain it in Section 2.1 
"Introduction to the Formal Semantics."

> Then, the first time it is explained is within the normalization rule in
> section 4.12.1. Here it says:
>   "Note that the following normalization rule uses a variable $fs:new,
>   which is a newly created variable which must not conflict with any
>   variables already in scope."
> We are not entirely clear, what "scope" means here.

I believe "variables already in scope" is a casual way of saying 
"in-scope variables", which refers to the 'varType' component of the 
static environment.

> The term "scope"  doesn't seem to be defined in the context of
> normalization rules, it  seems.

Do you mean that normalization rules appear to be context-free, and so 
don't have access to a static environment? It's certainly true that most 
of them are context-free, but in fact,
     "normalization is always applied in the presence of
      a static context"
(Section 3.2.2 "Normalization mapping rules"). E.g., normalization of 
function arguments is done with knowledge of the corresponding parameter 
types from the function signature, which is looked up in the static context.

(Mind you, I think there are 'bugs' in the mechanism that conveys the 
static context to normalization rules, but I haven't looked too closely.)

> What's particularly worrying us it, that this does not formally
> seem to preclude that the newly generated variable is - for instance -
> a variable which is actually used later on in a return clause.  

If a variable of the same name were introduced for an in inner scope, it 
would shadow the "$fs:new" variable, but I think that's okay, because 
the inner scope never needs to access the $fs:new variable.

Do you have a specific example where this wouldn't work?

Received on Friday, 11 March 2011 20:24:04 UTC

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