Enhancing SSCXML

Ok... so as you might have read I plan to improve SSCXML (Simple State Chart XML) to mirror a little bit better what is actually written in the W3C draft. One thing that is mentioned in the latest version of the draft is the split into different parts such as the data module, the script module etc.

Although they describe them as being two different parts, they mention (in the same time) that the data module must provide a data access language which will allow to access the data stored in the data module.

Now, this sounds like a great idea, but IMHO this also implies that a complete expression parser must be included in the data module. Why? Because once you define a "language" that enables you to access the data, there are also some operations that you want to handle: using a variable to index an access to an array of variables ("a[b]" or "a[10]") or combine variables to create a new one (AKA as assign a value to another variable). Those are two examples of what ideally should be possible with the data module.

Unfortunately this implies a lot more: In fact, implementing a data access language into the data module ultimately means that you have a complete expression parser implemented to access, assign, handle, alter and delete the data.

And there's now the notion of the script module. According to the draft, the script module adds scripting capability to the state machine. They're giving the example of ECMAScript (aka JavaScript).

Now, think a second about what I've written above... complete expression parser... script module... You see it? Yes... for a developer this basically means the same: When you want to include scripting into your state machine, you automatically also have the data module, since you cannot script without holding a basic set of data. This means that for a programmer the data module almost always goes in combination with a script language and vice versa.

Now, my idea is this: The data module is only there to store data is using a very basic scheme: values put into relation with an identifier. For every value pushed into the data module, an identifier must be given. If an identifier is used twice, the previously stored data is replaced by the new value.

This notion of the data module has some advantages and some drawbacks:

Pros:
- no expression parser must be included.
- replacing data is easy.
- the data module is not responsible for solving the value addressing.

Cons:
- Access of large datasets might be more difficult
Example: a is an array of 1000 values. You can access a value by directly indexing it. Since the data module only has simple identifiers, an array must be mapped to a simple scheme such as "a[10] -> a.10" (access the 10th element of an array).
- The script module/expression parser is responsible to create unique ids and to verify that data is handled as expected (IE. temporary data storage).
- The data module would have no garbage collection.

To solve some of the issues, it is important that the value that is actually stored within the data module, is as flexible as possible. Also, one might want to have the possibility to enable the developer to implement his own data values (IE. an object, a specific data type, etc.). The data module must not now how to handle these new data value types. It only has to store them and provide access to them.

I'll write about the interfaces themselves tomorrow. So... keep coming back to take a look at it :)

Have fun and a happy New Year,
Stefan