commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] SCXMLDigester setNamespaceAware
Date Sat, 17 Dec 2005 18:18:56 GMT
On 12/16/05, Mike Sparr - <> wrote:
> Rahul,
> No, just namespace URIs (I'll confirm Sunday night), but as we
> constructed SOAP-ENV message within send tags, our web service wouldn't
> accept the format of the message.  After turning off setNamespaceAware
> (set to false), it worked?  We can either send via encoded URI (REST) or
> merely add the SOAP env and pass it on - very cool!
> Below is example of output to client (transform is determined by which
> plug-in they access, usually a servlet but can be IM Gateway, SMS
> Gateway,  etc., just implementing our plug-in Interface)...
> We transform
> vxml response depending on client (rich text, vxml, text, html, etc.).
> It's built to be very flexible, we can even interact with REST WS or any
> encoded URI access to an app via <var> and namelist along with URI as
> target.  I'm not sure about performance of the whole thing - may add LRU
> Cache - but it does what I wanted it to and qualifies as an end-to-end
> SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
> :-)  Probably first in the world I imagine!  :-O  Anyone need a bot
> built, in minutes?

Super! You've demonstrated what some of us have merely claimed to be
the advantages obtained by using Commons SCXML in web-based

 * Separation of "dialog flow" from "views"

 * The multiple channels and devices aspect (catering markup to device
and modality used by end user)

 * Event triggered messages sent to external components (servlets,
web-services calls, SOAP over HTTP, what have you)

This is great stuff, Mike :-)

> Given digester is Open, a knowing (or unknowing like myself) individual
> can theoretically customize as they see fit.  As such, perhaps just
> leave it alone or implement the solution you mention.

I see the theory, makes sense to give the SCXMLDigester class a
Factory flavor. I'll add this to my TODO list for the weekend, will
probably get to it tomorrow.

> As a final note, if you have any input to W3C spec, I suggest removing
> mutual exclusivity of either namelist vars OR send body contents.  I
> believe they are supposed to throw fetch.error or something.  Commons
> SCXML does not, but as I stated before, I think this is best as it's
> nice to  access to some vars in context that may not necessarily be used
> for messages, etc.

As far as feedback is concerned, the W3C based on my understanding and
experience (arguably, limited experience), is open to suggestions from
everyone. There are public mailing lists -- to which anyone can
subscribe, just like the lists here at Apache -- and offer feedback. I
would recommend you post any suggestions about the specification
itself on the Voice Browser Working Group's (the SCXML spec is
currently a Working Draft out of the VBWG) public mailing list.

> Cheers,
> Mike
> P.S. - where do you work? And are you in US?

I'm in the big apple, where the big blue keeps me busy during the day.


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

View raw message