[SCXML] bad tests with inline values

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[SCXML] bad tests with inline values

David Junger
I have recently added (finally!) parsing inline JS/JSON and XML in <content> and <data> in my implementation. I noticed that a few revelant tests are not taking into account the latest requirements in this area:

Test 578 intends to send an object, but the inline string is not valid JSON because property names are not quoted, thus it gets a string as fallback. When you fix this, note that valid JSON must only use double quotes (") to delimit strings.

In tests 529 and 179, the inline value is a valid JSON string (therefore it should be parsed as such) whose interpretation is be a number, not a string (since there are no quotes). The condition should be rewritten with a loose == to allow both JSON and space-normalized text (which is possible when the implementation doesn't support JSON).

                        David
Reply | Threaded
Open this post in threaded view
|

RE: [SCXML] bad tests with inline values

Jim Barnett-5
Thank you for the comments.  I'm sorry to be late in responding to them. I will be looking at the tests in the new year and will investigate further then.

- Jim


-----Original Message-----
From: David Junger [mailto:[hidden email]]
Sent: Tuesday, December 10, 2013 3:27 PM
To: Voice Public List
Subject: [SCXML] bad tests with inline values

I have recently added (finally!) parsing inline JS/JSON and XML in <content> and <data> in my implementation. I noticed that a few revelant tests are not taking into account the latest requirements in this area:

Test 578 intends to send an object, but the inline string is not valid JSON because property names are not quoted, thus it gets a string as fallback. When you fix this, note that valid JSON must only use double quotes (") to delimit strings.

In tests 529 and 179, the inline value is a valid JSON string (therefore it should be parsed as such) whose interpretation is be a number, not a string (since there are no quotes). The condition should be rewritten with a loose == to allow both JSON and space-normalized text (which is possible when the implementation doesn't support JSON).

                        David


Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Zjnue Brzavi
Hi,

I'd like to propose a change to the eventdataVal XSL definition.
Right now all matched values are wrapped in single quotes, effectively / semantically casting them to strings.
The proposal is to remove the single quotes from this definition and leave it to the tests to wrap values in quotes when string comparisons are desired.
It would be great if the tests could convey the intent of the types in use clearly and not rely too much on various ecmascript quirks related to type-casting.
Best regards,
Zjnue

PS: The XPath XSL change has not been tested yet.

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Jim Barnett
What do other people think of this proposal?  I'm willing to make the
change but don't understand how/if it might effect other platforms.

- Jim
On 3/17/2014 8:47 PM, Zjnue Brzavi wrote:

> Hi,
>
> I'd like to propose a change to the eventdataVal XSL definition.
> Right now all matched values are wrapped in single quotes, effectively
> / semantically casting them to strings.
> The proposal is to remove the single quotes from this definition and
> leave it to the tests to wrap values in quotes when string comparisons
> are desired.
> It would be great if the tests could convey the intent of the types in
> use clearly and not rely too much on various ecmascript quirks related
> to type-casting.
> Here's the diff:
> https://github.com/zjnue/hscxml/commit/f964dcbbe72d54cc588d2fe3fd1bb4a3320e81c6
>
> Best regards,
> Zjnue
>
> PS: The XPath XSL change has not been tested yet.
>

--
Jim Barnett
Genesys

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Zjnue Brzavi
Hi,

Perhaps also mentioning the test cases where the current definition is creating difficulty:

test179.scxml:
 * data definition : <content>123</content>
 * equality test : <transition cond="_event.data == '123'" ... ( should be <transition cond="_event.data == 123")

test529.scxml:
 * data definition : <content>21</content>
 * equality test :<transition cond="_event.data == '21'" ... ( should be <transition cond="_event.data == 21" )

If the change is made, we could probably return to strict equality ( === ) tests instead of ==.

Thanks,
Zjnue


On Tue, Mar 18, 2014 at 1:51 PM, Jim Barnett <[hidden email]> wrote:
What do other people think of this proposal?  I'm willing to make the change but don't understand how/if it might effect other platforms.

- Jim

On 3/17/2014 8:47 PM, Zjnue Brzavi wrote:
Hi,

I'd like to propose a change to the eventdataVal XSL definition.
Right now all matched values are wrapped in single quotes, effectively / semantically casting them to strings.
The proposal is to remove the single quotes from this definition and leave it to the tests to wrap values in quotes when string comparisons are desired.
It would be great if the tests could convey the intent of the types in use clearly and not rely too much on various ecmascript quirks related to type-casting.
Here's the diff: https://github.com/zjnue/hscxml/commit/f964dcbbe72d54cc588d2fe3fd1bb4a3320e81c6

Best regards,
Zjnue

PS: The XPath XSL change has not been tested yet.


--
Jim Barnett
Genesys


Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

David Junger
Le 18 mar 2014 à 15:20, Zjnue Brzavi <[hidden email]> a écrit :

> Perhaps also mentioning the test cases where the current definition is creating difficulty:
>
> test179.scxml:
>  * data definition : <content>123</content>
>  * equality test : <transition cond="_event.data == '123'" ... ( should be <transition cond="_event.data == 123")
>
> test529.scxml:
>  * data definition : <content>21</content>
>  * equality test :<transition cond="_event.data == '21'" ... ( should be <transition cond="_event.data == 21" )
>
> If the change is made, we could probably return to strict equality ( === ) tests instead of ==.

But why would we *want* to use strict equality? As those tests demonstrate, == works intuitively (most of the time) to provide the expected result despite type mismatch. Moreover, as I pointed out before, == allows the possibility of interpreting the data as space-normalized text instead of JSON, and all it costs us is… well, nothing, it's even shorter :)

I'd rather keep using equivalence (==) and forget about types unless the type actually matters for a particular test or is semantically relevant. Actually, I wouldn't mind if the tests using X === undefined (or even typeof X === 'undefined') used !X instead. When is it useful to know that _event.data was explicitly set to an empty string as opposed to not set at all? Even worse, how about when _event.data is set explicitly to undefined? that would be undetectable under the current event representation, no matter how many equal signs you use.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Zjnue Brzavi
 
> Perhaps also mentioning the test cases where the current definition is creating difficulty:
>
> test179.scxml:
>  * data definition : <content>123</content>
>  * equality test : <transition cond="_event.data == '123'" ... ( should be <transition cond="_event.data == 123")
>
> test529.scxml:
>  * data definition : <content>21</content>
>  * equality test :<transition cond="_event.data == '21'" ... ( should be <transition cond="_event.data == 21" )
>
> If the change is made, we could probably return to strict equality ( === ) tests instead of ==.

But why would we *want* to use strict equality? As those tests demonstrate, == works intuitively (most of the time) to provide the expected result despite type mismatch. Moreover, as I pointed out before, == allows the possibility of interpreting the data as space-normalized text instead of JSON, and all it costs us is… well, nothing, it's even shorter :)

I'd rather keep using equivalence (==) and forget about types unless the type actually matters for a particular test or is semantically relevant. Actually, I wouldn't mind if the tests using X === undefined (or even typeof X === 'undefined') used !X instead. When is it useful to know that _event.data was explicitly set to an empty string as opposed to not set at all? Even worse, how about when _event.data is set explicitly to undefined? that would be undetectable under the current event representation, no matter how many equal signs you use.

Hi,

I'd prefer it to work intuitively all of the time :)
We're discussing the ecma model afterall and all valid ecmascript should be accepted, so fine by me either way.

Zjnue
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Jim Barnett
I'm not sure that I understand the conclusion of this discussion.  Do we have agreement on what to do with the tests?


On 3/18/2014 4:02 PM, Zjnue Brzavi wrote:
 
> Perhaps also mentioning the test cases where the current definition is creating difficulty:
>
> test179.scxml:
>  * data definition : <content>123</content>
>  * equality test : <transition cond="_event.data == '123'" ... ( should be <transition cond="_event.data == 123")
>
> test529.scxml:
>  * data definition : <content>21</content>
>  * equality test :<transition cond="_event.data == '21'" ... ( should be <transition cond="_event.data == 21" )
>
> If the change is made, we could probably return to strict equality ( === ) tests instead of ==.

But why would we *want* to use strict equality? As those tests demonstrate, == works intuitively (most of the time) to provide the expected result despite type mismatch. Moreover, as I pointed out before, == allows the possibility of interpreting the data as space-normalized text instead of JSON, and all it costs us is… well, nothing, it's even shorter :)

I'd rather keep using equivalence (==) and forget about types unless the type actually matters for a particular test or is semantically relevant. Actually, I wouldn't mind if the tests using X === undefined (or even typeof X === 'undefined') used !X instead. When is it useful to know that _event.data was explicitly set to an empty string as opposed to not set at all? Even worse, how about when _event.data is set explicitly to undefined? that would be undetectable under the current event representation, no matter how many equal signs you use.

Hi,

I'd prefer it to work intuitively all of the time :)
We're discussing the ecma model afterall and all valid ecmascript should be accepted, so fine by me either way.

Zjnue

--
Jim Barnett
Genesys
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

David Junger
Le 19 mar 2014 à 15:06, Jim Barnett <[hidden email]> a écrit :

> I'm not sure that I understand the conclusion of this discussion.  Do we have agreement on what to do with the tests?

I think the gist is that it looks better if the value in the condition is exactly (including the type) the value you used to define the data. If you want to do anything, just fix that, i.e. either use quotes in the data or don't use quotes in the condition.
But it doesn't break the test to compare a string with a number as long as you keep writing the condition as an equivalence (==), which you should keep doing.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Jim Barnett
So I should not have the xslt file insert quotations, but instead
include them in the data and condition if a string is intended, and not
if an int is intended, while leaving '==' for the comparison (in
ECMAScript - other data model languages could use different comparison
operators).  Is that correct?

- Jim
On 3/19/2014 11:07 AM, David Junger wrote:
> Le 19 mar 2014 à 15:06, Jim Barnett <[hidden email]> a écrit :
>
>> I'm not sure that I understand the conclusion of this discussion.  Do we have agreement on what to do with the tests?
> I think the gist is that it looks better if the value in the condition is exactly (including the type) the value you used to define the data. If you want to do anything, just fix that, i.e. either use quotes in the data or don't use quotes in the condition.
> But it doesn't break the test to compare a string with a number as long as you keep writing the condition as an equivalence (==), which you should keep doing.
>
> David

--
Jim Barnett
Genesys

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

David Junger
Le 19 mar 2014 à 16:19, Jim Barnett <[hidden email]> a écrit :

> So I should not have the xslt file insert quotations, but instead include them in the data and condition if a string is intended, and not if an int is intended, while leaving '==' for the comparison (in ECMAScript - other data model languages could use different comparison operators).  Is that correct?

Yes.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Jim Barnett
Just to be clear, I take the proposed changes to be those in Zjnue's
first email on this subject:
1. Remove the '..' from eventDataVal in both the ECMA and XPath xslt files
2.  Add '..' to the values in tests 294, 354, and 527.

Is this correct?  Are there other changes that need to be made?


On 3/19/2014 11:50 AM, David Junger wrote:
> Le 19 mar 2014 à 16:19, Jim Barnett <[hidden email]> a écrit :
>
>> So I should not have the xslt file insert quotations, but instead include them in the data and condition if a string is intended, and not if an int is intended, while leaving '==' for the comparison (in ECMAScript - other data model languages could use different comparison operators).  Is that correct?
> Yes.
>
> David

--
Jim Barnett
Genesys

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] bad tests with inline values

Jim Barnett
In reply to this post by Zjnue Brzavi
I have made these changes.  Let me know if you have any problems.

- Jim
On 3/17/2014 8:47 PM, Zjnue Brzavi wrote:

> Hi,
>
> I'd like to propose a change to the eventdataVal XSL definition.
> Right now all matched values are wrapped in single quotes, effectively
> / semantically casting them to strings.
> The proposal is to remove the single quotes from this definition and
> leave it to the tests to wrap values in quotes when string comparisons
> are desired.
> It would be great if the tests could convey the intent of the types in
> use clearly and not rely too much on various ecmascript quirks related
> to type-casting.
> Here's the diff:
> https://github.com/zjnue/hscxml/commit/f964dcbbe72d54cc588d2fe3fd1bb4a3320e81c6
>
> Best regards,
> Zjnue
>
> PS: The XPath XSL change has not been tested yet.
>

--
Jim Barnett
Genesys