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

Some issues with IRP Tests

From: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>
Date: Fri, 14 Mar 2014 21:35:53 +0000
To: "www-voice@w3.org (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <42361673-EAE2-430E-A282-002209722D13@tk.informatik.tu-darmstadt.de>
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="”/>. 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 Friday, 14 March 2014 21:36:19 UTC

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