On 8/25/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
I have few initial concerns after looking over the excellent
documentation and examples on the Commons SCXML site.
So far, my concerns are as follows:
1.) I'm not wild about having to run an XSL transform on dialogs
during compile time
<snip/>
Yes, sub-optimal, though an exercise in the following:
* Making sure the dialogs can actually map to SCXML
* Support two XML vocabularies with one engine
but the SCXML approach to configuring dialogs
seems to involve excessive XML if you're not using UML.
<snap/>
Correct. Character-to-character, it has higher verbosity. But, at the
notation level, it does satisfy this -- simple things should be
simple, other things should be possible. It does useful things, to
name a few:
* Allow executing content on a transition
* Allow arbitrary levels of recursion in composite states (without
breaking into a subdialog)
* Allow parallelism
Don't get me wrong.
<snip/>
Please don't worry about that. All constructive criticism is highly
welcome, and can only benefit all projects involved. So, please don't
hold back ;-)
Its a very cool concept but I'm not sure going from UML to
dialog config is the most important feature in a dialog solution.
<snap/>
I do this for every dialog. I do understand others may not.
2.) Each dialog needs its own SCXML file. In one extreme use case
where you have a ten step dialog and you want to have individual
single step dialogs for each of ten steps, you'd need 11 SCXML files.
<snip/>
Correct, valid point. As part of this process, we can explore ways to
alleviate this, but nothing jumps at me right now.
3.) Global transitions need to be configured in each of the SCXML
files (is that right?)
<snap/>
The notations are very symmetric. If you would define global
transitions in more than one dialogs, then you need them in more than
one SCXML files. If you define them in one dialog, you need them in
one SCXML file (and so on ...).
As a bonus, SCXML gives you local transitions, global transitions and
many layers in between (depending on how you nest the states -- again,
this goes beyond the current dialog notation).
While I realize these should be ideally coming
from the UML, the reality is a lot of people will not be using SC to
design their dialogs.
I haven't made up my mind on SCXML - in fact I seem to be swinging
back and forth. Even if we don't go with it right away, I think it
merits further study (and a place in our sandbox.)
<snip/>
As I've said before, and opened a JIRA ticket for it, I'm happy to
take this experiment to some sort of conclusion over the coming weeks.
There is always going to be inertia when a new notation comes into
picture. IMO, the current notation definitely deserves credit and does
its job given the usecases its seen till date. However, when I look
out into the distance, I see many more reasons why supporting SCXML
makes sense as outlined on the top of this thread.
Its a traveling weekend, see you on its other side.
-Rahul
I'm curious as to what others think.
Sean
<snap/>
