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

Re: External communication with SCXML

From: David Junger <tffy@free.fr>
Date: Tue, 12 Feb 2013 22:03:45 +0100
Message-Id: <8D2C2699-5090-49BA-A881-EF0AF13C017A@free.fr>
To: "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Le 12 feb 2013 à 18:54, Stefan Radomski a écrit :

> I implemented fetch as a custom executable content, but there are some questions:
> - What does it mean for the type to be "url"?

It means using url encoding (name=value&name2=value2&…) and it sets the default Content-Type header to application/x-www-form-urlencoded.

> - How do you represent xml data in the event that is being delivered to the interpreter?

As you would expect from a thin wrapper around XHR, XML data delivered to JSSC in response to a <fetch> request is available both as plain text and as a parsed Document, since I just reference the XHR object in the callback event's data (so you have _event.data.response, _event.data.responseText, and _event.data.responseXML if the response had an XML content-type and contained well-formed XML).

> The relevant part in the draft is at [1]:
> "data. This field contains whatever data the sending entity chose to include in this event. The receiving SCXML Processor should reformat this data to match its data model, but must not otherwise modify it. If the conversion is not possible, the Processor must leave the field blank and must place an error 'error.execution' in the internal event queue."

That doesn't actually apply to <fetch> because it doesn't involve an I/O Processor. The event is, in principle, being generated by the client-side platform, not by the host sending the HTTP response.

> As you are using the ECMAScript datamodel, I was wondering, whether you attempt to transform the XML into JSON (no bijective projection) or how you expose the XML in the event.

Document objects are valid ECMAScript data. I don't need (and I don't want) to transform them into JSON, because Document objects have all the nice DOM methods for navigating them, for free. Document objects can be quite easily transformed into JSON if they have to, basically they just lose all their methods and each node can only link to its children (not parents or siblings) to avoid circular references.

Of course, if you're implementing an interpreter on the server, you don't have such a nice and free DOM integration.

By the way, if you pass an ECMAScript object which isn't an instance of Document or Element as data to a <fetch> with type="xml" it will raise an error.execution, as that problem is a lot harder and even impossible without some metadata.

Received on Tuesday, 12 February 2013 21:04:15 UTC

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