Some issues with IRP Tests

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

Some issues with IRP Tests

Stefan Radomski
Hi there,

we are preparing for the IRP and just updated the tests. Now there are a couple of issues:

404 Not Found:
These are linked from http://www.w3.org/Voice/2013/scxml-irp/ but not found:


Test159:
The XSLT transformation will create an invalid send element in line 9: <send event="thisWillFail" conf:illegaltarget="”/>. It used to create ’target=“baz”’ some versions ago. We are using the saxon9he.jar XSLT implementation as it’s the only free-of-charge XSLT2.0 implementation available cross-platform we found.

Test179:
It fails for us as we used to interpret the content of a <content> element as a literal string (with a subsequent test for XML, JSON and space-normalization). For test179 with the ecmascript datamodel, this means that <content>'123'</content> would result in event.data === “‘123’” (note the single quotes). With earlier versions of this test, the content of <content> used to be 123 without any quotes.

The relevant sections from the recommendation candidate are:

——
5.6 <content>
The use of the <content> element depends on the context in which it occurs. See 5.5 <donedata>, 6.2 <send> and 6.4 <invoke> for details.
5.6.2 Children
[…] If the 'expr' attribute is not present, the Processor must use the children of <content> as the output. The interpretation of the output of the <content> element depends on the data model. See C Data Models for details.

6.2 <send>
6.2.3 Children
<content>. The SCXML Processor must evaluate this element when the parent <send> element is evaluated and pass the resulting data to the external service when the message is delivered.

C Data Models
C.2 The ECMAScript Data Model
C.2.6 <content>
When <content> is a child of <send>, the interpretation of its value depends on the Event I/O Processor.

6.2.5 The Type of Send
If neither the 'type' nor the 'typeexpr' is defined, the SCXML Processor must assume the default value of http://www.w3.org/TR/scxml/#SCXMLEventProcessor.

D.1 SCXML Event I/O Processor
The 'data' field of the event raised in the receiving session must contain a copy of the data specified in the 'namelist' attribute or in <param> or <content> elements in the sending session. The nature of the copy operation depends on the data model in question. […] The format of the 'data' field will depend on the data model of the receiving session.
——

I am not too sure what to make of it, as C.2.6 tells me to look at the I/O Processor (which is the SCXML one as no type is given) and D.1 tells me it depends on the receiving datamodel (ecmascript as we send it to ourselves). Reads like a circular specification. 

Am I right to assume that an interpreter should evaluate the content of <content> as an expression of the datamodel (which is somewhat implied by the test and allows for JSON)? If that’s the case, is there a difference between the text content of <content> and the value of the “expr” attribute in this case? But what about e.g. test 562, where a space normalized string is to be created - how would I differentiate the two case?

Test519 (related 520, 531, 534):
Where is the format for HTTP requests via the basichttp I/O processor defined? Test assumes 'Varparam1=1’ in the raw message, but the SCXML RC does not specify anything to this effect - did I miss/overread something? The IRP manifest declares them as optional, but we’d still like to pass them.

Best regards
Stefan



---
FB20 Telecooperation | Darmstadt University of Technology
Hochschulstr. 10 | D-64289 Darmstadt Germany | Room S2|02 / A108
Tel +49 (6151) 16-6670 | Fax +49 (6151) 16-3052

Reply | Threaded
Open this post in threaded view
|

RE: Some issues with IRP Tests

Jim Barnett-2

Stefan,

  The broken links to tests 446, 549. 545, 496, and 577 should be fixed.

 

Test159 should be fixed.

 I’ve removed the quotes from test 159

 

For test 519, the relevant section of the spec is in D.2.2 “If one or more <param> children are present, the SCXML Processor MUST map their names (i.e. name attributes) and values to HTTP POST parameters.”   The intent was that ‘param1=1’ would show up as a POST parameter, and that’s what the test is attempting to check.  Now the test may well be written wrong anyway, and I’ll be glad to change it if someone can show me the right way to test for a POST parameter.

 

-          Jim

 

 

From: Stefan Radomski [mailto:[hidden email]]
Sent: Friday, March 14, 2014 5:36 PM
To: [hidden email] ([hidden email])
Subject: Some issues with IRP Tests

 

Hi there,

we are preparing for the IRP and just updated the tests. Now there are a couple of issues:

 

404 Not Found:

These are linked from http://www.w3.org/Voice/2013/scxml-irp/ but not found:

 

 

Test159:

The XSLT transformation will create an invalid send element in line 9: <send event="thisWillFail" <a href="conf:illegaltarget=%22&#8221;/">conf:illegaltarget="”/>. It used to create ’target=“baz”’ some versions ago. We are using the saxon9he.jar XSLT implementation as it’s the only free-of-charge XSLT2.0 implementation available cross-platform we found.

 

Test179:

It fails for us as we used to interpret the content of a <content> element as a literal string (with a subsequent test for XML, JSON and space-normalization). For test179 with the ecmascript datamodel, this means that <content>'123'</content> would result in event.data === “‘123’” (note the single quotes). With earlier versions of this test, the content of <content> used to be 123 without any quotes.

