Re: April CCXML: test case conflicts with ECMA rules

Hi Chris,

> I don't see how any CCXML implementation can be passing this test case.
> Is yours passing?

Yes, OptimTalk passes this test smoothly.


Your explanation below is correct but it is important to note that you 
deal with a script. The following script in OptimTalk would behave the 
same way as you describe:

     <transition event="ccxml.loaded">
       <var name="test"/>
       <script>
       [![CDATA[
         test = id;

         var id = 3;
       ]]>
       </script>
     </transition>

Here the test value would be 'undefined'.

However, the test case deals with <var> tags. I assume that the <var> 
tag is evaluated according to its position in a CCXML document. I don't 
see any statement in the CCXML specification that <var> usage implies 
declaration of the variable at the begging of <transtion>.

I agree with you that it should be clarified whether the CCXML 
interpreter behavior here should be the same as for ECMA Script. This is 
probably issue for RJ Auburn.

Anyway it is also important to consider consequences. For instance, 
according to what you've described, this is correct code in ECMA script:

     x = 3;
     var x;

So if we want to follow the same behavior in CCXML this should be also 
correct:

     <transition event="ccxml.loaded">
       <assign name="x" expr="3"/>
       <var name="x"/>
     </transition>

which probably breaks the following statement in the CCXML 
specification, Section 8.2.1.1:

   "It is illegal to make an assignment to a variable that has not been
   explicitly declared using <var> or a var statement within a <script>."

Regards,
Petr

-- 
    Petr Kuba, Project Manager
    OptimSys, s.r.o
    kuba@optimsys.cz
    Tel: +420 541 143 065
    Fax: +420 541 143 066
    http://www.optimsys.cz



> When you say:
> "When this condition is being evaluated there is no "id" in current
> (Transition) scope because this variable will be declared couple of
> lines later in <var>."
>
> that is incorrect. The declaration of id will be made in the current
> scope(transition), regardless of where it sits visually in the
> transition. It doesn't get "declared later" - ECMA declares it inside
> the transition scope, which is visible when the ECMA first runs the
> transition.
>
> If you comment out the var id declaration, then yes ECMA will see id
> from the parent scope. However - by declaring a var id in the new scope
> you are evaluating the local id value (undefined because the assignment
> has not taken place after the if) when ECMA runs inside the transition
> scope.
>
> I've attached an html file with a short javascipt that demonstrates this
> misunderstanding of ECMA scopes.
> Try it on Windows/Explorer, Linux/Mozilla etc, you will always get the
> output:
>
> show ECMA function scope test
> see? id is undefined...id=undefined
>
> Here is the textual content of the attachment:
> <html>
> <body>
> <pre>
> <script type="text/javascript">
> document.write("show ECMA function scope test\n");
> var id=2;
> function foo()
> {
> if(id==2)
> {
> document.write("this won't run");
> var id = 3;
> }
> else
> {
> document.write("see? id is undefined...id="+id);
> }
> }
> foo();
> </script>
> </pre>
> </body>
> </html>
>
> Regards,
> Chris
>
> Petr Kuba wrote:
>> Hello Chris,
>>
>> I believe that the test case is correct. It tests the parent scope
>> chain delegation model as described in the CCXML specification but it
>> doesn't expect "if" to open a new scope.
>>
>> Let's see the statement you find offending:
>>
>> <if cond="id==session.id">
>>
>> When this condition is being evaluated there is no "id" in current
>> (Transition) scope because this variable will be declared couple of
>> lines later in <var>. Therefore searching continues in scopes CCXML,
>> Application and Session. The "id" variable is found in the Session
>> scope and therefore the condition is "true".
>>
>> You assume that the variable exists in the Transition scope and has
>> value 'undefined' but it is not correct. The variable doesn't exist at
>> the time when the condition above runs.
>>
>>
>> Regards,
>> Petr Kuba
>>
>
>

Received on Friday, 23 April 2010 17:54:45 UTC