[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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?
How does the Portal ensure that just one portlet is being "spoken"? e.g. use of Window state maximized?
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.
Is any of this data from the portlet (per-command)? If so we need a way to carry these portlet <-> consumer.
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?
An example of portlet specific input would answered these, I sure.
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]