Re: updated SCXML draft

Here is my review of the C.2 section.

C.2

What's this about E4X? is the E4X ghost haunting the Web still?

C.2.5

> The Processor may convert the expression result to a string in contexts where a string is expected


Please, no. What you suggest is just like PHP's infamous magic_quotes. That would lead to incompatible documents if someone were evil enough to do it. I know, nested quoting is annoying. But there is no other way. It's the ECMAScript data model, not the Plain Text data model.
BTW, please revert your change in the example in C.2.1.

C.2.8

> while data is either  an Object or a String  value.

I must remind you that <content expr/> or <content> with an atomic JSON value inside may result in something which is neither an object nor a string. Therefore, _event.data can have *any* type. You see that type frequently in ECMAScript-related documentation.

> For the _ioprocessors system variable the Processor must create an array


Why an array? it's much more elegant to use an object with named properties, as your own examples do. The language is confusing. Arrays in ECMAScript can have named properties but those don't count as items in the array and are not iterable. Just call _ioprocessors an object.

C.2.8.1

I don't like that the spec forbids platform-specific parsers for incoming data, nor allows senders to override the heuristics (e.g. by providing a MIME type, as I suggested before).

An obvious example: I want to parse HTML markup as a DOM too.
Also, I want to be able to tell the platform NOT to fall back to plain text if there is an XML error, so that I can see the XML error document.

C.2.9
should say something about the platform being unable to serialize at all. Do we raise an error.execution or just give a warning?

C.2.11
see my last message in the thread "IPR tests, part 1"

			David

Received on Wednesday, 10 April 2013 20:59:43 UTC