Re: [XQuery] MS-XQ-LC1-084

Yes, section 4  eliminates half of the confusion. But (a)
it is a little bit too late, section 3 has to specify this.
And (b) the  relationship between the in scope namespaces during
the parsing time and the ones available at runtime is still unclear to  
me
by reading the text (requires a lot of guessing and that's not good).

For example, are the following two expressions equivalent ?

Query1
======

declare namespace ns="uri1";
declare variable $x as xs;string external;

let $y := xs:Qname($x)
return <ns:bar xmlns:ns="uri2">  
{fn:get-namespace-uri-from-Qname($y)</ns:bar>


Query 2
=======

declare namespace ns="uri1";
declare variable $x as xs:string external;

  <ns:bar xmlns:ns="uri2">  
{fn:get-namespace-uri-from-Qname(xs:Qname($x))}</ns:bar>

when $x is bound to "ns:foo" ?


If they are not (which is what I expect, but I am sure by reading the  
text),
I will really insist we have a clear example in the  specification.
I hope everybody understands the consequences of such a
decision on rewriting and optimization (view unfolding doesn't hold in  
general, etc)

There is one thing to have the parsing deal with multiple  
contexts/scopes. However,
dealing with multiple contexts for each subexpression during  
compilation and runtime
is much harder and lots of traditional database optimizations will not  
hold anymore. We have
to make readers aware of this.

Best regards,
Dana


On Feb 16, 2004, at 7:21 PM, Michael Rys wrote:

> Actually, I think that the spec is clear in the semantics (also see
> section 4 in the language spec).
>
> Best regards
> Michael
>
>> -----Original Message-----
>> From: Daniela Florescu [mailto:danielaf@bea.com]
>> Sent: Monday, February 16, 2004 11:41 AM
>> To: Michael Rys
>> Cc: public-qt-comments@w3.org
>> Subject: Re: [XQuery] MS-XQ-LC1-084
>>
>> Michael,
>>
>> I think the spec is simply unclear what the semantics is in this case.
>>
>> See BEA's comment:
>>
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/ 
> 0455.html
>>
>> If it remains like Jonathan would desire, and make the scope include
>> all the subexpressions that are lexically within the element
>> constructor,
>> we do require more detailed examples to make users understand this.
>>
>> See BEA's request for more detailed explanation here:
>>
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/ 
> 0443.html
>>
>> The fact that now the semantics of an expression depends on the
> lexical
>> position of the expression within the query will impact on the way
> users
>> will make use of the LET clauses and on the functions.
>>
>> Best regards,
>> Dana
>>
>>
>>
>> On Feb 16, 2004, at 3:13 AM, Michael Rys wrote:
>>
>>>
>>> Section 3.7.1.2 Namespace Declaration Attributes
>>> Technical
>>>
>>> Namespace declaration attributes should not affect the in-scope
>>> namespace static context for expressions. We think that only the
> ones
>>> in
>>> the prolog should affect the namespace prefixes inside expressions.
>>>
>>> We find the following semantics to be confusing:
>>>
>>> declare namespace b="uri1"; <a xmlns:b="uri2">{/b:c}</a> will look
> for
>>> {uri2}:c and not {uri1:c}. "uri2" should only affect the
> construction
>>> part.
>>>
>>> The same should then also hold for the computed constructors.
>>>
>>> Thus, we would like to have the following behaviour:
>>>
>>> Namespace declaration in prolog: Provides static namespace prefix
>>> bindings for both constructors and expressions
>>>
>>> Namespace declaration on construction: Provides static namespace
> prefix
>>> bindings for constructors only, not for embedded expressions.
>>>
>