W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2014

RE: Some issues with IRP Tests

From: Jim Barnett <jim.barnett@genesys.com>
Date: Mon, 17 Mar 2014 14:55:16 +0000
To: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>, "www-voice@w3.org (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810205F4A3@GENSJZMBX03.msg.int.genesyslab.com>
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:radomski@tk.informatik.tu-darmstadt.de]
Sent: Friday, March 14, 2014 5:36 PM
To: www-voice@w3.org (www-voice@w3.org)
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:

http://www.w3.org/Voice/2013/scxml-irp/446/test446.txml
http://www.w3.org/Voice/2013/scxml-irp/459/test459.txml
http://www.w3.org/Voice/2013/scxml-irp/545/tests545.txml
http://www.w3.org/Voice/2013/scxml-irp/496/496.txml
http://www.w3.org/Voice/2013/scxml-irp/577/577.txml

Test159:
The XSLT transformation will create an invalid send element in line 9: <send event="thisWillFail" conf:illegaltarget=""/<conf:illegaltarget=%22"/>>. 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
Received on Monday, 17 March 2014 14:55:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:44 UTC