VoiceXML (VXML) is the W3C's standard XML format for specifying interactive voice dialogues between a human and a computer. It allows voice applications to be developed and deployed in an analogous way to HTML for visual applications. Just as HTML documents are interpreted by a visual web browser, VoiceXML documents are interpreted by a voice browser. A common architecture is to deploy banks of voice browsers attached to the Public Switched Telephone Network (PSTN) to allow users to interact with voice applications over the telephone. for details visit http://www.voicexml.org
Usage
Many commercial VoiceXML applications have been deployed, processing millions of telephone calls per day. These applications include: order inquiry, package tracking, driving directions, emergency notification, wake-up, flight tracking, voice access to email, customer relationship management, prescription refilling, audio news magazines, voice dialing, real-estate information and national directory assistance applications.VoiceXML has tags that instruct the voice browser to provide speech synthesis, automatic speech recognition, dialog management, and audio playback. The following is an example of a VoiceXML document:
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"> <form> <block> <prompt> Hello world! </prompt> </block> </form> </vxml>When interpreted by a VoiceXML interpreter this will output "Hello world" with synthesized speech.
Typically, HTTP is used as the transport protocol for fetching VoiceXML pages. Some applications may use static VoiceXML pages, while others rely on dynamic VoiceXML page generation using an application server like Tomcat, Weblogic, IIS, or WebSphere.
Historically, VoiceXML platform vendors have implemented the standard in different ways, and added proprietary features. But the VoiceXML 2.0 standard, adopted as a W3C Recommendation 16 March 2004, clarified most areas of difference. The VoiceXML Forum, an industry group promoting the use of the standard, provides a conformance testing process that certifies vendors implementations as conformant
History
AT&T, IBM, Lucent, and Motorola formed the VoiceXML Forum in March 1999, in order to develop a standard markup language for specifying voice dialogs. By September 1999 the Forum released VoiceXML 0.9 for member comment, and in March 2000 they published VoiceXML 1.0. Soon afterwards, the Forum turned over the control of the standard to the World Wide Web Consortium. The W3C produced several intermediate versions of VoiceXML 2.0, which reached the final "Recommendation" stage in March 2004.VoiceXML 2.1 added a relatively small set of additional features to VoiceXML 2.0, based on feedback from implementations of the 2.0 standard. It is backward compatible with VoiceXML 2.0 and reached W3C Recommendation status in June 2007
Related standards
The W3C's Speech Interface Framework also defines these other standards closely associated with VoiceXML
SRGS and SISR
The Speech Recognition Grammar Specification (SRGS) is used to tell the speech recognizer what sentence patterns it should expect to hear: these patterns are called grammars. Once the speech recognizer determines the most likely sentence it heard, it needs to extract the semantic meaning from that sentence and return it to the VoiceXML interpreter. This semantic interpretation is specified via the Semantic Interpretation for Speech Recognition (SISR) standard. SISR is used inside SRGS to specify the semantic results associated with the grammars, i.e., the set of ECMAScript assignments that create the semantic structure returned by the speech recognizer.SSML
The Speech Synthesis Markup Language (SSML) is used to decorate textual prompts with information on how best to render them in synthetic speech, for example which speech synthesizer voice to use, when to speak louder or softer.PLS
The Pronunciation Lexicon Specification (PLS) is used to define how words are pronounced. The generated pronunciation information is meant to be used by both speech recognizers and speech synthesizers in voice browsing applications.CCXML
The Call Control eXtensible Markup Language (CCXML) is a complementary W3C standard. A CCXML interpreter is used on some VoiceXML platforms to handle the initial call setup between the caller and the voice browser, and to provide telephony services like call transfer and disconnect to the voice browser. CCXML can also be used in non-VoiceXML contexts such as teleconferencing.MSML, MSCML, MediaCTRL
In media server applications, it is often necessary for several call legs to interact with each other, for example in a multi-party conference. Some deficiencies were identified in VoiceXML for this application and so companies designed specific scripting languages to deal with this environment. The Media Server Markup Language was Convedia's solution, and Media Server Control Markup Language was Snowshore's. These languages also contain 'hooks' so that external scripts (like VoiceXML) can run on call legs where IVR functionality is required.There is an IETF working group called mediactrl ("media control") that is working on a successor for these scripting systems, which it is hoped will progress to an open and widely adopted standard.
VoiceXML is the HTML of the voice web, the open standard markup language for voice applications. VoiceXML harnesses the massive web infrastructure developed for HTML to make it easy to create and deploy voice applications. Like HTML, VoiceXML has opened up huge business opportunities: the Economist even says that "VoiceXML could yet rescue telecoms carriers from their folly in stringing so much optical fibre around the world."
VoiceXML 1.0 was published by the VoiceXML Forum, a consortium of over 500 companies, in March 2000. The Forum then gave control of the standard to the World Wide Web Consortium (W3C), and now concentrates on conformance, education, and marketing. The W3C has just published VoiceXML 2.0 as a Candidate Recommendation. Products based on VoiceXML 2.0 are already widely available.
While HTML assumes a graphical web browser with display, keyboard, and mouse, VoiceXML assumes a voice browser with audio output, audio input, and keypad input. Audio input is handled by the voice browser's speech recognizer. Audio output consists both of recordings and speech synthesized by the voice browser's text-to-speech system.
A voice browser typically runs on a specialized voice gateway node that is connected both to the Internet and to the public switched telephone network (see Figure 1). The voice gateway can support hundreds or thousands of simultaneous callers, and be accessed by any one of the world's estimated 1,500,000,000 phones, from antique black candlestick phones up to the very latest mobiles.
VoiceXML takes advantage of several trends:- The growth of the World-Wide Web and of its capabilities.
- Improvements in computer-based speech recognition and text-to-speech synthesis.
- The spread of the WWW beyond the desktop computer.
What sorts of voice applications are best suited for VoiceXML? Here are a few ideas.
Information retrieval (IR) is a good match for VoiceXML. In an IR application, audio output tends to be pre-recorded information. Voice input can be highly constrained (e.g., a few browsing commands and limited data entry), or it can be quite rich (e.g., arbitrary street addresses). A good example of an IR application is one where the user first designs a personal voice newsletter at a web site, and then calls in periodically to browser through the newsletter. The newsletter may contain news, sports, traffic, weather, and stock information, as well as more specialized information such as intranet-based company news. This service can be funded by subscription, advertisement, or connect time.
Directory assistance applications work well in VoiceXML. AT&T's has a new VoiceXML toll-free directory assistance service, powered by TellMe, which you can try out in the United States by calling 800.555.1212. It is so incredibly effective that the automation rate climbed from 8% to 55%, saving AT&T $20 million a year. Remarkably, customer satisfaction has risen by over a third along with this increased automation.
Electronic commerce is another area. Customer service applications such as package tracking, account status, and support are well suited to VoiceXML. Financial applications like banking, stock quotes, and portfolio management are another good match. Catalog applications have to be done right, because voice conveys much less information than graphics. Catalog applications work if the customer is looking at a printed catalog (e.g., clothing), or knows the exact product already (e.g., a book, CD, or DVD title).
Telephone services like personal voice dialing, one-number "find-me" services, voice mail management, and teleconferencing can easily be voice-enabled through VoiceXML. Personal voice applications attached to individual phone lines can be very important sources of revenue.
Because standard Web security features apply to the voice web, intranet applications can also be written in VoiceXML for inventory control, ordering supplies, providing human resource services, and for corporate portals.
Unified messaging applications can leverage voice. E-mail messages can be read over the phone, outgoing e-mail can be recorded (and in the future transcribed) over the phone, and voice-oriented address information can be synchronized with personal organizers and e-mail systems. Pager messages can be originated from the phone, or routed to the phone.
There are many other areas where voice services can be used, such as checking the status of bids at an electronic auction site, authorizing bill payments, scheduling pickups of charitable donations, ordering a wake up call at a hotel. Doubtless there are many services not yet conceived of.
Conclusion
Before making a decision on voice access for your wireless application, take the time to visit a voice portal such as TellMe or BeVocal. While much of the wireless world is spending time trying to figure out how to deliver advertising as well as content to mobile devices, these voice portals are successfully doing both of these things now...with location-based services thrown in for good measure! Having said that, unlike the wired world, it is becoming increasingly clear that wireless application delivery will require support for a wide variety of devices and access technologies which will include voice access via VoiceXML to your applications. Get prepared today by studying up at the resources listed below!Apache Ant
 | |
