On 8/24/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> I'd like Shale to support both the current dialog notation and SCXML
> as stated here [1], and both can use the same underlying engine. The
> current dialog notation by virtue of being the incumbent, and SCXML
> because:
[snip]
If we go with SCXML under the covers, I'm definitely +1 on having both
syntaxes available. That way, we can appeal to the crowd who wants the
simplest possible syntax for this stuff, and then potentially seduce them
into leveraging the more sophisticated capabilities of the entire state
machine later. (Of course, we'd also want to make sure that the features we
expose to the developer can also leverage those capabilities.)
<snip/>
Yes, that makes good sense to me.
To that end, it would seem that an XSLT transformation of the existing
dialog-config.xml to the SCXML version would be ideal, if it is technically
feasible (and I think Rahul and I concluded earlier that it is). That way,
I could either build the transformation into my build process (to save a
little startup time) or just let the runtime take care of it at application
startup.
<snap/>
OK, I will look into this. The only wrinkle that comes to mind is the
dialog-config.xml contains many dialogs (hence many SCXML documents).
I should have a better perspective on the XSLT transform early next
week.
-Rahul
Craig
