commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] Document validation and testing (was: BUG: Inner States with no InitialState)
Date Wed, 12 Apr 2006 16:20:03 GMT
On 4/12/06, Fasih <> wrote:
> <quote>
> Then, the validation and generation of test cases for path coverage
> around this transition has become one step easier. However, as you'll
> notice, this means that such support needs to be "layered"
> appropriately, the EL used needs to be amicable to introspection so
> the SCXML test tooling can be built on top of that, and so on ...
> </quote>
> There is more than meets the eye. Lets say, on connection.alerting I call a
> ccxml:accept, that's it. How do I proceed further, given that the custom
> action can expect something in the payload. I guess, what we want to do is
> not a model validation but a compilation. IMO compilation should be the
> first step.
> This is what I see compilation as.
> 1. Validate against DTD [Already in place]
> 2. Generate classes for events rather than allowing strings to be entered.
> Something like an abstract class Event {} And instead of saying new
> TriggerEvent
> we do a ConnectionConnectedEvent()). This should help
> eliminate the common typos. Having an interface would be even better as it
> will ensure that we dont make a mistake like ConnectinConnectedEvent also
> and not to use it.
> 3. Generate warning when for an event when there is a cond like "a eq b" and
> not "! a eq b"
> More ideas can be put in....
> Comments!!

Personally, I didn't understand the value of (2) very well and I'm not
very keen on (3) since I see no need for there to be any kind of
absolute expression closure for conditions on transitions for any
event. But (3) may be useful in certain scenarios, possibly yours ;-)

In any case, this discussion is somewhat of a bottomless pit -- and I
don't mean that in any negative sense, I find this interesting -- but
I suggest we stop here in the interest of others on this mailing list
who may not find this very relevant. To match that statement, I also
think the next thing one of us should do on this particular topic is
to post a concrete proposal or some code to convey our thoughts
better. Ofcourse, its generally a good idea to post proposals *before*
spending too much cycles, to gauge community interest. Finally, any
extensive "toolkit" would be beyond the scope of Commons SCXML.


> +Fasih

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message