Home » Archived » Voicetools » Voice Tools Development Call Minutes: July 12, 2005
| Voice Tools Development Call Minutes: July 12, 2005 [message #6707] |
Tue, 12 July 2005 15:16  |
Eclipse User |
|
|
|
Eclipse Voice Tools Development Call Minutes
July 12, 2005, 11am EST
Attendees:
David Varnes
Joe Oh, Audium
Jeff Fried, Empirix
Brent D. Metz, IBM
Lenora Wright, IBM
Jeff Pedigo, SandCherry
John Buttitto, SandCherry
Michael Greenawalt, TellMe
Derek Barnes, VoiceGenie
The call began with a summary of the week's efforts, notably the completion
of the Eclipse Voice Tools Project's
SpeechTEK presentation. The presentation was offered to anyone who is
interested in seeing it ahead of time to
help communicate the project. A face-to-face meeting during SpeechTEK was
discussed.
The project's scope and the initial project plan was discussed. Due to the
overwhelming interest in standards-based markup
editing, Brent stated that the project plan would focus on markup editors as
the primary focus of the initial 1.0 project plan.
SISR/ECMAScript validation and content assist were brought up as examples of
additional innovation that is possible in the
markup editors. Other ideas for markup-oriented tooling included HP's
contributions of wizards and schema support as well
and grammar format (ABNF <-> XML) converters.
The point was raised that several implementations differ in what they
consider to be legal syntax. It was agreed to follow up
offline with some examples. It was stated that implementations which
required violations of the standards would not be
accomodated.
Callers not on last week's call were asked about their position on
contributing to the project and what they were interested
in seeing in the project's initial release. One participant stated an
interest in contributing annotation tooling, testing resources
and test fixtures to make testing of the standard markup possible.
A discussion of working on a joint article on how to extend or contribute to
the Voice Tools Project source tree occured. Several
participants expressed interest in creating the article, which would be
published on IBM's developerWorks web site.
|
|
|
| Voice Tools Development Call Minutes: August 11, 2005 [message #6752 is a reply to message #6707] |
Thu, 11 August 2005 14:30  |
| Eclipse User |
|
|
|
Eclipse Voice Tools Development Call Minutes
August 11, 2005, 11am EST
Attendees:
Joe Oh, Audium
Frederic Gloppe, HP
Brent D. Metz, IBM
Lenora Wright, IBM
John Buttitto, SandCherry
Jeff Pedigo, SandCherry
Michael Greenawalt, TellMe
The call began with a recap of the conversations Brent had begun with the
Eclipse Foundation regarding
the steps necessary to promote the project to the Implementation phase. The
current impediment appeared to
be multiple organizations basing product deliverables off to the VTP at the
time of the review. It was
stated that this may cause schedules to change to allow for increased
maturation of the VTP in the
validation phase versus in the implementation phase.
A summary of the SpeechTEK marketing initiatives for the project was
presented by Brent and Frederic. The
vendors at the were was stated to have a heavy usage of eclipse, both
publicly and internally and sentiment
for the VTP was said to be overwhelmingly positive among these vendors.
A discussion of execution APIs followed, starting with a high level overview
of what features a execution API
would provide as standard cross-browser function. The topic of how
structured to make eventing back from the
browser was discussed at length and many alternatives were proposed, from
new events extending the existing
debug framework to unstructured eventing to simply pass messages back and
forth to the UI. The functionality of
each vendor's current browser implementation was discussed from the
perspective of what could be provided in an
API. It was proposed that we simply allow browsers to return unstructured
markup back to the UI along with a
processing layer to extract meaning for each browser. Along this line of
discussion integration with a VoiceXML
Forum Data logging format was proposed.
The question of whether or not the WTP had any web-oriented debug
architecture in place was raised.
No one on the call could answer authoritatively. It was suggested that
VoiceXML is a uniqely client-oriented
programming language that demands dynamic content debugging support in a
higher priority fashion than other
client scripting languages such as JavaScript in a web browser, and
therefore is likely to be the first
implementor of such a layer of functionality.
The question of whether or not to include Debugging API support in the
initial release of an execution API was
raised. While the callers expressed interest in starting with simply
handling execution, it was also the consensus
on the call that production of a Debug API would encourage vendors to add
debugging support to their browser
implementations. It was tenatively agreed that focusing on just the
execution API portion while being cognizant of
the need to extend the API into debugging relatively soon would be the
correct approach.
Perspectives on usage of the API were solicited from the partipants of the
call, with several scenarios of usage
proposed. It was commented that all executions of a VoiceXML browser
generally have some grounding in debugging
since they are taking place in a development environment. The lack of debug
support initially was agreed to be
more about practicality in adoption and development than in any user
scenarios. Scenarios such as correleating
an executing browser with a visual tool or performing automated test by
automatically driving browser input and
parsing browser output were discussed. Additionally, the topic of attaching
to a running VoiceXML instance was
brought up along with subsequent security issues. It was stated that by
leaving the specifics of how a browser
would be attached to or launched to the browser implementor that security
and privacy issues could be avoided
in the VTP.
As the discussion began to become more technical, it was asked if the
development list should be used. It was
agreed that further discussions on the nature of the execution API should be
taken to the list where more
concrete examples can also be proposed.
|
|
|
| Voice Tools Development Call Minutes: August 11, 2005 [message #572138 is a reply to message #6707] |
Thu, 11 August 2005 14:30 |
| Eclipse User |
|
|
|
Eclipse Voice Tools Development Call Minutes
August 11, 2005, 11am EST
Attendees:
Joe Oh, Audium
Frederic Gloppe, HP
Brent D. Metz, IBM
Lenora Wright, IBM
John Buttitto, SandCherry
Jeff Pedigo, SandCherry
Michael Greenawalt, TellMe
The call began with a recap of the conversations Brent had begun with the
Eclipse Foundation regarding
the steps necessary to promote the project to the Implementation phase. The
current impediment appeared to
be multiple organizations basing product deliverables off to the VTP at the
time of the review. It was
stated that this may cause schedules to change to allow for increased
maturation of the VTP in the
validation phase versus in the implementation phase.
A summary of the SpeechTEK marketing initiatives for the project was
presented by Brent and Frederic. The
vendors at the were was stated to have a heavy usage of eclipse, both
publicly and internally and sentiment
for the VTP was said to be overwhelmingly positive among these vendors.
A discussion of execution APIs followed, starting with a high level overview
of what features a execution API
would provide as standard cross-browser function. The topic of how
structured to make eventing back from the
browser was discussed at length and many alternatives were proposed, from
new events extending the existing
debug framework to unstructured eventing to simply pass messages back and
forth to the UI. The functionality of
each vendor's current browser implementation was discussed from the
perspective of what could be provided in an
API. It was proposed that we simply allow browsers to return unstructured
markup back to the UI along with a
processing layer to extract meaning for each browser. Along this line of
discussion integration with a VoiceXML
Forum Data logging format was proposed.
The question of whether or not the WTP had any web-oriented debug
architecture in place was raised.
No one on the call could answer authoritatively. It was suggested that
VoiceXML is a uniqely client-oriented
programming language that demands dynamic content debugging support in a
higher priority fashion than other
client scripting languages such as JavaScript in a web browser, and
therefore is likely to be the first
implementor of such a layer of functionality.
The question of whether or not to include Debugging API support in the
initial release of an execution API was
raised. While the callers expressed interest in starting with simply
handling execution, it was also the consensus
on the call that production of a Debug API would encourage vendors to add
debugging support to their browser
implementations. It was tenatively agreed that focusing on just the
execution API portion while being cognizant of
the need to extend the API into debugging relatively soon would be the
correct approach.
Perspectives on usage of the API were solicited from the partipants of the
call, with several scenarios of usage
proposed. It was commented that all executions of a VoiceXML browser
generally have some grounding in debugging
since they are taking place in a development environment. The lack of debug
support initially was agreed to be
more about practicality in adoption and development than in any user
scenarios. Scenarios such as correleating
an executing browser with a visual tool or performing automated test by
automatically driving browser input and
parsing browser output were discussed. Additionally, the topic of attaching
to a running VoiceXML instance was
brought up along with subsequent security issues. It was stated that by
leaving the specifics of how a browser
would be attached to or launched to the browser implementor that security
and privacy issues could be avoided
in the VTP.
As the discussion began to become more technical, it was asked if the
development list should be used. It was
agreed that further discussions on the nature of the execution API should be
taken to the list where more
concrete examples can also be proposed.
|
|
|
Goto Forum:
Current Time: Thu Oct 30 23:56:48 EDT 2025
Powered by FUDForum. Page generated in 0.30285 seconds |
Home