@Sean - I take it you are using this attribute? Any ideas here? Can you please explain (again) how you use it? There may be other ways to achieve the desired results, from an SCXML PoV. Ofcourse, that will only be applicable for new applications.
Basically there were a bunch of shortcoming in Shale dialog (many of which we are talking about addressing now) so I had need to subclass DialogImpl with my own class. The configuration stuff that shipped with shale assumed that your dialogs would be the DialogImpl class which was inconvenient. So following the DRY principle, I asked Craig to patch in the classname attribute so that users could take advantage of the digester rules, etc. I would say this would be a useful feature to have in any future direction of Shale dialogs. The fact that Dialog is an interface would suggest its expected that users might provide their own impl. It would suck for users to have to provide their own configuration when the default one was 99.9% sufficient.
-Rahul
Sean
