- From: Chris Davis <davisc@iivip.com>
- Date: Mon, 07 Jun 2010 11:26:03 -0500
- To: Baggia Paolo <paolo.baggia@loquendo.com>
- CC: www-voice@w3.org, devans@invores.com
Everyone, I'm seeking clarification for why this is "reject". I discussed this w/Dan Evans and he agrees that the test needs to be changed because as written it requires an inefficient ECMA embed model to be used. To quote Dan: "After some more study of JS 1.5 and 1.8, some more reading of ECMA-262, and a lot of examples, I managed to correct my misunderstanding of the handling of 'var' statements. A 'var' statement, not inside a function, anywhere in a compilation unit, results in a property definition on the current scope object when the execution context is created (value undefined), while the optional initializer is left behind at the point of the 'var' statement, to be executed only if control flows through that point. I have always agreed with your desire for efficiency, so now I also agree that the test should be changed. I don't think the CCXML standard intends to preclude what you want to do (if it does, it should make a statement to that effect), and the test just exposes an unintended consequence of breaking a Javascript pgm up into smaller compilation units. " Dan - the above was from your 5/25 email to me. Please chime in. Regards, Chris Baggia Paolo wrote: > Chris, > > we reviewed and discussed your comments on CCXML.1.0 scooping. > > ISSUE-677: > > Proposed Resolution: Reject > > In our opinion ISSUE-677 on #798 in 8_4.txml, is correctly testing > the scope chain of CCXML (in Sect 8.2.1.1). > > Where the first 'if' is meant to see if the variable is resolved > in the 'session' scope, then other scopes are tested as well. > > After discussion your request is pending reject. > > Please explicitly confirm that you accept the proposed resolution or after one week we will consider implicitly accepted the resolution. If you need clarification, please ask them very soon. > > Regards, > Paolo > > > -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Received on Monday, 7 June 2010 16:27:31 UTC