RE: Recommendation for new behavior for <subdialog>

Everyone's style of application building may be different and everyone's use cases may naturally be different.  I've found, in my experience, that people who come from a procedural programming model sometimes overly gravitate to subdialog because it feels like a function call to them and then overly use it.  I'd advise that, and again this is just my experience so YMMV, but my rule of thumb is if the same author is writing both sides of the subdialog then there is a 95+% chance that they are using it wrong.  Subdialog shines when one application needs to call to another application.  For instance, a travel site's VXML wants to invoke a specific rental car companies VXML.  Or if a platform wants to expose some functionality (CTI connect, Voice authentication, Multimodal sessions) and an application by a company on that platform wants to call it.  We also used it early on for ad serving on a voice portal (subdialog into the add server, it returns back - sort of like a 302 redirect for banner adds but capable of richer prompting semantics than just URL replacement).

Some people, especially engineers who have the DRY philosophy and look for opportunities to factor code also use, over use, or hope to use subdialog to create general purpose application agnostic reusable dialogs.  Like, the "perfect" dialog to capture credit card information that multiple applications can subdialog to.  IME this doesn't work well.  The main reason is while there is some stuff that is useful to share between different applications doing credit card capture, there ends up being a fair amount that should be different or skinned between the different applications - at least this tends to be the case for high quality applications and those supporting large business IVRs.  There is often different voice talent that needs to be used for recorded audio (ok, pass in a different base URL for the module and record the audio in all the voice talent needed), plus different TTS voices needed (ok, pass in different voice names into the subdialog and do the if trick from your previous message for each and every possible TTS voice), plus there is often subtly different command grammars that need to be active (one client for whom "operator" must always be active and take them to an operator, anther for whom dtmf 0 does that, and another for whom dtmf ** does that) - ok pass in parameters to define this either through content through command grammar URLs (even though in the application calling they may not be separate external grammars but may be link tags in the application root), etc.  In practice, when I've seen this done there tends to be so much creep of parameters that gets passed into the subdialog that it isn't a clean implementation.  There are other reuse boundaries that work better like the grammars for recognizing the credit cards can be external URLs and shared, the JS to process check sums and the right number combinations with the right credit card types can be hosted as external JS and those can be shared, etc.  Reusing those resources, rather than the full dialog, works better, IME.

All that said, if the aspect of subdialog that you like is the ability to return back to the previous form you can do that using goto and storing just one variable, the URL on which to go back.  If you make that variable a JS Array (history array) that you push and pop to you can get a full call stack.  If what you want is a filled processing on return, you can emulate that with a block at the start of the function that has a cond to a global Boolean variable that is TRUE when "returning" and made false at the start of each such "return" block, and then set to true right before you goto the URL that you pop out of the history array.  The only bit this misses is the dialog scope variables when you return, but if you want that you can store the dialog scope in JS history array, you can also store any return variables in such an object.  Depending on the complexity of your application, and the number of variables you pass back and forth, this might be cleaner than the current way you pass everything to the subdialog, assign it, use it, return from subdialog, and set everything back again.  On our platform we have an extension that reflects your current URL to the document and your current URL to the dialog so the pushing of the location information is easy and programmatic, but even without that using relative URL should be straightforward inside one application.

If there were to be an extension to the language to support the semantics that you like, I'm not sure it would make sense to overload subdialog with it, instead of a new tag that has the exact semantics that you like (if you share application contexts, would you really want to pass parameters?  And have the parameters need a var tag to accept them? etc.).

From: David Wright [mailto:David.Wright@OntarioSystems.com]
Sent: Wednesday, May 21, 2014 11:57 AM
To: www-voice@w3.org
Subject: Recommendation for new behavior for <subdialog>

The <subdialog> feature of VXML 2.1 is a great improvement over just <goto> call flow.  However, I have never found a benefit to having a fresh variable context when calling a form via <subdialog>.  Other users may rely on this, so I recommend an alternate behavior based on a new attribute or a new tag.  This alternate behavior would allow the form that is called via <subdialog> to execute in the same application context as the caller.

In order to get around this, I currently pass all of my variables to forms that are called by <subdialog> as javascript objects with lots of properties.  And I have to pass them with temporary names and assign them back to their real names immediately inside the form I'm calling.

<var name="sessionArgs">

<subdialog name="sub_verifyIntro" src="#s102_Verification1">
       <param name="tempSessionArgs" expr="sessionArgs"/>
       <filled>
              <!-- do something -->
       </filled>
</subdialog>

<form id="s102_Verification1">
       <var name="tempSessionArgs"/>
       <block>
              <assign name="sessionArgs" expr="tempSessionArgs"/>
       </block>
       ...
</form>



David Wright, OFS
Senior Software Engineer
Ontario Systems, LLC
765-751-7233


[https://no-cache.hubspot.com/cta/default/159435/96c76b68-b911-464a-b811-210d8e4954c1.png]<http://tinyurl.com/ndzpd5y>
Join Ontario Systems at PowerUp 2014. Visit the website and register today.  Register today<http://tinyurl.com/qz6a57q>.