The relevant sections from the recommendation candidate are:

——

5.6 <content>
The use of the <content> element depends on the context in which it occurs. See 5.5 <donedata>, 6.2 <send> and 6.4 <invoke> for details.

5.6.2 Children

[…] If the 'expr' attribute is not present, the Processor must use the children of <content> as the output. The interpretation of the output of the <content> element depends on the data model. See C Data Models for details.

 

6.2 <send>

6.2.3 Children

<content>. The SCXML Processor must evaluate this element when the parent <send> element is evaluated and pass the resulting data to the external service when the message is delivered.

 

C Data Models

C.2 The ECMAScript Data Model

C.2.6 <content>

When <content> is a child of <send>, the interpretation of its value depends on the Event I/O Processor.

 

6.2.5 The Type of Send

If neither the 'type' nor the 'typeexpr' is defined, the SCXML Processor must assume the default value of http://www.w3.org/TR/scxml/#SCXMLEventProcessor.

 

D.1 SCXML Event I/O Processor

The 'data' field of the event raised in the receiving session must contain a copy of the data specified in the 'namelist' attribute or in <param> or <content> elements in the sending session. The nature of the copy operation depends on the data model in question. […] The format of the 'data' field will depend on the data model of the receiving session.

——

 

I am not too sure what to make of it, as C.2.6 tells me to look at the I/O Processor (which is the SCXML one as no type is given) and D.1 tells me it depends on the receiving datamodel (ecmascript as we send it to ourselves). Reads like a circular specification. 

 

Am I right to assume that an interpreter should evaluate the content of <content> as an expression of the datamodel (which is somewhat implied by the test and allows for JSON)? If that’s the case, is there a difference between the text content of <content> and the value of the “expr” attribute in this case? But what about e.g. test 562, where a space normalized string is to be created - how would I differentiate the two case?

 

Test519 (related 520, 531, 534):

Where is the format for HTTP requests via the basichttp I/O processor defined? Test assumes 'Varparam1=1’ in the raw message, but the SCXML RC does not specify anything to this effect - did I miss/overread something? The IRP manifest declares them as optional, but we’d still like to pass them.

 

Best regards

Stefan

 

 

---

FB20 Telecooperation | Darmstadt University of Technology
Hochschulstr. 10 | D-64289 Darmstadt Germany | Room S2|02 / A108

Tel +49 (6151) 16-6670 | Fax +49 (6151) 16-3052

 

Reply | Threaded
Open this post in threaded view
|

Re: Some issues with IRP Tests

Zjnue Brzavi
In reply to this post by Stefan Radomski
Hi,
 
Test159:
The XSLT transformation will create an invalid send element in line 9: <send event="thisWillFail" conf:illegaltarget="”/>. It used to create ’target=“baz”’ some versions ago. We are using the saxon9he.jar XSLT implementation as it’s the only free-of-charge XSLT2.0 implementation available cross-platform we found.

This has been noted before. In test159.txml, conf:illegaltarget="", should be conf:illegalTarget=""
https://github.com/zjnue/hscxml/commit/264b5f01eed717a7b3412d7ceb469c7c6ae885fc

Another minor point is that test 528 contains some unnecessary duplication:
https://github.com/zjnue/hscxml/commit/c319a3d7efdf44c6f28f3e90dd77848acc1cd8ca

Best regards,
Zjnue
Reply | Threaded
Open this post in threaded view
|

RE: Some issues with IRP Tests

Jim Barnett-2

I’ve fixed test159 and removed the duplicate from test 528.

 

-          Jim

 

From: Zjnue Brzavi [mailto:[hidden email]]
Sent: Monday, March 17, 2014 11:22 AM
To: Stefan Radomski
Cc: [hidden email] ([hidden email])
Subject: Re: Some issues with IRP Tests

 

Hi,

 

Test159:

The XSLT transformation will create an invalid send element in line 9: <send event="thisWillFail" <a href="conf:illegaltarget=%22&#8221;/">conf:illegaltarget="”/>. It used to create ’target=“baz”’ some versions ago. We are using the saxon9he.jar XSLT implementation as it’s the only free-of-charge XSLT2.0 implementation available cross-platform we found.

 

This has been noted before. In test159.txml, <a href="conf:illegaltarget">conf:illegaltarget="", should be <a href="conf:illegalTarget"> conf:illegalTarget=""
https://github.com/zjnue/hscxml/commit/264b5f01eed717a7b3412d7ceb469c7c6ae885fc

Another minor point is that test 528 contains some unnecessary duplication:
https://github.com/zjnue/hscxml/commit/c319a3d7efdf44c6f28f3e90dd77848acc1cd8ca

Best regards,
Zjnue

Reply | Threaded
Open this post in threaded view
|

Re: Some issues with IRP Tests

Zjnue Brzavi
On Mon, Mar 17, 2014 at 3:28 PM, Jim Barnett <[hidden email]> wrote:

I’ve fixed test159 and removed the duplicate from test 528.


Thanks!