|---|---|
| Developer(s) | Apache Software Foundation |
| Stable release | 1.8.1 / May 7, 2010 |
| Written in | Java |
| Operating system | Cross-platform |
| Type | Build Tool |
| License | Apache License 2.0 |
| Website | http://ant.apache.org |
The most immediately noticeable difference between Ant and Make is that Ant uses XML to describe the build process and its dependencies, whereas Make uses Makefile format. By default the XML file is named
build.xml.Ant is an Apache project. It is open source software, and is released under the Apache Software License.
History
Ant ("Another Neat Tool") was conceived by James Duncan Davidson while turning a product from Sun into open source. That product, Sun's reference JSP/Servlet engine, later became Apache Tomcat. A proprietary version of make was used to build it on the Solaris Operating Environment, but in the open source world there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple platform-independent tool to build Tomcat from directives in an XML "build file". From this humble beginning, the tool has gone on to become more widespread than the Tomcat product for which it was created. Ant (version 1.1) was officially released as a stand-alone product on July 19, 2000.Several proposals for an Ant version 2 have been made, such as AntEater by James Duncan Davidson, Myrmidon by Peter Donald and Mutant by Conor MacNeill, none of which were able to find large acceptance with the developer community.
Today, Ant is the build tool used by most Java development projects. For example, most open source developers include build.xml files with their distribution.[citation needed]
Because Ant made it trivial[citation needed] to integrate JUnit tests with the build process, Ant has made it easy for willing developers to adopt test-driven development, and even Extreme Programming.
Other Java-based build tools include Maven and JavaMake.
Sample build.xml file
Below is listed a sample build.xml file for a simple Java "Hello, world" application. It defines four targets - clean, clobber, compile and jar, each of which has an associated description. The jar target lists the compile target as a dependency. This tells Ant that before it can start the jar target it must first complete the compile target.<?xml version="1.0"?> <project name="Hello" default="compile"> <target name="clean" description="remove intermediate files"> <delete dir="classes"/> </target> <target name="clobber" depends="clean" description="remove all artifact files"> <delete file="hello.jar"/> </target> <target name="compile" description="compile the Java source code to class files"> <mkdir dir="classes"/> <javac srcdir="." destdir="classes"/> </target> <target name="jar" depends="compile" description="create a Jar file for the application"> <jar destfile="hello.jar"> <fileset dir="classes" includes="**/*.class"/> <manifest> <attribute name="Main-Class" value="HelloProgram"/> </manifest> </jar> </target> </project>
Another task used in this example is named jar:
<jar destfile="hello.jar">
Many Ant tasks delegate their work to external programs, either native or Java. They use Ant's own <exec> and <java> tasks to set up the command lines, and handle all the details of mapping from information in the build file to the program's arguments -and interpreting the return value. Users can see which tasks do this (e.g. <cvs>, <signjar>, <chmod>, <rpm>), by trying to execute the task on a system without the underlying program on the path, or without a full Java Development Kit (JDK) installed.
Extensions
WOProject-Ant is just one of many examples of a task extension written for Ant. These extensions are put to use by copying their jar files into ant's lib directory. Once this is done, these extension tasks can be invoked directly in the typical build.xml file. The WOProject extensions allow WebObjects developers to use ant in building their frameworks and applications, instead of using Apple's Xcode suite.Antcontrib provides a collection of tasks such as conditional statements and operations on properties as well as other useful tasks.
Other task extensions exist for Perforce, .Net, EJB, and filesystem manipulations, just to name a few.
Portability
One of the primary aims of Ant was to solve make's portability problems. In a Makefile the actions required to create a target are specified as shell commands which are specific to the current platform, usually a Unix shell. Ant solves this problem by providing a large amount of built-in functionality which it can then guarantee will behave (nearly) identically on all platforms.For example, in the sample
build.xml file above the clean target deletes the classes directory and everything in it. In a Makefile this would typically be done with the command:rm -rf classes/
rm is a Unix specific command which will probably not be available if the Makefile is used in a non-Unix environment such as Microsoft Windows which would use:rmdir /S /Q classesIn an Ant build file the same thing would be accomplished using a built in command:
<delete dir="classes"/>
Limitations
- Ant build files are written in XML. For unfamiliar users, both XML itself and the complex structure (hierarchical, partly ordered, and pervasively cross-linked) of Ant documents can be a barrier to learning. A GUI called Antidote was available for a time, but never gained a following and has been retired from the Apache project. Moreover, the language of Ant is quite verbose, and the build files of large or complex projects become unmanageably large. Good design and modularization of build files can improve readability but not necessarily reduce size. Other build tools like Maven use more concise scripts at the expense of generality and flexibility.
- Many of the older tasks—the core ones that are used every day, such as <javac>, <exec> and <java>—use default values for options that are not consistent with more recent versions of the tasks. Changing those defaults would break existing Ant scripts.
- When expanding properties in a string or text element, undefined properties are not raised as an error, but left as an unexpanded reference (e.g. ${unassigned.property}).
- Ant has limited fault handling rules, and no persistence of state, so it cannot be used as a workflow tool for any workflow other than classic build and test processes.
- The Ant target model does not treat artifacts as targets. In most build tools a target is an artifact created by the build—a program, library, intermediate object file, PDF documentation, etc.—and rules specify the dependencies between targets and the tasks to run to build a target when it is out of date. In Ant a target is a group of tasks rather than an artifact. This means that Ant is sometimes unable to determine the relationship between an artifact and the task sequence to build the artifact and this logic must be implemented by the programmer using Ant's control structures.
- Once a global property is defined it cannot be changed by any of the core tasks. Antcontrib provides a variable task to workaround this problem. And AntXtras provides a variable property type that complements readonly properties.
- Lazy property evaluation is not supported. For instance, when working within a Antcontrib <for> loop, a property cannot be re-evaluated for a sub-value which may be part of the iteration. (Again you can workaround this depending on the third-party extension you're using; AntXtras flow-control tasksets do provide for cursor redefinition for loops.)
- Reuse of build file fragments is hard. Ant 1.6 made reuse easier, with features like
<import>,<presetdef>, and<macrodef>; however, some might argue these new features create an even steeper learning curve for new Ant users.
- In makefiles, any rule to create one file type from another file type can be written inline within the makefile. For example, you may transform a document into some other format by using rules to execute another tool. Creating a similar task in Ant is more complex: a separate task must be written in Java and included with the Ant build file in order to handle the same type of functionality. However, this separation can enhance the readability of the Ant script by hiding some of the details of how a task is executed on different platforms.
No comments:
Post a Comment