OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-markup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrp-markup] Markup Fragment rule for VXML

Thanks, Walter,

This makes good sense, and I am sure we will 
include it and use it as a springboard for 
further discussions. We will probably have to ask 
the overall TC if they are willing to support a 
subdialog, but I think it is a good idea. The 
root document is another question. Would this be 
better framed as a separate document that the 
Portlet invokes? I think it might be a more 
difficult sell to ask for it in the WSRP spec 
itself. We will find out, however, in any event.

Both of these are fairly largish issues, compared 
to what is usually done for v1.1 work. However, I 
think we should frame the argument for these two 
items and VXML in v1.1 as something that we want 
to use sooner rather than later and get feedback 
before the timeframe for v2.0. I think it is 
better to stay with the tech dev curve rather 
than lag behind it, which is what will happen if 
we wait for v2.0. However, asking for it in v1.1 
will certainly necessitate some discussion, so 
you might want to be prepared for that when the 
time comes.

For the WSRP-Markup SC, we should chat about this today.


At 2:48 PM +0200 10/15/03, Walter Haenel wrote:
>Hello Rex,
>I tried to contact you on Russell's email address, but I did not get any
>response. Thus, I had no chance to talk to Russell.
>To get something moving for VXML, I will add some initial thoughts. I added
>the official markup mailing list and hope it will work this time.
>Fragment Rules for VXML
>- A device supporting VXML needs considerable performance, to do the voice
>recognition and the text to speech translations. With this processing power
>in mind,
>   it does not make sense to restrict the usage of the VXML language for
>performance reasons. The performance necessary to drive  the VXML
>interpreter will be small
>   compared to the performance requirements of the other tasks.
>  This would allow the usage of all VXML tags, which can be used between
><VXML> and </VXML>
>- The voice navigation needed in the portal, e.g. to finish the call, to
>leave the portlet, to return to the portal main menu has to be added to the
>portlet output, since the portlet is coded
>    without being aware which words are used for these commands, nor which
>commands exist at all.
>    There are 2 possibilities to add the navigation commands to the portlet
>       a.) by including them into each portlet document
>       b.) by including a reference to a portal root document, which itself
>holds the needed declarations
>- Typical voice applications make use of an application root document
>       Will we support this?
>- VXML Browsers offer the possibility to isolate parts  of an VXML
>application by putting this part into a VXML subdialog. Running the portlet
>as a subdialog
>   would give us this feature as well, and prevents the portlet to modify
>the VXML behavior of the portal. I propose to use this feature.
>   The portlets would then have to code a <return/> statement at their
>ending point instead a <goto next="id dont know where to go"/>.
>   The VXML interpreter implicitly would know where to go.
>Mit freundlichen Grüßen /
>                   Have a nice day
>                     Walter Hänel
>Pervasive Computing - Portal Development
>Tel. +49-7031-164523
>              Fax +49-7031-164888
>To unsubscribe from this mailing list (and be 
>removed from the roster of the OASIS TC), go to 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]