W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2005

RE: Argument in Favor of Keeping the <object> Element

From: <ken.waln@edify.com>
Date: Fri, 23 Sep 2005 04:45:46 -0700
Message-ID: <5076FACEDACF624B965A87041DD1F9CA19E18E@x2.edify.com>
To: amelica@uui.com, www-voice@w3.org

I didn't know this was a discussion item, but I agree with this completely.
The Object tag provides a way to offer extensions without special markup and
is therefore "more standard". Although compatibility may imply rewriting the
object routines to go to a different platform, you don't need to rewrite all
of the VoiceXML. Also by doing through the Object tag, customers can write
their own extensions (for example for a custom CTI environment) whereas a
proprietary markup does not allow that. Even if a future version of VoiceXML
includes these example features there will always be new ones people think

-----Original Message-----
From: Antoniu Melica [mailto:amelica@uui.com] 
Sent: Tuesday, September 20, 2005 5:37 PM
To: www-voice@w3.org
Subject: Argument in Favor of Keeping the <object> Element 

Dear Voice Browser Working Group,

It has recently come to our attention that the usefulness
of the <object> element has been under question. We wish
to make a strong argument in favor of keeping this element.

Our voice platform has two programming interfaces: C++ and
VoiceXML. Through our C++ interface, we provide several
features for our customers that are not yet available in

  * Speaker Verification
  * SS7 Signalling
  * Call Center Integration

Realizing the benefits of VoiceXML, our customers are
starting to port their legacy applications to it. At the
same time, however, they cannot give up the above core
technologies they depend on. As such, we have made these
technologies available to them via VoiceXML <object>s.

Without the <object> element, we would have to resort to
alternative schemes, none of which we favor:

  1. Ad hoc, platform-specific language extensions.

  2. Using the <submit> element. This would be ugly and
     difficult to use at the application level, and
     inefficient and difficult to implement at the
     middleware level.

There is one more alternative: to wait until these
technologies are formally added to VoiceXML. This would
be bad for our company since we could not market our
advanced technologies through VoiceXML in a timely manner,
if ever; bad for our customers since their migration to
VoiceXML would be significantly delayed, or postponed;
and bad for the VoiceXML community at large since
potential new adherents would shy away.

The disadvantage of having the <object> element is that
some applications are no longer universally compatible
with all interpreters. We, however, believe that the
advantages far outweigh the disadvantages in real-world

Thank you,

Antoniu Melica
Magellan Communications
Sunnyvale, CA
Received on Friday, 23 September 2005 11:42:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:38 UTC