[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-markup] Strawman for VXML Fragments
Andre, please see my remarks below. Should be in this color and starting with --> Mit freundlichen Grüßen / Have a nice day Walter Hänel Pervasive Computing - Portal Development Tel. +49-7031-164523 Fax +49-7031-164888 Andre Kramer <andre.kramer@eu. citrix.com> To Walter Haenel/Germany/IBM@IBMDE, 25/02/04 17:39 rexb@starbourne.com, wsrp-markup@lists.oasis-open.org cc Subject RE: [wsrp-markup] Strawman for VXML Fragments My questions on the call were concerned with: How does the portlet / consumer negotiate when to use voice? Is it just a mime type we should document? --> the mime type should be text/vxml How does the Portal ensure that just one portlet is being "spoken"? e.g. use of Window state maximized? --> this is up to the portal, but the use of the Window state maximized is a good way to implement this. Does the portlet have to supply any of the application root data? In particular, the "your grammar definition for voice ...... your grammar definition for DTMF" example placeholders. --> no, since these grammars should not be portlet specific, but should be Portal specific. For example, one portal may use "go back" and "*8" to generate a go-back event, while the next is using "return" and "*1". The portlet code has to be independent from this Portal specific implementation Is any of this data from the portlet (per-command)? If so we need a way to carry these portlet <-> consumer. --> All data in the application root document should be independent of the portlet. How is input done? I suspected a http request back to the consumer Portlal, but how do we turn it into an performBlockingAction back to the WSRP producer / portlet? --> Yes, as in HTML a HTTP request will carry the collected data back to the portal. There should be no difference how this is performed between HTML and VXML. An example of portlet specific input would answered these, I sure. --> working on it thanks, Andre -----Original Message----- From: Walter Haenel [mailto:HAENEL@de.ibm.com] Sent: 20 February 2004 14:15 To: rexb@starbourne.com; wsrp-markup@lists.oasis-open.org Subject: [wsrp-markup] Strawman for VXML Fragments Hello Rex, I hope, this come still in time. I had some time during the flight to work on it. A review of the proposal would help as well as a checking of my wording. It may not always be correct English. A more complex example showing the correct use of the "go back" command inside a portlet my also be useful. I talked to my colleague who is representing IBM in the VXML group. As far as the specs themselves go, 2.0 is pretty-much done. It would take a major issue to get anything in it changed. The 2.1 spec is being worked on by the W3C, but has not been announced yet. It's possible to bring the fragment idea up, but that's may be outside the scope of what 2.1 is about. May be, getting it into the spec is not really what we need. It seems like a technical note could also be reasonable for describing fragments. Here my proposal for the VXML 2.0 fragment rules Background: Portlets following the new standards such as WSPR or JSR 188 have to emit a markup fragment which gets integrated into the overall output of the portal by the portal framework. While the standards define the behavior and APIs for the portlets, they do not specify the fragment rules since they have to be defined for each markup language independently. This proposal is a first step to define the fragment rules for VXML. A standard function of the portal framework is to enable the user to navigate through the portal content and open and close the applications. Unlike the visual markups, where the portal framework could place additional controls arround the fragment output to open or close the application, voice is missing this possibility. Additional voice commands, which should be available throughout the application, have to go into each voice dialog. The only means available in VXML is the usage of an application root document. If the portal framework is generating this document, it could add additional active grammars and error handlers to the portlet output, without the need to modify the portlet output. This leads to the first requirement, that it should be possible for the portal framework to generate and define the application root document. When a voice portlet reaches its final state, there has to be a way, to return the control to the Portal framework. This should be possible also for the case, that the user is not actively stopping the portlet action by a voice command such as "stop portlet" or "go back". Since the portlet has no knowledge on which system it is running, it can not just use a goto statement to return control to the Portal Framework. Especially for reusable voice dialogs, VXML has introduced the subdialog construct. Since portlets represent reusable dialog components, it is most natural to implement the portlet dialog as a subdialog, and return control to the Portal framework by the use of the return statement. Furthermore, VXML 2.0 requires, that each subdialog will be executed in its own execution environment. This will add the additional benefit of the isolation of the portlet execution from the Portal Framework execution in the Voice Browser to the system. Because of this, our second requirement will be to structure the portlet dialog as a subdialog. Since Voice Browsers queue audio output and proceed with the execution of the VXML markup, the control flow of the VXML interpretation is not always in sync with the Audio output. This may result in usage problems, since the user of the voice portal has the experience of still being in portlet 1 while he is listening to the output of the portlet 1, while the control flow of the VXML interpretation may already be in a different portlet, portlet 2. If the user now issues a command valid in the context of portlet 1, the VXML interpreter will interpret the command in the context of portlet 2. This may result in unexpected and wrong behavior of the voice portal. This situation can be fixed, if the voice browser is forced to synchronize the output with the current state of the VXML interpretation by inserting a field after the last prompt of the portlet. This would be requirement 3. To give the VXML portlet writer some guidance, which functions he could expect from the externally introduced grammars, I recommend that each voice portal should at least introduce the following command functions: "go back" this function will be similar to the behavior of the back button of a web browser, in that it returns to a previous dialog. The default behavior while spoken inside a portlet should be to close the portlet application and to return to the Portal Framework. and "Start all over" This command should return the user to the entry point of the portal. Of course, the proposal only describes the function and the actual grammar used to detect these commands will be language dependent and is up to the portal implementation. These two commands allow the portlet programmer to assume, that any user which indented or accidentally entered the portlet has already an consistent method to exit from the portlet, and thus the portlet programmer can concentrate on its main task to implement the required portlet functionality, while the user experiences a common behavior throughout the portal. To even further extend the common user experience, it should be possible that complex portlets may intercept the "go back" function and only go back one dialog inside the portlet. It is only required, that a sequence of repetitively spoken "go back" commands finally leaves the portlet. To allow the portlet to intercept the default behavior of the "go back" function, the application root document should generate an "portal.nav.goback" event, which could be intercepted by a local event handler. The default behavior has to be implemented by an event handler in the application root document . The above requirements could be fulfilled by the following fragment rules: - The portlet fragment has to be VXML 2.0 - The fragment produced by the portlet has to fit syntactically between the <VXML ....> and </VXML> tags. - the portlet has to be written as a subdialog, which requires, that at the end of the control flow a "return" statement is issued. Also a portlet must not use the "exit" tag, nor is it allowed to just end the control flow, since this is equivalent to an "exit" tag. - The portlet can assume that a spoken "go back" command generates an portal.nav.goback event, which may be caught by a local event handler. - The portlet has to code a field or menu after the last output to synchronize the user experience with the state of the VXML interpreter - The event which will be generated by the portlet framework on a "go back" command is "portal.nav.goback" Example Portlet Output: The example shows the output of a Weather Portlet announcing the weather in the 2 preselected cities Osaka and Tokyo. How these cities get preselected is out of the scope of the current example, but one could assume that this may be done by some personalization rule of the portlet, depending on the address of the current caller. The first part of the output is generated by the portal framework, and has to contain the XML tag as well as the VXML tag. Inside the VXML tag the portal framework has defined the URL pointing to the application root document for the portlet. The next part is the complete output fragment of the portlet. Despite the fact, that the portlet generates only output, the prompts are included into a menu with no choices to achieve the synchronization of the output with the state of the VXML interpretation. The VXML interpreter will now start the output of the prompt and wait till it is finished. Then it will wait another second and catch the noinput event. The processing of this event will end the portlet by using the return statement. Since the menu has no choices, this is the only way to leave the portlet, beside the possibilities delivered by the application root document which are "go back" and "start all over" At the end, the Portal Framework has to insert the closing VXML tag. ----------------- generated by Portal Framework ------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE vxml PUBLIC "vxml" > <vxml version="2.0" lang="en_US" application="/wps/myportal/portletroot" > <meta name="Content-Type" content="text/x-vxml"/> ----------------- generated by Portal Framework ------------------------------------- ----------------- generated by Portlet ------------------------------------- <menu scope="dialog" id="weather"> <prompt> The weather Portlet. All temperatures are in: degrees Fahrenheit. Following cities are selected: </prompt> <prompt>Osaka: temperature 70 degrees Sunny</prompt> <prompt>Tokyo: temperature 66 degrees Partly Sunny</prompt> <prompt timeout="1s">This was the last city.</prompt> <help>The help for the stocks portlet.</help> <noinput><return/></noinput> </menu> ----------------- end generated by Portlet ------------------------------------- ----------------- generated by Portal Framework ------------------------------------- </vxml> ----------------- end generated by Portal Framework ------------------------------ The application root document generated by the portal framework should hold following fragments to enable the processing of the defined commands: <!-- go back : overwrite it in your document --> <link event ="portal.nav.goback"> your grammar definition for voice ...... your grammar definition for DTMF </link> <catch event="portal.nav.goback"> your portal default handling to end the portlet execution </catch> <!-- Portal Home --> <link event ="portal.nav.startover"> your grammar definition for voice ...... your grammar definition for DTMF </link> 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 http://www.oasis-open.org/apps/org/workgroup/wsrp-markup/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]