Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20030046316
Kind Code
A1
Gergic, Jaroslav ; et al.
March 6, 2003
Systems and methods for providing conversational computing via javaserver pages and javabeans
Abstract
A new application programming language is provided which is based on user interaction with any device which a user is employing to access any type of information. The new language is referred to herein as a "Conversational Markup Language (CML). In a preferred embodiment, CML is a high level XML based language for representing "dialogs" or "conversations" the user will have with any given computing device. For example, interaction may comprise, but is not limited to, visual based (text and graphical) user interaction and speech based user interaction. Such a language allows application authors to program applications using interaction-based elements referred to herein as "conversational gestures." The present invention also provides for various embodiments of a multimodal browser capable of supporting the features of CML in accordance with various modality specific representations, e.g., HTML based graphical user interface (GUI) browser, VoiceXML based speech browser, etc.
Inventors:
Gergic; Jaroslav
(Kocbere, CZ)
, Kleindienst; Jan
(Kladno-Krochehlavy, CZ
)
, Maes; Stephane H.
(Danbury, CT
)
, Raman; Thiruvilwamalai V.
(San Jose, CA
)
, Sedivy; Jan
(Praha, CZ
)
Correspondence Name and Address:
F. CHAU & ASSOCIATES, LLP 1900 Hempstead Turnpike, Suite 501
Frank Chau
East Meadow
NY
11554
US
Series Code:
837024
Filed:
April 18, 2001
U.S. Current Class:
707/513
U.S. Class at Publication:
707/513
Intern'l Class:
G06F 017/24;
G06F 017/21; G06F 017/00; G06F 009/46; G06F 015/00
Claims
What is claimed is:
1. A method of programming an application accessible by a user through one or more computer-based devices, the method comprising the steps of: representing interactions that the user is permitted to have with the one or more computer-based devices used to access the application by interaction-based programming components; wherein the interaction-based programming components are independent of content/application logic and presentation requirements associated with the application, and further wherein the interaction-based programming components are transcoded on a component by component basis to generate one or more modality-specific renderings of the application on the one or more computer-based devices.
2. The method of claim 1, in a client/server arrangement wherein at least a portion of the application is to be downloaded from a server to at least one of the one or more computer-based devices, acting as a client, further comprising the step of including code in the application operative to provide a connection to the content/application logic resident at the server.
3. The method of claim 2, wherein the content/application logic connection code expresses at least one of one or more data models, atrribute constraints and validation rules associated with the application.
4. The method of claim 1, wherein the one or more modality-specific renderings comprise a speech-based representation of portions of the application.
5. The method of claim 4, wherein the speech-based representation is based on VoiceXML.
6. The method of claim 1, wherein the one or more modality-specific renderings comprise a visual-based representation of portions of the application.
7. The method of claim 6, wherein the visual-based representation is based on at least one of HTML, CHTML and WML.
8. The method of claim 1, wherein the user interactions are declaratively represented by the interaction-based programming components.
9. The method of claim 1, wherein the user interactions are imperatively represented by the interaction-based programming components.
10. The method of claim 1, wherein the user interactions are declaratively and imperatively represented by the interaction-based programming components.
11. The method of claim 1, wherein the interaction-based programming components comprise basic elements associated with a dialog that may occur between the user and the one or more computer-based devices.
12. The method of claim 11, wherein the interaction-based programming components comprise complex elements, the complex elements being aggregations of two or more of the basic elements associated with the dialog that may occur between the user and the one or more computer-based devices.
13. The method of claim 1, wherein one of the interaction-based programming components represent conversational gestures.
14. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating informational messages to the user.
15. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating contextual help information.
16. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating actions to be taken upon successful completion of another gesture.
17. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating yes or no based questions.
18. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating dialogues where the user is expected to select from a set of choices.
19. The method of claim 18, wherein the select gesture comprises a subelement that represents the set of choices.
20. The method of claim 18, wherein the select gesture comprises a subelement that represents a test that the selection should pass.
21. The method of claim 20, wherein the select gesture comprises a subelement that represents an error message to be presented if the test fails.
22. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating rules for validating results of a given conversational gesture.
23. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating grammar processing rules.
24. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating dialogues that help the user navigate through portions of the application.
25. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating a request for at least one of user login and authentication information.
26. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating a request for constrained user input.
27. The method of claim 13, wherein the conversational gestures comprise a gesture for encapsulating a request for unconstrained user input.
28. The method of claim 13, wherein the conversational gestures comprise a gesture for controlling submission of information.
29. The method of claim 1, further comprising the step of providing a mechanism for defining logical input events and the association between the logical input events and physical input events that trigger the defined logical input events.
30. The method of claim 1, wherein the component by component transcoding is performed in accordance with XSL transformation rules.
31. The method of claim 1, wherein the component by component transcoding is performed in accordance with Java Bean.
32. The method of claim 1, wherein the component by component transcoding is performed in accordance with Java Server Pages.
33. The method of claim 1, wherein representation by the interaction-based programming components permits synchronization of the one or more modality-specific renderings of the application on the one or more computer-based devices.
34. The method of claim 1, wherein representation by the the interaction-based programming components supports a natural language understanding environment.
35. The method of claim 1, further comprising the step of including code for permitting cosmetic altering of a presentational feature associated with the one or more modality-specific renderings of the application on the one or more computer-based devices.
36. The method of claim 1, further comprising the step of including code for permitting, changes to riles for transcoding, on a component by component basis to generate the one or more modality-specific renderings of the application on the one or more computer-based devices.
37. The method of claim 1, wherein a definition of an underlying data model being, populated is separated from a markup language defining the user interaction.
38. The method of claim 1, wherein a node_id attribute is attached to each component and the attribute is mapped over to various outputs.
39. The method of claim 1, wherein an author is provided with a pass through mechanism to encapsulate modality-specific markup components.
40. The method of claim 1, wherein the components may be active in parallel.
41. The method of claim 1, wherein the representation and transcoding is extensible.
42. The method of claim 1, wherein a state of the application is encapsulated.
43. The method of claim 1, wherein the representation permits reference to dynamically generated data and supports callback mechanisms to the content/application logic.
44. Apparatus for use in accessing an application in association with one or more computer-based devices, the apparatus comprising: one or more processors operative to: (i) obtain the application from an application server, the application being programmatically represented by interactions that the user is permitted to have with the one or more computer-based devices by interaction-based programming components, wherein the interaction-based programming components are independent of content/application logic and presentation requirements associated with the application; and (ii) transcode the interaction-based programming components on a component by component basis to generate one or more modality-specific renderings of the application on the one or more computer-based devices.
45. The apparatus of claim 44, wherein the one or more processors are distributed over the one or more computer-based devices.
46. The apparatus of claim 44, in a client/server arrangement wherein at least a portion of the application is to be downloaded from a server to at least one of the one or more computer-based devices, acting as a client, further comprising the step of including code in the application operative to provide a connection to the content/application logic resident at the server.
47. The apparatus of claim 46, wherein the content/application logic connection code expresses at least one of one or more data models, atrribute constraints and validation rules associated with the application.
48. The apparatus of claim 44, wherein the one or more modality-specific renderings comprise a speech-based representation of portions of the application.
49. The apparatus of claim 48, wherein the speech-based representation is based on VoiceXML.
50. The apparatus of claim 44, wherein the one or more modality-specific renderings comprise a visual-based representation of portions of the application.
51. The apparatus of claim 50, wherein the visual-based representation is based on at least one of HTML, CHTML and WML.
52. The apparatus of claim 44, wherein the user interactions are declaratively represented by the interaction-based programming components.
53. The apparatus of claim 44, wherein the user interactions are imperatively represented by the interaction-based programming components.
54. The apparatus of claim 44, wherein the user interactions are declaratively and imperatively represented by the interaction-based programming components.
55. The apparatus of claim 44, wherein the interaction-based programming components comprise basic elements associated with a dialog that may occur between the user and the one or more computer-based devices.
56. The apparatus of claim 55, wherein the interaction-based programming components comprise complex elements, the complex elements being aggregations of two or more of the basic elements associated with the dialog that may occur between the user and the one or more computer-based devices.
57. The apparatus of claim 44, wherein one of the interaction-based programming components represent conversational gestures.
58. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating informational messages to the user.
59. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating contextual help information.
60. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating actions to be taken upon successful completion of another gesture.
61. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating yes or no based questions.
62. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating dialogues where the user is expected to select from a set of choices.
63. The apparatus of claim 62, wherein the select gesture comprises a subelement that represents the set of choices.
64. The apparatus of claim 62, wherein the select gesture comprises a subelement that represents a test that the selection should pass.
65. The apparatus of claim 64, wherein the select gesture comprises a subelement that represents an error message to be presented if the test fails.
66. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating rules for validating results of a given conversational gesture.
67. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating grammar processing rules.
68. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating dialogues that help the user navigate through portions of the application.
69. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating a request for at least one of user login and authentication information.
70. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating a request for constrained user input.
71. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for encapsulating a request for unconstrained user input.
72. The apparatus of claim 57, wherein the conversational gestures comprise a gesture for controlling submission of information.
73. The apparatus of claim 44, further comprising the step of providing a mechanism for defining logical input events and the association between the logical input events and physical input events that trigger the defined logical input events.
74. The apparatus of claim 44, wherein the component by component transcoding is performed in accordance with XSL transformation rules.
75. The apparatus of claim 44, wherein the component by component transcoding is performed in accordance with Java Bean.
76. The apparatus of claim 44, wherein the component by component transcoding is performed in accordance with Java Server Pages.
77. The apparatus of claim 44, wherein representation by the interaction-based programming components permits synchronization of the one or more modality-specific renderings of the application on the one or more computer-based devices.
78. The apparatus of claim 44, wherein representation by the the interaction-based programming components supports a natural language understanding environment.
79. The apparatus of claim 44, further comprising the step of including code for permitting cosmetic altering of a presentational feature associated with the one or more modality-specific renderings of the application on the one or more computer-based devices.
80. The apparatus of claim 44, further comprising the step of including code for permitting changes to rules for transcoding on a component by component basis to generate the one or more modality-specific renderings of the application on the one or more computer-based devices.
81. The apparatus of claim 44, wherein a definition of an underlying data model being populated is separated from a markup language defining the user interaction.
82. The apparatus of claim 44, wherein a node_id attribute is attached to each component and the attribute is mapped over to various outputs.
83. The apparatus of claim 44, wherein an author is provided with a pass through mechanism to encapsulate modality-specific markup components.
84. The apparatus of claim 44, wherein the components may be active in parallel.
85. The apparatus of claim 44, wherein the representation and transcoding is extensible.
86. The apparatus of claim 44, wherein a state of the application is encapsulated.
87. The apparatus of claim 44, wherein the representation permits reference to dynamically generated data and supports callback mechanisms to the content/application logic.
88. The apparatus of claim 44, wherein the one or more processors are distributed over the one or more computer-based devices and the application is synchronized across the one or more computer-based devices.
89. The apparatus of claim 44, wherein the representation of the application further permits cosmetization of the one or more modality-specific renderings via one or more modality-specific markup languages.
90. A browser apparatus for use in providing access to an application by a user through one or more computer-based devices, comprising a machine readable medium containing computer executable code which when executed permits the implementation of the steps of: obtaining the application from an application server, the application being programmatically represented by interactions that the user is permitted to have with the one or more computer-based devices by interaction-based programming components, wherein the interaction-based programming components are independent of content/application logic and presentation requirements associated with the application; and transcoding the interaction-based programming components on a component by component basis to generate one or more modality-specific renderings of the application on the one or more computer-based devices.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority to the U.S. provisional patent application identified by Ser. No. 60/158,777 filed on Oct. 12, 1999, the disclosure of which is incorporated by reference herein. The present application is related to (i) PCT international patent application identified as US99/23008 (attorney docket no. Y0998-392) filed on Oct. 1, 1999; (ii) PCT international patent application identified as US99/22927 (attorney docket no. YO999-111) filed on Oct. 1, 1999; (iii) PCT international patent application identified as US99/22925
(attorney docket no. YO999-1 13) filed on Oct. 1, 1999, each of the above PCT international patent applications claiming priority to U.S. provisional patent application identified as U.S. Ser. No. 60/102,957
filed on Oct. 2, 1998 and U.S. provisional patent application identified as U.S. Ser. No. 60/117,595 filed on Jan. 27, 1999; and (iv) U.S. patent application identified as U.S. Ser. No. 09/507,526 (attorney docket no. YO999-178) filed on Feb. 18, 2000 which claims priority to U.S. provisional patent application identified as U.S. Ser. No. 60/128,081
filed on Apr. 7, 1999 and U.S. provisional patent application identified by Ser. No. 60/158,777 filed on Oct. 12, 1999. The disclosures of all of the above-referenced related applications are incorporated by reference herein.
FIELD OF THE INVENTION
[0002] The present invention generally relates to information access applications and, more particularly, to an interaction-based markup language and multi-modal browsing mechanisms supporting the interaction-based markup language for use with such information access applications.
BACKGROUND OF THE INVENTION
[0003] Given the dramatic increase in the availability of various types and quantities of information and a sharp decrease in time and/or availability of traditional facilities to access such information, individuals currently desire to be able to access, act on, and/or transform any information from any device at any time. In the case of the Internet, for instance, large quantities and varieties of information are available, however, traditionally the Internet was mostly supporting only devices that access information using a HyperText Markup Language (HTML) browser on top of a HyperText Transport Protocol (HTTP) network. This was provided on top of TCP/IP (Transmission Control Protocol/Internet Protocol).
[0004] Solutions to this problem centered around rewriting application programs used to access such information so that the information could be accessed in other ways. One solution led to the development of the Wireless Application Protocol (WAP), see, http://www.mobilewap.com. WAP is equivalent to HTTP for a wireless network. A Wireless Markup Language (WML) was developed which is equivalent to HTML for a wireless network. Thus, similar to how HTML is used on top of HTTP. WML is used on top of WAP. WAP and WML allow a user to access the Internet over a cellular phone with constrained screen rendering and limited bandwidth connection capabilities. CHTML is another example of a ML (markup language) addressing this space.
[0005] Next, more recently came the development of a mechanism for bringing the Web programming model (also known as fat client programming model) to voice access and, in particular, to telephone access and Interactive Voice Response (IVR) systems. Such a mechanism is typically known as a speech browser (or voice browser). Such a speech browser is described in the above-referenced U.S. provisional patent application identified as U.S. Ser. No. 60/102,957 (attorney docket no. YO998-382). The speech browser may use a speech based variation of the Extensible Markup Language (XML) known as VoiceXML, see, e.g., http://www.voicexml.org. The speech browser can also operate on top of the WAP protocol and in conjunction with exchanges of WML data.
[0006] However, such an approach poses certain problems for application programmers, if they want to offer multi-channel support: offer access to web browsers (HTML browsers), phones (voice browsers) and wireless browser (WML) or multi-modal/conversational browsers, as defined in the aforementioned disclosures. First, with this approach, the application programmer must deal with at least three different languages when developing an application, e.g., HTML, WML and VoiceXML. That is, the application must account for the fact that since a user is going to be accessing Internet based information via a speech browser over a conventional telephone, or over a wireless connection using a WAP browser or using a conventional web browser, HTML, WAP and VoiceXML must be employed when writing the application. This is known to be quite burdensome to the application developer. Secondly, with this approach, there is no suitable way to synchronize multi-modal applications, for example, applications that provide for both visual and speech based user interaction with the browser or browsers employed to access the application.
[0007] Applications have traditionally been developed such that both content (i.e., information or other data) and presentation (i.e., manner in which the content is presented to the user) were mixed. However, in an attempt to simplify application programming, an effort was made to separate content from presentation. This led to the development of the Extensible Stylesheet Language (XSL) which operates in conjunction with XML such that content associated with an application is stored in XML and the transformations necessary to present the content on a specific device are handled by XSL, see, http://www.w3.org/Style/XSL. Such approach has been adopted by the W3C (World Wide Web Consortium). This approach is typically used to adapt the presentation to the characteristics of the main browsers (e.g., different versions of Microsoft Internet Explorer, Netscape Conununicator/Navigator, other less popular browsers, etc.). Some have tried to extend this use to other modalities/channels (e.g., wireless browser supporting a format like WML on top of embedded devices (wireless phone or PDA)). This last approach has never been very successful or convenient and in any case it requires multiple authoring of the XSL pages. However, this approach has the disadvantage of being both application and device/channel dependent. That is, XSL rules are dependent on the application and device for which the content is to be transcribed. Thus, if an application is to be accessed from a new device, new XSL transformations must be written for that device.
[0008] Other attempts to overcome some of these problems have been made. There have been attempts to provide an XML model based on user intention (complex and generally task oriented intentions). User intentions may be modeled with complex components that can not, or are very difficult to be, rendered on devices with small screens or with speech. These complex components, not decomposed into smaller atomic components, can also not be tightly synchronized across modalities. Tags independent of the device are offered which are rendered by different browsers. Also, some extensions to speech interactive voice response (IVR) systems have been proposed. However, among other deficiencies, these attempts do not model dialog and transcoding from modality to modality is generally an impossible task.
[0009] In these approaches, user intentions are modeled with complex components that describe complex interactions. However, they are typically application-specific. That is, they depend, characterize, or directly involve business logic concepts and elements. Therefore, in that case, the same way that XSL rules (and XSL style sheets) are today fundamentally a function of the application or application domain (i.e., the nature of the XML attribute involved), the XSL rules used to transform pages written with theses languages are also fundamentally a function of the application or application domain. They must be re-written for each new application. This characterizes the limitation of these approaches. These approaches do not contribute in helping to offer access to content, independent of the access modality. Indeed, these approaches only allow access to content related to this application or application domain. Any other case requires rewriting the transformation rules. Thus, there is a need to free transformation rules from the backend application and to make it depend only on characteristics/modalit- ies supported by the access device or channel.
[0010] Note that in some cases, support of multiple channels has been achieved by using cascades of stylesheets and treating the resulting XML stream as serialized internal APIs (Application Programming Interfaces). Again, this requires multiple authoring.
[0011] In addition, the above approaches result in having very complex intention models with such components that do not have corresponding rendering appropriate in modalities like WML. It is apparent that these models were designed to offer the capability to customize the graphical user interface (GUI) presentation to requirements of different types of display (i.e., essentially within variations of the same channel and modality) or browsers. As a result, none of these approaches appropriately model and treat speech or multi-modal user interfaces.
[0012] As already mentioned, conventional transcoding (XSL rules used to present the XML content and change of XSL style sheet to go from one modality to another) has been considered to support different access modalities. This means that for a given XML content, by changing the XML rules, the system can produce an HTML page, an WML rule, or even a VoiceXML page, etc. Actually, this is what is being used today to support the different web browsers on the market, e.g., Netscape Communicator, Microsoft Internet Explorer, Sun Microsystems Hot Java, Spyglass browser, Open Source Amaya browser/editor, etc. Unfortunately, this is possible only if:
[0013] (i) The XSL rules are application or application domain specific (i.e., the nature of the XML attribute); and
[0014] (ii) Transcoding is between two languages, for example HTML to WML, and the original content has been built in HTML while following very strict rules of authoring. Indeed, this is enforceable only if within a given company, for a given web site. Even in those cases, it is hardly implementable, in general, because of missing information across markup languages or modalities in order to provide the corresponding components in other modalities (e.g., an HTML form or menu does not provide the information required to render it automatically by voice) as well as different dialog navigation flows in different modalities.
[0015] Accordingly, there is a need for an application programming language and information browsing mechanisms associated therewith which overcome these and other shortcomings attributed to existing languages and browsers.
SUMMARY OF THE INVENTION
[0016] The present invention provides for a new application programming language which is based on user interaction with any device which the user is employing to access any type of information. The new language is referred to herein as a "Conversational Markup Language (CML).
[0017] In a preferred embodiment, CML is a high level XML based language for representing "dialogs" or "conversations" the user will have with any given computing device. While the terms dialog and conversation are used herein, it is to be appreciated that they more generally refer to a users interaction with a device (e.g., a local device, a remote device (e.g., interaction over the telephone), or any otherwise distributed device), independent of the modality and the device. Thus, interaction may comprise, but is not limited to, visual based (text and graphical) user interaction and speech based user interaction and combinations of them.
[0018] Such a language allows application authors to program applications using interaction-based elements referred to herein as "conversational gestures." Conversational gestures are elementary programming components or elements of CML that characterize any dialog, independent of the modalities, the devices, or the browsers employed to access information associated with an application programmed in accordance therewith.
[0019] The invention accomplishes these and other features and advantages by defining a new application programming paradigm. As mentioned above, existing application authoring approaches have adopted the concept of separating the content based aspects of an application from the presentation based aspects. In accordance with the present invention, CML introduces a new paradigm which provides for separating application programming into content aspects, presentation aspects and interaction aspects. By focusing on the interaction aspect of an application with respect to a user, an application may be written in a manner which is independent of the content/application logic and presentation. It is to be appreciated that the content and/or the business logic of an application is also referred to as the "back-end logic" associated with the application.
[0020] In a client/server arrangement, the "back-end logic" is the portion of an application that contains the logic, i.e., encoded set of states and conditions that drive the evolution of an application, as well as variable validation information. As will be explained, attribute constraint and validation information can be added to a CML page to carry logic information separated from the back-end data. Thus, as will be explained and illustrated below, after an application is created in CML, a portion of the CML code associated with the application is downloaded to a client device or devices from a server and the CML gestures of the CML code are then transcoded to the browser-specific markup languages employed at the device or devices, e.g., HTML and/or VoiceXML.
[0021] In accordance with the invention, a device (client or even server serving CML pages into possibly other legacy markup languages like HTML, VoiceXML, WML etc.) operating with downloaded CML code can transcode to, for example, HTML and VoiceXML, substantially simultaneously so as to synchronize the multiple browsers providing the user with access to information. Such advantageous synchronization according to the invention is possible because the transcoding is done gesture by gesture with gesture identification. Thus, when an input/output event occurs in one modality, the browser knows what event occurred for what gesture and can immediately update all the supported modalities. This results in a very tight synchronization across modalities. Such synchronization is also achieved due to the fact that the various modality-specific user interface dialogues, e.g., associated with a graphical user interface (GUT) browser or a speech browser, are generated from a single CML representation, on a gesture by gesture basis. Thus, the multiple user interfaces, e.g., GUI, speech, etc., are synchronized and continuously updated as a user interactively proceeds with one or the other modality.
[0022] CML and the browsing mechanisms of the present invention also provide a platform for natural language (NL) programming. Since CML allows an application author to program gesture by gesture, such an application provides the flexibility for a user to provide requests/responses in a wide range of natural conversational manners. Thus, the user is not restricted to simple commands bust rather can interact with an application in a less restrictive manner, e.g., more closely resembling a natural conversation. With NL and the invention, the user can express himself freely in multiple modalities, with no constraint other than to carry a natural conversation as if it was carried with another human being. In the case of NL, in addition, the system may use context and past interaction/dialog history (as well as other meta-information like user preferences, application settings, stored common knowledge, etc.) to disambiguate queries.
[0023] NL is a statement which is not limited to speech but encompasses all aspects of a natural multi-modal conversational application. It combines NL inputs with natural multi-modal input. As described in the above-referenced patent application identified by attorney docket no. YO999-111: any input is modeled independently of the modality as an input/output event that is then processed by a dialog manager and arbitrator that will use history, dialog context and other meta-information (e.g., user preference, information about the device and application) to determine the target of the input event and/or engage a dialog with the user to complete, confirm, correct or disambiguate he intention of the user prior to executing the requested action.
[0024] It is also to be appreciated that the present invention provides for a multi-device or distributed browsing environment. Due to the nature of CML and its ability to the effectively synchronize multiple browsers, various portions of an application may reside and be executed on separate computing devices. A user may then simultaneously interact with more than one device, e.g., a laptop computer and a cellular phone, when accessing an application. This is referred to as "multi-device browsing." Actually, this aspect of the invention does not require "multi-modality." That is, even with only GUI/HTML browsers, the gesture-based XSL rules can be used to define what is rendered on what browser. Accordingly, some content can be displayed on a personal digital assistant or PDA (i.e, color images, streamed video, long lists), while the rest is displayed on the cell phone screen, etc.
[0025] Given the modality-independence of CML, even after an application is written, any transcoding rules associated with any type of browser may be implemented. That is, CML allows the author to change to another type of transcoding (i.e., the gesture based transcoding rules), other than any default transcoding that may have originally been implemented. Thus, through simple updates of gesture based XSL rules, this feature advantageously guarantees support for new releases/versions of the so-called "legacy languages," e.g., HTML, XML, VoiceXML, etc., and for new languages, e.g., CHTML, HDML, etc. In addition, this feature permits a simple and easy passage from one version of CML to a new one using simple gesture based XSL rules. It is to be appreciated that gesture by gesture transcoding from version to version is not a different problem from transcoding from CML to other legacy language. This is especially advantageous as CML is designed, by definition, around the principle of this transcoding. This is certainly not true for most of the other mark-up languages where upgrades of the specifications, while possibly offering backward compatibilities, are usually problematic for new generation browsers, as well as in with respect to all the older content written in older versions.
[0026] CML also permits cosmetic altering of a presentation even after a CML page is written. For example, depending on the desired modality and target markup language, a CML command may be issued to cosmetically alter some feature of the presentation of content, in some modalities. This allows CML developers to put the same amount of cosmetic efforts as they would put for optimal HTML rendering. But the advantage of course is that for the same price, they have obtained a multi-channel (i.e., able to be expressed in multiple type of target ML or device modalities or specific user interface characteristics) description of the interaction that can be used to provide universal access (independent of the access device or channel) and/or tightly synchronized multi-modal and conversational user interfaces.
[0027] The present invention also provides for various embodiments of a multi-modal browser capable of supporting the features of CML in accordance with various modality specific representations, e.g., HTML based graphical user interface (GUI) browser, VoiceXML based speech browser, etc.
[0028] It is to be noted that the term "CML" is used in the above-referenced patent applications identified by attorney docket nos. YO998-392 and YO999-178. In these applications, the term is meant to refer to a declarative way to describe conversational interfaces. In accordance with the present invention, the term CML refers to a gesture-based language which embodies the concept of programming by interaction, as will be explained in detail below.
[0029] Given such aspects of the present invention, as well as others that will be explained below, we now discuss some important differences between such inventive features and existing approaches. The exponential growth of the World Wide Web (WWW) during the last five years has pointed out the inherent strength in constructing light-weight user interface applications by first separating user interaction from content, and subsequently delivering application front-ends via markup languages like HTML that are rendered by a platform-independent WWW browser. This architecture opens up a new world of possibilities by liberating end-user applications from details of the underlying hardware and operating system. The current WWW architecture has liberated visual interfaces to e-commerce applications from details of the underlying hardware and operating system. The next step in this evolution is to make end-user applications independent of the interface modality and device used to interact with electronic information. This evolution is the natural next step in enabling speech-based interaction with the new generation of e-commerce applications.
[0030] To achieve end-user WWW services that are device and modality independent, there is a strong need to author such applications and services using modality independent technologies that enable delivery to a variety of devices. With XML fast becoming the next-generation lingua-franca of the WWW, it is natural to design such languages as XML applications.
[0031] Modality-independent WWW services can thus be achieved by designing an XML-based language for authoring information content and interaction logic that is modality independent, and then delivering the resulting application in a manner most appropriate to the target device. This naturally leads to the design of languages that separate information content, information presentation and interaction logic into distinct components. The WWW has already evolved towards separating out content from presentation by adopting style sheets; the next evolutionary step is to factor out interaction logic from information content. At present, external standards activities in this area are expected to emerge from industrial consortia such as the W3C within its XFORMS and voice browser working groups.
[0032] The separation outlined above leads to an approach we refer to as conversational computing: end-user applications and services are expressed as an aggregation of modality-independent conversational gestures, where each conversational gesture encodes an atomic piece of the man-machine dialogue making up the user interaction.
[0033] The insights outlined above are validated by the fact that there have been a few attempts at designing intention-based markup language in the recent past. They were initially designed to abstract variations in visual presentation amongst different devices e.g., small screen handhelds versus desktop PCs. As speech interfaces become relevant, both these languages are presented as a possible means for authoring end-user applications for delivery to speech devices, in addition to the different visual displays that were their original target.
[0034] CML, according to the present invention, is designed from the ground-up as an XML-based language for authoring modality-independent user interaction, with a special focus on the new requirements introduced by the need to address conversational interfaces comprising of speech and natural language technologies. This focus on speech as a first-class citizen in the user interface has caused CML to evolve in a manner distinct from previous attempts. We will contrasts some of these key differences.
[0035] (i) Overlays Interaction On Data Model
[0036] All prior art languages define the user intentions and the underlying data model that is populated by the user interaction within the same piece of markup. Here is a short example from a specification to illustrate this. The fragment of markup shown below would be used to obtain a person's title (Mr., Mrs., or Ms.). Notice that the definition of the datatype being prompted for is intermixed with the markup that produces the user interaction.
1
<prior art ML> <CHOICE NAME ="PersonTitles" SELECTION-POLICY="SINGLE"> <CAPTION>Title</CAPTION> <HINT>This is a set of valid titles for a person.</HINT> <STRING NAME="Mr"> <VALUE>Mr.</VALUE> </STRING> <STRING NAME="MRS"> <VALUE>Mrs.</VALUE> </STRING> <STRING NAME="MISS"> <VALUE>Miss</VALUE> </STRING> <STRING NAME="MS"> <VALUE>Ms</VALUE> </STRING> </CHOICE> </prior art ML>
[0037] Compare the above with the CML representation for obtaining the person's title shown below. Notice that we separate the definition of the datatype, i.e., the enumeration type that lists valid person titles, from the user interaction component, i.e., namely, the select gesture.
[0038] We first define the enumeration type PersonTitle:
<enum name="PersonTitle"type="string"><value>MR</value>&- lt;value>MRS</value><value>MISS</value></enum>
[0039] Once defined, field PersonTitle can be instantiated at multiple points in the user interaction via an appropriate CML gesture. Below we illustrate this with gesture select.
<select name="PersonTitle" selection-policy="single"><message>- Person Title</mesage><choices><choicevalue="MR">Mr.</- choice><choicevalue="MRS">MRS.</choice><choicevalue="MIS- S">Miss.</choice></choices></select>
[0040] Separating the conversational gesture (gesture select in the above example) from the definition of the underlying datatype (enumeration PersonTitle above) provides a number of advantages:
[0041] (1) By separating the conversational gesture from the data definition, we can author multiple user interfaces for prompting for the person title, e.g., when internationalizing the above dialogue. Thus, a German version of this dialogue constructed in CML would require only the conversational gesture to be modified. Notice that when the representation of the above is internationalized, i.e., what needs to change are the contents of elements caption, hint and code value, the definition of the underlying enumeration type remains the same. However, by overlaying the user interface markup on the data definition, this design fails to isolate the changes needed to internationalize the dialogue. Note that some of the previous languages work around this explicit problem of internationalization by introducing the notion of templates which then get re-used by the author for producing different language versions of the above dialogue. However, this does not eliminate the basic underlying problem, i.e., the data definition and user interface still remain linked in the template definition.
[0042] (2) Once field PersonTitle is defined, CML gestures can refer to this field at multiple points in the user interaction. Thus, once the user has specified a value for field PersonTitle, subsequent portions of the dialogue can refer to the supplied value when producing prompts e.g., Welcome to the electronic store Mr. Smith.
[0043] (3) Applications authored in CML are also free to prompt the user for a specific field such as PersonTitle at different points in the user interaction, with the user having the freedom to decide at which point he/she supplies a value for that field. This form of flexibility is especially vital in designing natural language interfaces, and is again a consequence of separating the markup that defines the model from the markup that declares the user interaction. Without this separation (as in the prior art at present), the above would force the author to define field PersonTitle multiple times.
[0044] To see the above, consider a mutual funds application that allows the user to buy and sell mutual funds as well as to find out the net value of a specific asset. In a simplified version of this interaction, the system needs to obtain two items of information from the user:
[0045] (a) User action, e.g., buy sell or net asset value;
[0046] (b) Asset to act on, e.g., fund to buy.
[0047] When using a natural language interface for the above example, the user is equally likely to specify either the action to perform, the asset to act on, or perhaps both when initially prompted by the system. Depending on what is specified, the dialogue now needs to transition to a state where the system prompts for the missing piece of information; alternatively, if both action and asset are specified, the system needs to produce a confirmation prompt of the form: "Would you like to action specified fund?"
[0048] Given that the prior art currently overlays the interaction markup, i.e., in this case, element CHOICE on the data definition, it becomes impossible for the application author to specify the user interaction for obtaining value the same field, e.g., asset at different points in the user interaction.
[0049] The overlay of interaction over data models especially emphasizes the novelty of our approach and new paradigm and programming model that we disclose herein.
[0050] (ii) Lack Of Explicit Environment For Encapsulating Application State
[0051] A further consequence of separating out the data model from the user interaction in CML is that applications authored as a CML document clearly present an environment that binds application state, e.g., PersonTitle or action in the examples cited above. In the case of the prior art, this application state is implicit and not readily available to other parts of the user interface encoded in the language.
[0052] By defining the data model and hence the application state explicitly, CML clearly defines the XML encoding that will be sent back to the server once user interaction is completed. Thus, in the case of field PersonTitle, the server would receive the following upon submission:
<PersonTitle>MR</PersonTitle>
[0053] The server, which has access to the definition of the data model, can validate the submitted value. In more complex examples, the data model definition can encapsulate application-specific validation constraints; these constraints can be checked both at the client-side, and later verified upon submission on the server end. This separation of the data model and constraints from the user interface enables CML applications that allow the user to commence an interaction using a particular interaction device, e.g., a desktop PC, submit a partially completed transaction, and later complete the transaction using a different device, e.g., a cellular telephone.
[0054] (iii) The prior art reflects GUI Legacy
[0055] Many of the core attributes defined in the prior art specification reflects GUI-specific legacy. For instance, all data types are qualified by core attributes shown, which makes sense only for display-based interfaces. There appears to be no unambiguous interpretation of settings such as enable=false, shown=true for non-visual devices such as speech-based handhelds and cellular telephones.
[0056] Moreover, these attributes make it hard to map representations of user interaction to small-sized displays; this is because an application authored in these ML for a desktop GUI is likely to declare that many of the interaction elements be shown, something that becomes difficult in environments where display real-estate is scarce.
[0057] The prior art usually has other GUI components that have no meaning outside large screens. Unfortunately, features that are pervasive in the language and not easily usable across modalities/channel are problematic: one can not guarantee that transcoding/rendering will be possible for any target.
[0058] In addition modalities like speech may require additional information in order to render the dialog components (e.g., grammar, vocabulary, language model, acoustic model, NL parsing and tagging data files, etc.). This information is not available in the prior art widgets. Again, the overlay between data model and interaction leads to problems when the same dialog component needs to be used multiple times in the page with different data files.
[0059] (iv) Lack Of Atomic Conversational Gestures
[0060] Because prior art representations of user interaction are overlaid directly on the underlying data model that is being populated, there is no notion of a set of atomic conversational gestures in these MLs as in CML; rather, explicit CML gestures such as select are implicit in the prior art design. For example, CML gesture select would appear in prior art as a result of overlaying the markup for a choice element on the markup for a list structure, see the example of field PersonTitle cited above.
[0061] Lack of atomic conversational gestures first becomes a problem when constructing more complex dialogues; for instance, the prior art introduces explicit table and tree constructs to parallel the GUI notion of two-dimensional tabular layout and tree widgets. But since these higher-level constructs are not built up of atomic building blocks as in CML, mapping components constructs like table or tree (where tree is declared to be open or closed) to modalities like speech that lack a static two-dimensional display is impossible. Also, gestures like tree and table have no immediate equivalent on small screen devices.
[0062] (v) Synchronization
[0063] Tight synchronization across multiple interaction modalities is a key requirement of high-quality multi-modal interfaces. Going forward, such multi-modal clients are more likely to be constructed using the DOM (Document Object Model as described at http://www.w3c.org) provided by conventional browsers as the underlying platform. In this latter implementation scenario, the overlaying of the user interface constructs on the data definition detailed above is likely to once again become a stumbling block (e.g., same problem, now view by view as mentioned above for the lack of explicit environment to encapsulate the dialog/application state).
[0064] Tight synchronization across modalities is a basic design goal in CML. This is reflected throughout the CML design, and the resulting separation between conversational gestures and the definition of the data model makes it easier to implement a multi-modal browser that is constructed on top of the DOM using the classic Model View Controller (MVC) design.
[0065] (vi) Conversational Applications
[0066] Conversational applications can be developed declaratively by activating simultaneously multiple forms (each describing a transaction or portion of transaction). This requires the capability to re-use at different places in the file the same dialog component. As explained above, the overlay mentioned earlier does not support this requirement.
[0067] (vii) Lack of event binding
[0068] The lack of event binding capability limits the multi-channel/multi-modal capabilities of the application: there is no way to associate some specific logic action to some specific physical action. This is especially critical if we want to offer a multi-modal/multi-channel access where different bindings are desirable (e.g., a key short cut for telephony help, a voice command for help and a key combination on the keyboard for help).
[0069] (viii) Peer
[0070] Further, prior art attempts also rely on the technique of peers for generating different user interfaces from the same underlying representation; by doing so, it does not address the problems of synchronized multi-modal interaction.
[0071] These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0072] FIG. 1 is a diagram illustrating the conventional application programming approach;
[0073] FIG. 2 is a diagram illustrating the interaction based application programming approach of the present invention;
[0074] FIG. 3 is a diagram illustrating an example of a CML authored application according to an embodiment of the present invention;
[0075] FIG. 4 is a diagram illustrating the XFORMS concept;
[0076] FIGS. 5A and 5B are diagrams illustrating the use of XFORMS in the interaction based programming approach of the present invention;
[0077] FIGS. 6A through 6C are diagrams illustrating a GUI welcome page, transformed from CML source code page, as viewed with an HTML browser;
[0078] FIG. 7 is a diagram illustrating a GUI welcome page, transformed from CML source code page, as viewed with a WML browser;
[0079] FIG. 8 is a diagram illustrating a GUI welcome page, transformed from an HTML cosmetized CML source code page, as viewed with an HTML browser;
[0080] FIG. 9 is a diagram illustrating a new interpretation of the MVC model;
[0081] FIGS. 10-12 illustrate the migration road map from existing systems to fill use of CML according to the present invention;
[0082] FIG. 13 is a diagram illustrating a multimodal browser architecture according to an embodiment of the present invention;
[0083] FIG. 14 is a flow diagram illustrating an exemplary usage of CML in the application programming process according to an embodiment of a multimodal browser mechanism of the present invention;
[0084] FIG. 15 is another flow diagram illustrating an exemplary usage of CML in the application programming process according to an embodiment of a multimodal browser mechanism of the present invention; and
[0085] FIG. 16 is a diagram illustrating a multidevice browser architecture according to an embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0086] The following description will illustrate the invention using a preferred specification of CML, a preferred multi-modal browsing environment, and some exemplary applications for a better understanding of the invention. It should be understood, however, that the invention is not limited to these particular preferred implementations and exemplary applications. The invention is instead more generally applicable to any information access application regardless of the access protocol, modality, browser or device. Thus, the invention is more generally applicable to any information access situation in which it is desirable to provide synchronized, multi-modal, easy and convenient access of information to a user.
[0087] The detailed description is divided into the following sections for ease of reference: (I) CML Specification; and (II) Multimodal Browser Architecture to support, parse and render CML. Section I provides a detailed description of a preferred specification of CML according to the invention. Section II provides a detailed description of a preferred multimodal browsing environment implementing CML according to the invention.
[0088] I. CML Specification
[0089] The following description is a specification of a preferred embodiment of CML. This section is divided into the following subsections for ease of reference: (A) Introduction; (B) Comparative Examples; (C) CML Syntax; (D) Namespaces; (E) CML Attributes; (F) CML Components; (G) Binding Events; (H) Grouping Gestures and Defining Focus; (I) Data Model and Data Types; (J) Accessing Environment; (K) CML Traversal Model; (L) Transforming CML to Specific User Interface Languages; (M) Cosmetization; and (N) CML Document Type Definition.
[0090] A. Introduction
[0091] As mentioned above, separating content from presentation in order to achieve content re-use is the conventionally accepted way of deploying information on the World Wide Web (WWW). This is illustrated in FIG. 1. As shown, the existing approach with respect to application authoring is to consider only two components: a content component (A) and a presentation component (B). In the current W3C architecture, such separation is achieved by representing content in XML that is then transformed to appropriate final-form presentations (e.g., HTML, VoiceXML, WML) via application and device dependent XSL transforms. However, critical disadvantages exist with this approach. Indeed, the XSL rules typically depend on the backend application or domain. As a result, authoring of an application is a multiple authoring exercise with design of the XML content and then design of XSL style sheet per application/page and per target device/channel. In addition, when style sheets are expected to be used to transcode from one ML to another, as previously mentioned, transcoding is typically often between two legacy languages (e.g., HTML to WML), and the original content has been built in HTML while following very strict rules of authoring. Indeed, this is enforceable only if within a given company, for a given web site. Even in those cases, it is hardly implementable, in general, because of missing information across markup languages or modalities in order to provide the corresponding components in other modalities (e.g., an HTML form or menu does not provide the information required to render it automatically by voice).
[0092] CML is motivated by the realization that in addition to form (presentation) and content, there is a third component, i.e., interaction, that lies at the heart of turning static information presentations into interactive information. It is to be appreciated that static information is a very particular case where the user is passive and presented with all the information. This new paradigm is illustrated in FIG. 2. As shown, the present invention introduces the concept of programming by interaction wherein application authoring is broken into three components: content (A); presentation (B) and interaction (C). This new programming paradigm goes in pair with the development of a new programming environment, e.g., development tools, etc.
[0093] We refer to such "light-weight" information applications, or electronic information with small amounts embedded application intelligence, as "infoware" throughout this specification. Until now, such interaction has been represented partly within the presentational HTML, e.g., form elements, and partly within server-side logic encapsulated in servlets and CGI (Common Gate Interface) scripts. This combination has resulted in the creation of infoware or light-weight applications where the information content dominates. Good examples of infoware on today's WWW include e-businesses like Amazon.com.
[0094] As we move to a world where we interact with such infoware via multiple modalities, it is now time to achieve a clear separation between these three aspects of electronic content, namely, content, presentation, and interaction.
[0095] CML is based on the insight that all man-machine dialog can be broken down to an appropriate sequence of "conversational gestures" or modality-independent building blocks (components or elements) that can be appropriately combined to replace any interaction. CML encapsulates man-machine interaction in a modality-independent manner by encoding these basic building blocks in XML. Such CML encapsulations are later transformed to appropriate modality-specific user interfaces. This transformation is performed in a manner that achieves synchronization across multiple "controllers," i.e., browsers in today's WWW-centric world, as they manipulate modality-specific "views" of a single modality-independent "model." The terms "model," "view" and "controller," are well-known terms used in accordance with the classic MVC (model-view-controller) decomposition of computing, see, e.g., G. E. Krasner and S. T. Pope, "A Cookbook for Using the Model-View-Controller User Interface Paradigm in SmallTalk-80," Journal of Object-Oriented Programming, 1(3):26-49, August/September 1988, the disclosure of which is incorporated herein by reference. The result is uniform conversational behavior across a multiplicity of information appliances and coordinated, well-synchronized user interaction across a multiplicity of interface modalities.
[0096] B. Comparative Examples
[0097] Before providing a description of the specification of the CML preferred embodiment, we present some examples to illustrate fundamental principles of CML and programming by interaction. The examples refer to a "global cafe" site. Imagine a cafe that has decided to offer to its customers the possibility to pre-order their drinks prior to arriving the cafe or when in the cafe. As such, they fundamentally want to offer access to their information independently of the access channel.
[0098] Accordingly, a page is authored in CML. The CML code for generating this page is illustrated in FIG. 3 as CML code 10. The page fundamentally comprises a sequence of conversational gestures (note that the gestures here are taking some freedom from details of the actual CML specification, to be provided below, for the sake of providing a better understanding of the fundamental principles of CML and programming by interaction). The page may comprise the following:
[0099] (1) Title (shown as "gesture" 20 in FIG. 3): " Global Cafe" (i.e., a particular message to be rendered as a Title)
[0100] (2) A gesture message (shown as "gesture" 22 in FIG. 3): Would you like coffee, tea, milk or nothing?
[0101] (3) A gesture exclusive select out of a list (shown as "gesture" 24
in FIG. 3): the list is composed of the following items: coffee, tea, milk and nothing.
[0102] (4) A submit gesture (not expressly shown in FIG. 3). Clearly, the page fully defines the complete interaction with the user without introducing any dependency on the target modality (i.e., type of access channel or access device). It also clearly illustrates the programming model of programming by interaction:
[0103] (i) The application is programmed by interaction: using elementary components of interaction, independently of the target modality:
[0104] (a) A gesture message: "Global Cafe."
[0105] (b) A gesture message:Would you like coffee, tea, milk or nothing?
[0106] (c) A gesture exclusive select out of a list.
[0107] (d) A submit gesture.
[0108] (ii) This is connected to the backend which is programmed/developed conventionally. In this example, the connection to the backend is illustrated by the list (coffee, tea, milk and nothing) that has been read in the backend database and added as argument to the list, either statically, when the page has been produced, or dynamically, when the pages have been dynamically generated on the server using backend logic.
[0109] (iii) At this stage, if needed, constraints, validations of the attributes/variables can be added, for example using the XFORM syntax. For example, if the page asks for the age of the user in order to offer alcoholic beverages, a constraint can easily be expressed that restricts or modifies the dialog if the users indicates that he is under age. This is not explicitly shown on the page.
[0110] (iv) The presentation can thereafter be cosmetized. In the present example, it is done by using the gesture title instead of a gesture message: modality independent cosmetization. Modality specific cosmetization can also be added, for example by adding HTML tags that specify the background (color or image) to use for the resulting HTML page. This will be ignored by the other target modalities or replaced by a "behavior" provided for the other modalities. For example, when an image is displayed in the HTML modality, a caption may be provided to be a rendering instead for the WML, VoiceXML, or other modalities.
[0111] (v) The resulting pages can now be rendered by appropriate browsers. Two models exist. Either CML pages are served to browsers that can parse and render CML content (see Case B below) or they are served to legacy browsers that can only handle legacy languages, e.g., HTML, WML, VoiceXML, etc. (see Case A below).
[0112] (a) Case A: This case is also known as the "multi-channel" case. The target browser is well-defined (identified at the HTTP connection for HTML browser), because of the address of the requester (wireless gateway or speech browser) or because of the request (i.e., HTML file request versus WML page request). When a page is requested, it is fetched in CML and transcoded on the fly using the gesture-based XSL transformation rules into the target ML.
[0113] (b) Case B: The target browser handles CML. Therefore, it knows exactly what are the modalities that it supports (single or multiple) as well as the rules required to optimally render a given gesture in its supported modalities. These gesture XSL transformation rules are advantageously something that has been programmed in the browser when the device was built or when the browser was ported to it. Clearly, it means that the most appropriate programmer with the appropriate information (i.e., knowing fully well the device) takes that responsibility.
[0114] (vi) In both cases, the CML application developer does not need to do anything. He/she can always assume that the platform/browser will appropriately handle the rendering.
[0115] (vii) The gestures are completely independent of the target modality. They depend also only on the gesture not on the backend business logic/domain or anything else. This is why the XSL rules can be stored on the browser.
[0116] (viii) The XSL rules render the gestures based on the target modality. In the present case this means:
[0117] (a) Title:
[0118] HTML: Bold, Header character displayed
[0119] WML: Single card display
[0120] VoiceXML: Welcoming prompt
[0121] (b) Message:
[0122] HTML: display in regular characters
[0123] WML: display in regular character (possibly on multple cards)
[0124] VoiceXML: Generate a prompt message (text-to-speech or play back)
[0125] (c) Exclusive selection out of list:
[0126] HTML: Pull Down Menu
[0127] WML: Radio buttons
[0128] VoiceXML: Dialog (possibly Natural Language) to select in the menu (e.g., "You have that many items to select from. I will read the first three. Please select an item or say more for the next 3 . . . ").
[0129] Returning to FIG. 3, a visualization of the three example renderings that may be obtained in the global cafe application written in CML. Thus, from the CML code 10 comprising the gesture-based XSL transformations, an HTML rendering 12, a WML rendering 14, and a VoiceXML rendering 16 of the global cafe application are obtained.
[0130] (ix) When the transcoding is performed by a multi-modal/conversatio- nal browser (as described below), the gestures are uniquely identified using a node_id tag. This allows not only to produce the rendering in each registered modality (local or distributed), but also to provide very tight synchronization (i.e., on a gesture level or even sub-gestures levels, when it is a gesture for which this makes sense). For example, an event (I/O event) immediately impacts the state of the dialogs (i.e., the state as maintained in the multi-modal shell, for example, as in the above-referenced patent application identified by attorney docket no. YO999-178) and the other modalities. Thus, such tight synchronization may exist between the HTML rendering 12 as may be supported by a personal digital assistant and the VoiceXML rendering 16 as may be supported by a conventional telephone.
[0131] Note that the gestures XSL transformation rules can be overwritten by the application developer indicating where they should be downloaded. They can also be overwritten by user, application or device preference from what would be otherwise the default behavior.
[0132] New gestures can also be added, in which case, the associated XSL rules must be provided (e.g., a URL where to get them).
[0133] C. CML Syntax
[0134] In a preferred embodiment of CML, CML syntax is XML compliant. CML instances are well-formed XML. CML processors may be implemented as validating XML processors based on device constraints.
[0135] (i) Special CML notes
[0136] (1) Case Sensitivity
[0137] CML clients and servers treat CML element and attribute names as being case sensitive. As a convention, all element and attribute names defined in this specification use lower-case. This convention is strictly imposed on all predefined element and attribute names.
[0138] (2) Content Model
[0139] A CML instance consists of a sequence of XML elements. CML does not allow any pc data at top-level, i.e., all top-level children of a CML are necessarily elements.
[0140] (3) Sparse CMLs
[0141] CML instances may be sparse; except attribute node_id, the top-level CML attributes and elements documented in this specification are required.
[0142] (4) Entity References
[0143] All entity references in CML conform to the URI (Universal Resource Identifier) specification, see URI specification from the W3C at http://vww.w3.org.
[0144] (ii) Terminology
[0145] The terminology used to describe CML documents is defined in the body of this specification. The terms defined in the following list are used in building those definitions and describing the actions of a CML "processor." A CML processor generally refers to a processing device configured to execute CML code and associated applications. The terms are:
[0146] may--Conforming CML documents and processors are permitted to but need not behave as described.
[0147] must--Conforming CML documents and processors are required to behave as described; otherwise they are in error, as defined below.
[0148] error--A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it.
[0149] fatal error--An error which a conforming CML processor must detect and report to the application.
[0150] D. Namespaces
[0151] This section details the use of namespaces within all sections of a CML instance. Note that all elements and attributes defined in this specification are implicitly in namespace cml, i.e., element name message in a CML instance occurring within a general XML document is visible to the processing application as cml:message; CML attribute node_id would be visible to the XML processor as cml: node_id. The subsequent paragraphs in this section define the rules for how namespace cml is further subdivided to avoid name collisions amongst CML clients.
[0152] All namespaces introduced by "unqualified" namespaces, e.g., vxml are implicitly in namespace com. ibm. cml. vxml. More generally, vendor specific namespaces use a vendor prefix that is constructed from the vendor's domain name--this is analogous to the scheme used by systems like Java.
[0153] CML also uses namespaces to allow field names and values from different pieces of infoware to coexist. Thus, the fully qualified name of field drink in application cafe is cafe. drink. An example application will be given below for this drink example. Note that all field names in CML are always fully qualified, i.e., there is no implicit hierarchy within field names based on the nesting level at which an associated gesture occurs.
[0154] E. CML Attributes
[0155] CML instances can have the following XML attributes. Unless stated otherwise, all attributes are optional.
[0156] (i) node_id--Unique identifier for this CML node. Attribute node_id is required.
[0157] (ii) title--Human-readable metadata string specifying a title for the CML instance.
[0158] (iii) name--Name used to establish a namespace for all field values instantiated within the CML instance. This attribute is required for CML instances that are intended to be reusable.
[0159] (iv) action--Specifies the URL (Uniform Resource Locator) that is the target action of the CML instance.
[0160] (v) style--URI of associated XSL style sheet. Unless specified, the CML interpreter defaults to a generic style sheet for transforming the modality-independent CML instance into modality-specific encodings. Attribute style allows CML creators to override or specialize system-wide style rules.
[0161] F. CML Components
[0162] A CML instance represents a "conversational gesture." As previously mentioned, a conversational gesture is a basic building block of a dialog and encapsulates the interaction logic in a modality independent manner. Complex conversational components (also referred to as dialog components or dialog modules) are constructed by aggregating more basic conversational gestures described in detail in subsequent subsections. These complex conversational components are usually task oriented, e.g., get a phone number, get an address, etc. CML descriptions of basic conversational gestures can nest to the desired level of complexity. Besides nesting, complex conversational components can be obtained by combining the basic conversational gestures in parallel and/or in sequence. Also, complex conversational components can be achieved by combining imperative gestures, e.g., Conversational Foundation Classes (CFCs), as will be explained below. Note also that though every CML gesture is an XML element, the converse is not true, i.e., every XML element defined in this specification is not a CML gesture. Many CML gestures use sub-elements to encapsulate substructure of a given gesture. In the subsequent sections, CML elements that are "gestures" are marked as such in the subsection entitled Gesture Message.
[0163] CML is designed to inter-operate with other emerging W3C standards such as, for example, XHTML (Extensible HyperText Markup Language). CML elements therefore re-use, rather than reinvent, elements from other markup languages like HTML, MATHML, etc., where appropriate. Such elements, when embedded in a CML instance, are fully qualified, e.g., html: em. The first subsection below introduces the common aspects of the various CML building blocks; subsequent subsections describe each building block in detail. Notice that each CML primitive captures a basic conversational gesture; XML attributes are used to encode more specialized behaviors. Thus, for example, asking a yes or no question is a CML primitive; a yes or no question requiring user confirmation is a refinement of this primitive.
[0164] It is to be appreciated that because CML allows overwriting gestures and extending gestures, it does not matter what is the basic set of CML gestures that is provided in a particular embodiments of CML. The set and rules provided herein allow for implementation of any legacy page and interaction.
[0165] CML gestures share the following common XML attributes:
[0166] action--Action to be performed upon completion of the gesture. Attribute action can be one of link,return or submit.
[0167] (i) Gesture Message
[0168] The conversational gesture message is used to convey informational messages to the user. The gesture message is typically rendered as a displayed string or a spoken prompt. Portions of the message to be spoken can be a function of the current state of the various pieces of infoware being hosted by the CML interpreter (see section on accessing environment state).
[0169] Example:
[0170] <message node_id="1">
[0171] Your<html:em>checking</html:em>account balance is
[0172] <value name="banking.checking.balance"/>
[0173] after transfering
[0174] <value name="banking.checking.transfer"/>
[0175] to your
[0176] <value name="banking.creditCard.account"/>
[0177] </message>
[0178] Empty element value is used to splice in variable information from the current environment and is defined formally in the section on accessing environment state.
[0179] (ii) Gesture Help
[0180] The conversational gesture help is used to encapsulate contextual help to be displayed if the dialog runs into trouble. The gesture help is typically rendered as a displayed string or a spoken prompt. Portions of the message can be a function of the current state of the various pieces of infoware being hosted by the CML interpreter.
[0181] Example:
[0182] <help node_id="l">
[0183] You can check your account balances by specifying a
[0184] particular account. </help>
[0185] (iii) Final
[0186] CML element final is used within gestures to encapsulate actions to be taken upon successful completion of the encapsulated gesture, e.g., updating the enclosing environment based on user interaction.
[0187] (iv) Gesture Boolean: Yes Or No Questions
[0188] The conversational gesture boolean encapsulates typical yes or no questions. The gesture boolean encapsulates the prompt to be used as a message, as well as the default response, if any. Attributes require_confirmation, require_confirmation_if_no and require_confirmation_if_yes (all false by default) allow infoware applications to refine the dialog.
[0189] Example:
[0190] <boolean default="y"
[0191] node_id="1"
[0192] require_confirm_if_no="true">
[0193] <grammar type "text/jsgf">
[0194] (yes.vertline.yeah) {yes}.vertline.(no nay) {no}
[0195] </grammar>
[0196] <message>
[0197] Please confirm that you would like to stay at the
[0198] <value href="travelCenter.hotel.selected"/>
[0199] </message>
[0200] </boolean>
[0201] (v) Gesture Select
[0202] The conversational gesture select is used to encapsulate dialogues where the user is expected to pick from a set of choices. It encapsulates the prompt, the default selection, as well as the set of legal choices. Attributes of element select refine the gesture to achieve mutually exclusive select (visually rendered as a group of radio buttons), select from range, visually rendered as a scrollbar, etc. Sub-elements of select include:
[0203] choices
[0204] Contains the list of possible choices--embedded either by value or by reference. Element choices contains a list of one or more choice elements as well as, at most, one default element that specifies the default selection, if any.
[0205] predicate
[0206] Predicate encapsulating the test that the selection should satisfy.
[0207] help
[0208] Help to be offered in case the dialog gets stuck.
[0209] error
[0210] Contains a message to be used if the predicate fails.
[0211] Example:
[0212] <select name="portfolio.fund"
[0213] node_id="1"
[0214] require predicate="yes">
[0215] <message node_id="2">
[0216] Which of your positions would you like to check?
[0217] </message>
[0218] <help>
[0219] You can specify the names of stocks or funds you own
[0220] and we will report your current position.
[0221] </help>
[0222] <choices>
[0223] <var name="possibleChoices"/>
[0224] <default value="possibleChoices">
[0225] Check the position of all holdings</default>
[0226] </choices>
[0227] <predicate>
[0228] <condition>
[0229] fund in possibleChoices
[0230] </condition>
[0231] <error>
[0232] Sorry, you do not appear to own any shares in
[0233] <var name="portfolio.fund"/>
[0234] </error>
[0235] </predicate>
[0236] </select>
[0237] (vi) Predicate
[0238] The element predicate is used in CML to encapsulate rules for validating the results of a particular conversational gesture. Test predicates are expressed as simple conditionals using the expression syntax and semantics defined in the xpath specification from the W3C, i.e., XML Path Language, W3C Proposed Recommendation, the disclosure of which is incorporated by reference herein, see http://www.w3.org/tr/xpath- . Xpath specifies an expression syntax for accessing different portions of the document tree; validations that require calls to an application backend are handled separately.
[0239] Conversational gestures that include a predicate element qualify the action to be taken in case of a failed test via appropriate attributes.
[0240] (vii) Grammar
[0241] The CML sub-element grammar is modeled after element grammar in VoiceXML. Sub-element grammar encodes the grammar fragment; sub-element help encapsulates an appropriate help message to be played to the user to indicate what utterances are allowed. Where appropriate, CML gestures can provide grammar fragments that are assembled into more complex grammars by the CML interpreter.
[0242] The sub-elements grammar can be generalized as rules to process input, in particular, speech. These rules can be strict or can describe remote resources to be used for processing (URL), and provide arguments to pass to these resources that characterize what processing must be performed with what data file and how the result must be returned and to what address. In general, the grammar may be defined in line or defined via aURL.
[0243] In addition, it is also possible to declare this processing through an object tag, e.g., <object>. . . <object>. An object tag allows for loading Conversational Foundation Classes (CFCs) or Conversational Application Platform (CAP) services (see, e.g., the above-referenced PCT international patent application identified as US99/22927 (attorney docket no. YO999-111 wherein CAP is equivalent to CVM or Conversational Virtual Machine). Arguments can be passed to the object using XML attributes and variables. Results can be returned via similar variable place-holders. This allows these objects calls to access and modify the environment.
[0244] Objects can be qualified by attribute: execute that can take the values: parallel (executed in parallel, non blocking and it can notify on the fly effects on environment during its execution, prior to its completion), asynchronous (executed asynchronously, non blocking and notifies via event when completed to update the environment), blocking (the browser waits for completion of the object call, before updating the environment and continuing).
[0245] All the information needed to distribute the processing is described in the above-referenced PCT international patent application identified as US99/22925 (attorney docket no. YO999-113) which defines an architecture and protocols that allow distribution of the conversational applications. As such, the international patent application describes how such distribution can be done and how it allows, in the current case, to distribute the processing between a client browser and a server browser, as well as between local engines and server engines. This allows distribution of the processing of the input/output event across the network.
[0246] (viii) Gesture Menu
[0247] The gesture menu is a special case of gesture select. Gesture menu is used for encapsulating dialogues that help the user navigate through different subparts of an application. The same effect can be achieved using gesture select; however, having an explicit menu gesture enables authors to provide more semantic information about the reason why the select gesture is being used. Notice that in the example below, element menu is equivalent to element select with attribute action set to link.
[0248] Example:
[0249] <menu name="main">
[0250] <choice value="#query">Ask a question</choice>
[0251] <choice value="#browse">Browse available categories</choice>
[0252] </menu>
[0253] The value of attribute value in each choice specifies the URI target for that choice.
[0254] (ix) Gesture User Identification
[0255] The conversational gesture user_identification is used to encapsulate user login and authentication. It is designed to be generic--and is specialized for specific user interaction environments via style rules.
[0256] Sub-elements user and identify encapsulate conversational gestures for obtaining the user name and authentication information. Element predicate provides the test for ascertaining if the user has authenticated successfully.
[0257] Example:
[0258] <user_identify name="login"
[0259] require_predicate="yes"
[0260] on_fail="retry"
[0261] node_id="2">
[0262] <message node_id="3">
[0263] To use this service, you first need to login using your name
[0264] and personal identification.
[0265] </message>
[0266] <user name="userid"
[0267] node_id="4">
[0268] what is your user id?
[0269] </user>
[0270] <identify name="pin"
[0271] node_id="4">
[0272] Please provide your user authentication.
[0273] </identify>
[0274] <predicate>
[0275] <condition>
[0276] backend.authenticate(user id,pin)
[0277] </condition>
[0278] </predicate>
[0279] <error>
[0280] Sorry, login for <var name="userid"/>
[0281] with identification <var name="pin"/>failed.
[0282] </error>
[0283] </user_identify>
[0284] Variations on this gesture can be useful, e.g., explicit distinction between an identification gesture (e.g., identify who the person is), verification gesture (e.g., authentication of the claimant), speech biometrics (e.g., U.S. Pat. No. 5,897,616).
[0285] (x) Gesture Constrained Input
[0286] CML provides a number of pre-defined dialog components for obtaining user input such as dates and currencies. Typically, such input:is more open-ended than the various selection gestures enumerated so far, and is realized in conventional visual interfaces via simple edit fields. However, encapsulating the domain-specific constraints for such input gestures is advantageous in constructing spoken interaction. Also, notice that such domain-specific constraints are typically implemented in today's WWW interfaces as client-side scripts within HTML pages that perform validation of user input before it is submitted to a server. In CML, we formalize those input gestures that are widely used on today's WWW for performing standard user-level tasks. CML also provides an extension mechanism that allows this basic set of input gestures to be extended over time. Note that all CML elements defined in this list are gestures:
[0287] (1) Date--Specify date
[0288] (2) Time--Specify time.
[0289] (3) Currency--Specify currency amount.
[0290] (4) Credit card--Specify a credit card (including card type, card number and expiration date).
[0291] (5) Phone--Specify a telephone number.
[0292] (6) Email--Specify an e-mail address.
[0293] (7) URL--Specify a URL.
[0294] (8) Snail Address--Specify a "snail mail" address, including street, city/state/country and zip code.
[0295] The constrained input gesture can easily be extended by passing a grammar for other input fields. Note that this gesture can, in addition, be associated with transcoding rules that can be localized (i.e., internationalized and take regional flavors). This is a statement that is actually extendable to all the gesture and gesture based transcoding rules. Based on the location (i.e., calling number, origin of the IP address, preferences known about the user (on his local device/browser or transmitted through cookies to the server)), gestures can be expressed in another language (i.e., "Select yes or no" becomes "Selectionnez oui ou non" etc.) or adapted to the geography (e.g., zip code becomes postal code).
[0296] (xi) Gesture Unconstrained Input
[0297] The conversational gesture input is used to obtained user input where the input constraints are more complex (or perhaps non-existent). The gesture encapsulates the user prompt, application-level semantics about the item of information being requested, and possibly a predicate to test the validity of the input. Note that gesture input along with application-specific semantic constraints provides a means to extend the set of built-in constrained input gestures discussed in the previous section.
[0298] Example:
[0299] <Input node_id="1">
[0300] <Message>. . . </Message>
[0301] </Input>
[0302] (xii) Gesture Submit
[0303] The conversational gesture submit specifies the components from the environment to be packaged up and returned by the containing CML instance. It also encapsulates the prompt to be used as well as the target URI to which the encapsulated environment state is to be submitted.
[0304] Example:
[0305] <submit target="uri">
[0306] <env name="location.state"/>
[0307] <env name="location.city"/>
[0308] </submit>
[0309] Sub-element env specifies components of the environment to be submitted by the enclosing gesture.
[0310] It is to be appreciate that while various CML attributes and components have been described above, other attributes and components will be presented and defined below in the course of describing further aspects of this embodiment of CML. It should be understood that other attributes and components may be defined in accordance with the teachings of the invention. That is, the invention is not intended to be limited to the particular attributes and components that are described in this detailed description.
[0311] G. Binding Events
[0312] CML provides a flexible, extensible mechanism for application authors to define "logical input events" and the association between such logical events and the actual "physical input events" that trigger the defined logical events. CML gestures declare logical events that they are prepared to handle via CML attribute trigger when a defined logical event is received, the closest enclosing gesture that has a matching event in its trigger list handles the event. The CML attribute trigger allows a gesture to be triggered by an event that is logically bound to it. This mechanism is best illustrated by an example. In the fragment of CML code shown below, the application defines help as a logical input event, binds this to physical events in two separate modalities, and finally declares a CML gesture to handle the help event.
[0313] Example:
2
<cml name="travel"> <bind-event logical="help" modality="dtmf" physical="*"/> <bind-event logical="help" modality="qwerty" physical="h"/> <help name="help" trigger="help"> Top-level application help </help> ... </cml>
[0314] CML element bind-event takes three attributes:
[0315] (1) logical--Specifies the name of the logical event being defined.
[0316] (2) modality--Specifies the interaction modality in which the event is being bound.
[0317] (3) physical--Specifies physical event to bind to a logical event.
[0318] Input events that are not handled by CML gestures making up the application bubble up to the CML interpreter where standard platform events such as help are handled by a default handler. Bubble up means that search of a gesture that matches the trigger value is hierarchically bubbling up from the closest enclosing gesture to a higher one, until no gesture matches. In such a case, the trigger should be associated to a service offered by the browser, if not by the underlying platform (e.g., conversational virtual machine of YO999-111). If none are met, the event is ignored or a default message is returned to the user explaining that the input was not understood (or not supported) and ignored. These, however, are implementation choices of the browser and underlying platform, not choices of the language. Note that mechanism bind-event is designed to override platform behavior--it is not meant to be used as the exclusive mechanism for mapping user input to CML gestures. Thus, using element bind-event to bind all valid spoken utterances in an application to the appropriate gestures is deprecated.
[0319] Further, note that omitting attribute modality in element bind-event results in associating the specified physical binding in all modalities. Omitting value of attribute physical in element bind-event declares a logical event that is unbound, i.e., not bound to a physical event.
[0320] H. Grouping Gestures And Defining Focus
[0321] Conversational gestures when rendered to specific modalities to realize a a specific user interface are grouped appropriately to allow the user to interact with related portions of the interface. To understand this assertion, consider WWW applications that split the user interaction across several HTML pages, with related portions of the interface appearing on the same page. Similarly, speech interfaces allow users to specify any one of several related commands at a given time.
[0322] This form of grouping of gestures is best captured at the time the application is being authored. Such grouping may or may not be modality independent; CML allows application authors to encapsulate both forms of grouping.
[0323] Conversational gestures are grouped using the CML element group. Element group is further qualified by attributes id, modality and class. Attribute id is minimally required to group gestures. Attribute modality, if present, declares the specified grouping to be modality specific. Attribute class can be used in a manner analogous to the HTML class attribute to enable further selection of related elements whilst transcoding CML to languages like HTML.
[0324] By default, CML gestures enclosed in a single group element map to a user interface which enables the user to interact with any of the contained gestures--in the case of HTML, this results in the gestures being transcoded into a single page; in the case of VoiceXML, this results in the corresponding forms being made active in parallel.
[0325] Note that to activate groups of gestures in parallel is the way to implement mixed initiative NL interfaces: each command/query supported at a given time is characterized by a form built out of gestures (i.e., a group of gestures is called a form). When an input/output event occurs, the dialog manager provided by the browser or underlying platform will guess what are the gestures in the different forms that are activated and they allow to qualify their associated attributes (the environment variables associated to the gestures). When all the mandatory attributes of a form have received a value, the action is considered as disambiguated and executed. Note that extra constraints between the attributes can be expressed using XFORMS, as will be explained below. See also the above referenced patent application identified by attorney docket no. YO998-392 for discussion on parallel activation, and K. A. Papineni et al., "Free-flow dialog management using forms," Proc. Eurospeech, 1999, and K. Davies et al., "The conversational telephony system for financial applications," Proc. Eurospeech, 1999, the disclosure of which is incorporated by reference herein.
[0326] Instances of the element group cannot nest unless the inner group element specifies a value for attributes modality or class that is different from that specified in the enclosing element.
[0327] Efforts like XFORMS (http://www.w3.org/MarkUp/Forms/) have attempted to solve problems associated with existing markup languages by splitting forms into three layers (presentation, logic and data), as shown in FIG. 4, in an attempt to facilitate replacing the presentation for different kinds of browsers (however, XFORMS fails to address different modalities), while preserving the same backend. XFORMS data layer allows the application developer to define the data model for the form. The developer can use built-in data types or roll his own. XFORMS are building the data types on top of the work being done on XML Schemas. The logic layer allows the application developer to define dependencies between fields, for example, for running totals, or where one field requires another to be filed in. XFORMS supports a light-weight expression syntax, building upon widespread familiarity with spread sheets and existing forms packages. The application developer is still able to call out the scripts, when extra flexibility is needed. The presentation layer is consists of markup for forms controls and other HTML markup, where each control is bound to a field in the data model. "Getter" and "setter" functions allow the presentation to match the user's preferences, e.g., for dates and currencies, while retaining a canonical representation internally, thereby simplifying form processing. The same data field can have more than one presentation control bound to it. Changing the value in any of the controls then automatically updates all of the others.
[0328] As explained herein, XFORMS provides a back-end mechanism for separating out data from presentation. CML provides a mechanism to further separate the logic and presentation part into presentation rendering (i.e., modality-dependent rendering with no interaction information)/interaction (plus possible modality dependent cosmetic inputs)/content (i.e., backend data plus logic information minus all the interaction related logic components). This inventive concept is illustrated in FIG. 5A. As previously explained, the programming paradigm of the invention separates presentation/modality specific rendering A, interaction B, and content and backend/application logic C. FIG. 5A also illustrates the backend mechanism of XFORMS, as mentioned above, where data D is separated from the backend E. FIG. 5B represents how a form based mixed initiative NLU (natural language understanding) application is written in CML. Leters A and C denote the same items as in FIG. 5A. In the block denoted as B', the interaction/dialog information is described in terms of CML. This part describes the interactions (mandatory and optional) that need to occur in order to realize each of the activable transactions. To this you add an XFORMS component that captures constraint and data models associated to the underlying attribute data structure. The engine control and cosmetization part capture additional control parameters that are used to optimize the behavior of the conversational engines, in particular the dialog manager and NLU engines. Note that the CML portions can be used for rendering in other modalities, as described earlier. Block F denotes an exemplary form (e.g., a mutual fund demo form) that may be employed in accordance with block B'.
[0329] I. Data Model And Data Types
[0330] CML defines data-model or data-type primitives in the manner specified by the results of the W3C work on XML Schema and XML forms, see http://www.w3.org.
[0331] J. Accessing Environment
[0332] CML gestures define a collection of variables collectively called the "environment." As the CML document is traversed, variables in the environment are bound to the values resulting from successful user interaction. The environment can be accessed and manipulated within CML gestures via elements var, value and assign, as will be explained below. Note that all such names are always fully qualified.
[0333] (i) var--Element var declares (and optionally) initializes a variable (assigns it an initial value) in the current environment. Attribute name specifies the variable name. An initial value may be specified using the same syntax as specified for element assign, see below.
[0334] (ii) assign--Element assign assigns a value to a variable that already exists in the environment. That is, element assign is used to bind values in the environment. Attribute name specifies the variable to be bound. The value to be bound may be specified either as the value of attribute expr using the same expression syntax as used by xpath; alternatively, the value to be assigned may be specified as the contents of element assign. Element assign is typically used to bind or update intermediate variables that are not set by direct user interaction.
[0335] (iii) value--Element value retrieves the value of a defined variable. That is, attribute name of empty element value specifies the variable whose value is to be looked up in the environment. Value of attribute name may be a partially or fully qualified name (see section above on Namespaces) and is interpreted in the context of the containing CML gesture.
[0336] Note that as defined above, variables must be declared before they can be assigned.
[0337] K. CML Traversal Model
[0338] Infoware authored in CML is hosted by a conversational shell that mediates amongst multiple user agents--hereafter referred to as the CML interpreter. It is to be appreciated that the traversal model will be further discussed and illustrated in the context of FIGS. 10 and 11. User interaction proceeds by the CML interpreter mapping CML instances to appropriate modality-specific languages such as HTML and VoiceXML. These modality-specific representations are handed to the appropriate user agents which render modality-specific versions of the dialog.
[0339] The transformation from CML to modality-specific representations is preferably governed by XSL transformation rules (XSLT). Note that other transformation mechanisms can be used. XSLT is merely a method proposed for a preferred embodiment. For example, JSP--Java Server Pages or Java Beans can be used, as well as other techniques which transform, based on rules, the gestures to their target rendering. An example of such implementation is: for each gesture, we associate a java bean. The java bean carries its own rendering in each modality (through JSP). Thus, the invention is not limited to XSLT. In any case, these XSL rules are modality-specific. In the process of mapping the CML instance to an appropriate modality-specific representation, the XSL rules add the necessary information needed to realize modality-specific user interaction. As an example, when translating element select to VoiceXML, the relevant XSL transformation rule handles the generation of the grammar that covers the valid choices for that conversational gesture.
[0340] The process of transforming CML instances to modality-specific representations such as HTML may result in a single CML node mapping to a collection of nodes in the output representation. To help synchronize across these various representations, CML attribute node_id is applied to all output nodes resulting from a given CML node. When a given CML instance is mapped to different representations, e.g., HTML and VoiceXML by the appropriate modality-specific XSL rules, the shape of the tree in the output is likely to vary amongst the various modalities. However, attribute node_id allows us to synchronize amongst these representations by providing a conceptual backlink from each modality-specific representation to the originating CML node. In the above-referenced U.S. provisional patent application identified as U.S. Serial No. 60/128,081
(attorney docket no. YO999-178), a description is provided of how to develop a platform (the multi-modal shell) able to support tight multi-modal applications. The mechanism operates as follows. Each modality registers with the multi-modal shell the commands that it supports and the impact that their execution will have on the other registered modalities. Clearly, in the current case, upon parsing the CML page and transcoding the gestures, each gesture is kept in a data structure (i.e., the table) in the multi-modal shell. Upon an I/O event in a given modality, the node_id information is used to find the activated gesture and from the table (i.e., the CML document dialog tree), it is immediate to find the effect on the activated modality as well as the other modality (i.e., update of each view or fetch of a new page on the CML server).
[0341] As user interaction proceeds, variables defined in the environment by the current CML instance get bound to validated values. This binding happens first in one of the registered modality-specific user agents. The registered user agent sends an appropriate message to the conversational shell comprising of the updated environment and the node_id of the gesture that was just completed. Once the updated binding has been propagated to the CML interpreter, it messages all registered user agents with the node_id of the gesture just completed. Registered user agents update their. presentation upon receiving this message by first querying the CML interpreter for the portion of the environment that affects their presentation.
[0342] L. Transforming CML to Specific User Interface Languages
[0343] CML is transformed into user interface (ui) specific encodings, e.g., HTML, via transformation rules expressed in XSL. This section begins with some background material on XSL transformations and then presents examples on how XSL is used in the context of CML and multi-modal browsers according to the invention.
[0344] (i) XSL Transformations Background Information
[0345] The W3C XSL transformations (xslt) specification has been released as a Proposed Recommendation: XSL Transformations (xslt) Version 1.0, reference: W3C Proposed Recommendation Oct. 8, 1999, edited by James Clark, the disclosure of which is incorporated by reference herein. The above-referenced W3C Proposed Recommendation is part of the W3C Style activity. Specifically, the xslt specification defines the syntax and semantics of xslt, which is a language for transforming XML documents into other XML documents. xslt is designed for use as part of XSL, which is a stylesheet language for XML. A transformation in the xslt language is expressed as a well-formed XML document conforming to the Namespaces in the XML Recommendation, which may include both elements that are defined by xslt and elements that are not defined by xslt. A transformation expressed in xslt describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. A pattern is matched against elements in the source tree. A template is instantiated to create part of the result tree. The result tree is separate from the source tree. The structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, e