- 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