On Mon, Jun 28, 2010 at 7:40 AM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: > Hi, > > I'm currently adding support for the data module, and I have a quick > question about the specification that I was hoping you could answer for me. > > For the <data> element, the src attribute can reference a URI containing a > legal data value. I think that what constitutes legal data values is defined > in the profile. <snip/>
Correct. > The specification of the ecmascript profile seems to imply > that legal data values should be formatted as JSON. But the browser runtime > also has good support for XML, and so I think it would be useful to be able > to specify whether the data referenced at the URI should be handled as JSON > or XML. <snap/> Sure, normative requirement in the ECMAScript profile is JSON support. XML may be supported in addition, there is a mention along those lines (9.2.3, "Evaluation of ... XML expressions may be supported.") > The handleAs property of the Dojo toolkit's > dojo.xhrGet<http://api.dojotoolkit.org/jsdoc/dojo.xhrGet>API is a good > example of what I have in mind for this. In the scxml > specification, is there any way to specify the way a referenced URI should > be handled? > <snip/> I don't expect the SCXML spec will define any such shorthand, as I expect this to be handled using underlying means. For example, the HTTP Accept header may be used in the request (in this case, XHR) to signal what the profile can work with -- minimally, "application/json" but additionally "application/xml" (and text/xml) as well. Similarly, the response header for "Content-Type" (matching one of those listed in the Accept) can be used as a switch to process the legal data value based on type of response. As an aside, the WG is in the process of simplifying error event names. WRT the script module, therefore, please do not spend any time (than you may have already) in producing internal events in the "error.script.errortype" category. -Rahul > Please let me know what you think. Thanks, > > Jake > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
