shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] Using SCXML to describe Shale dialogs
Date Sat, 26 Aug 2006 00:22:36 GMT
On 8/25/06, Sean Schofield <sean.schofield@gmail.com> 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/>

Mime
View raw message