Re: April CCXML: test case conflicts with ECMA rules

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

-- 
    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


On 22.4.2010 15:24, Chris Davis wrote:
> Hello voice group,
>
> For test case 798 of 8_4_A.txml, there appears to be an inconsistency
> with relation to ECMA script rules and scoping rules
> laid out in the Recommendation's scoping section (
> http://www.w3.org/TR/2010/CR-ccxml-20100401/#Assign ).
>
> Specifically, the Recommendation describes just 4 scopes; session,
> application, ccxml, and transition.
> However, test case 798 indicates that the test designer assumed that "if
> (statement) { }" results in a new scope, and any
> variables declared live inside this new non-existant scope.
>
> The problem is that in ECMA, "if" does not create a scope, and any vars
> declared get "positioned" in the current scope and set
> to undefined prior to execution. Here is the offending test fragment:
> ------------
> <transition event="user.START_ASSERTION_795" state="ASSERTION_NMBR_795">
>
> <assign name="ASSERTION_NUM" expr="'798'"/>
> <if cond="id==session.id">
> <assign name="application.id" expr="'1'"/>
> <if cond="id=='1'">
> <var name="id" expr="'2'"/>
> ------------------
> The local position of "id" gets put into the nearest scope, which in
> this case is the transition level scope.
> When the script runs, this means that "id" exists but has the value
> undefined when <if cond="id==session.id"> runs,
> so the test always fails.
>
> To the test designer the javascript equivalent of the test fragment is:
> --------------------------------------------------
> if(id==session.id)
> {
> application.id = '1';
> if( id=='1' )
> {
> var id = '2';
> }
> }
> --------------------------------------------------
> But in reality to ECMA the xml becomes:
> ------------------------------------------
> var id=undefined; // because this is the scope; not the if {} and id has
> not been assigned yet
> if(id==session.id) // always fails now
> {
> application.id = '1';
> if( id=='1' )
> {
> id = '2';
> }
> }
> -------------------------------------------
> We don't see in the Recommendation where "if" is supposed to create a
> new scope, so we fall back on ECMA
> rules, where "if" does *not* create a scope. In theory a block scope
> could be created after "if" with the "let"
> keyword, but we doubt that was intended.
>
> We recommend the test be deleted or modified.
>
> As a followup, when the test fails, it fails to record the error
> properly because in the .txml,
> there is:
> <log expr="LogPrefix + ' FAIL session.id/id=' + id + ' expected
> session.id'"/>
>
> and LogPrefix is undefined.
>
> Thanks
>
>
>

Received on Friday, 23 April 2010 08:24:52 UTC