Re: IRP for uSCXML

OK, I've fixed test350.  It was a weird error - the close quote in 
conf:systemVarExpr="..." was actually a weird special character that 
just looked  like a close quote. I don't know how I managed to do that, 
but I should be OK now.

I'll start looking at the rest of the issues.

On 6/24/2014 2:21 PM, Stefan Radomski wrote:
> On Jun 24, 2014, at 16:58, Jim Barnett <1jhbarnett@gmail.com> wrote:
>
>> For test350, does your transform by any chance give you any information on where the error is?  Mine doesn't, so I'm modifying things randomly, trying to find the problem without much luck.
> First it complained about the character encoding, after resaving as UTF-8 I got:
> Error on line 10 column 2 of test350.txml:
>    SXXP0003: Error reported by XML parser: The value of attribute "conf:systemVarExpr"
>    associated with an element type "null" must not contain the '<' character.
> Transformation failed: Run-time errors were reported
>
>> For test513, the extension is defined in section 5.3 of the IR Test Plan, in the paragraph titled "Extensions Required”.
> That’s ok - we already implement _event.raw for basichttp but we’ll skip on httpResponse for send - we already implement <fetch> as suggested by David. There is also an occurence of _event.raw with the *SCXML I/O-processor* in the tests iirc, if you feel like it’s important, I can look it up.
>
>> For 519, 520, 531, and 534, in what way is the behavior underspecified?   We thought the definitions in C.2.1 and C.2.2 were sufficient to define the behavior.  Which statements are vague or underspecified?
> Well, what is specified for the basichttp ioproc:
> 1. uses post with an application/x-www-form-urlencoded body when sending
> 2. if the event attribute is given, it becomes a _scxmleventname post header parameter
> 3. all namelist and param values become post header parameter as well
> 4. content becomes the application/x-www-form-urlencoded body of the http post request
> 5. if a single instance of the parameter _scxmleventname is present when receiving it becomes the event’s name
>
> With our implementation, the complete, raw post request is available in _event.raw.
>
> What is tested is:
>
> 1. from test519:
> <send event=“test” …>
>    <param name="param1" expr="1"/>
> </send>
>
> ought to end up as a string 'Varparam1=1’ in _event.raw - we do have a 'param1=1' http post parameter as per 3. No idea where that ‘Var’ prefix is coming from.
>
> 2. from test520:
> <send ...>
>    <content>this is some content</content>
> </send>
>
> ought to lead to an event HTTP.POST and raw ought to contain 'this is some content’. We do have 'this%20is%20some%20content’ as per 1&4. On a related note: are event names case-sensitive, in our implementation they are not, but I am not sure whether this is actually specified somewhere.
>
> 3. from test531:
> <send ...>
>    <content>_scxmleventname=test</content>
> </send>
>
> ought to lead to an event called “test”, but content is to be application/x-www-form-urlencoded and point 5 from above refers to post parameters, not encoded content? Our implementation will happily take an event attribute with the send element, a namelist entry or a param to create a _scxmleventname post parameter, but not urlencoded content.
>
> 4. from test534:
> <send event=“test” … />
>
> ought to lead to an event containing 'Var_scxmleventname=test’ in _event.raw but nowhere is that ‘Var’ prefix defined.
>
> Feel free to correct any misconceptions - my HTTP encoding knowledge is somewhat rusty and I’d prefer to pass those tests if you insist that they actually test what is specified in C2.1 / C2.2.
>
> Regards
> Stefan
>
>> On 6/23/2014 7:46 PM, Stefan Radomski wrote:
>>> Hi there,
>>>
>>> attached is the IRP report for uSCXML with the ecmascript datamodel. We pass most tests but:
>>> - the one where the XPath DM is hardcoded
>>> - test350 which fails to XSLT transform
>>> - test513 which tests for an unspecified http extension
>>> - test[519,520,531,534] which rely on an imho underspecified behavior of the basichttp ioprocessor
>>> - test579 with the recent addition of history transitions
>>>
>>> We do implement parts of the XPath DM but prefer not to submit an implementation report for it.
>>>
>>> Tests were:
>>> - performed on a Mac with JavaScriptCore for the ECMAScript datamodel implementation
>>> - validated on Linux with Google’s v8 for the ECMAScript datamodel implementation
>>> - fetched at 06/23/2014 - 4:22pm
>>> - run with uSCXML commit id 3d3f6a693ac51bca9b77133783a0fb296abd7ff6
>>>
>>> This submission is done to the best of our knowledge - if you cannot reproduce these tests, or there is a formal error with the submission please contact us.
>>>
>>> Best regards
>>> Stefan
>>>
>> -- 
>> Jim Barnett
>> Genesys

-- 
Jim Barnett
Genesys

Received on Tuesday, 24 June 2014 18:59:34 UTC