WIDEX V. Stirbu Internet-Draft Nokia Intended status: Standards Track D. Raggett Expires: December 21, 2006 W3C/Volantis June 19, 2006 Widget Description Exchange Service (WIDEX) Framework draft-stirbu-widex-framework-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a framework used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update operations. Stirbu & Raggett Expires December 21, 2006 [Page 1] Internet-Draft The WIDEX Framework June 2006 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture Paradigm . . . . . . . . . . . . . . . . . . . . 3 3. The Widex Framework Definition . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Service Discovery and Session Setup . . . . . . . . . 7 3.2.2. Widex Synchronisation . . . . . . . . . . . . . . . . 8 3.2.3. Transport . . . . . . . . . . . . . . . . . . . . . . 8 4. Widex Synchronisation Messages . . . . . . . . . . . . . . . . 8 4.1. WO.Update Message . . . . . . . . . . . . . . . . . . . . 8 4.2. WO.Event Message . . . . . . . . . . . . . . . . . . . . . 8 4.3. WO.Selector Message . . . . . . . . . . . . . . . . . . . 9 5. Processing External Resources . . . . . . . . . . . . . . . . 9 5.1. References to External Resources . . . . . . . . . . . . . 9 5.2. Synchronising with External Resources . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 12 A.1. Simple Widex Elements . . . . . . . . . . . . . . . . . . 12 A.2. Multimodal Widex Server . . . . . . . . . . . . . . . . . 12 A.3. Multiple Rendering Engines Widex Renderer . . . . . . . . 12 A.4. Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Stirbu & Raggett Expires December 21, 2006 [Page 2] Internet-Draft The WIDEX Framework June 2006 1. Introduction This document describes the components and interactions between them of the Widex framework used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update operations. The framework described in this document is intended to fulfil the requirements described in Internet-Draft Widex Requirements [I-D.ietf-widex-requirements]. 2. Architecture Paradigm The Model-View-Controller architectural pattern (MVC) [MVC] divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model. Figure 1 describes an extension to the MVC architecture which enables the situations where the user interface and the model may be on different machines. +-----------------------------+ +---------------+ | Widex Server | | Widex Renderer| | +-------+ .............. | | +-----------+ | | | | . .--------------->| | | | | | . View . | Updates | | | | | | | . (Virtual) .<---------------| | | | | | .............. | | | | | | | Model | | | | View | | | | | +------------+ | | | | | | | | | |<---------------| | | | | | | Controller | | Events | | | | | | | | |--------------->| | | | +-------+ +------------+ | | +-----------+ | +-----------------------------+ +---------------+ Figure 1: Architecture paradigm - A networked MVC architecture In the networked MVC architecture, the View is exported on the remote device while a Virtual View is maintained on the server. The change- propagation mechanism that ensures consistency between the user interface and the model is augmented with methods which keep the View synchronised with the Virtual View, synchronisation being done via updates. Additionally, user interactions or gestures are captured by the View copy and passed to the Controller as events. Stirbu & Raggett Expires December 21, 2006 [Page 3] Internet-Draft The WIDEX Framework June 2006 It is quite common that the View is not needed in the Widex Server, but there are situations (e.g. desktop applications) in which the Widex Server has to maintain a real copy of the View. Therefore, we call the View in the Widex Server to be Virtual. 3. The Widex Framework Definition 3.1. Overview In the context of Widex working group, the user interface is understood as XML [XML1.0] data describing the user interface. Typically, the XML data is manipulated as levels 2 and 3 in the W3C Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style information associated with the user interface can be manipulated via the DOM, see [DOM2.Style]. The Widex Framework, described in Figure 2, is based on the networked MVC paradigm described in Section 2. The Widex framework is handling all network related issues involved in the networked MVC architecture, e.g. discovery and matching of Widex Elements, setting up sessions between Widex Elements, marshaling XML DOM updates or events and exchanging them over the wire. There are many events emitted on the Widex Renderer side that have no meaning for the application running in the Widex Server and in order to minimise the network traffic the Widex Framework MUST deliver only the information having remote scope. Stirbu & Raggett Expires December 21, 2006 [Page 4] Internet-Draft The WIDEX Framework June 2006 +-------------------------------+ +--------------------------+ | Widex Server | | Widex Renderer | | | | | |+--------------------+ | | +---------------+| || Application | | | | Rendering || || | | | | Engine || ||+---++------------+ | +-----+ | | +-----+ | +------------+|| ||| ||+..........+| | | | |Selector| | | | |+..........+||| ||| ||. Event .|-->| |----------->| |-->|. Event .||| ||| ||. Handler .| | | F | | | | F | | |. Listener .||| ||| M ||+..........+| | | r | | | | r | | |+..........+||| ||| o || |<--| W a |<-----------| W a |<--| XML DOM ||| ||| d || Controller | | | i m | | Events | | i m | | | ||| ||| e || |-->| d e |----------->| d e |-->| Engine ||| ||| l |+------------+ | | e w | | | | e w | | +------------+|| ||| |.............. | | x o | | | | x o | | +------------+|| ||| |. View .-->| r |----------->| r |-->| View ||| ||| |. (Virtual) . | | k | |Updates | | k | | | ||| ||| |. XML DOM .<--| |<-----------| |<--| XML DOM ||| ||+---+.............. | | | | | | | | +------------+|| |+--------------------+ +-----+ | | +-----+ +---------------+| +-------------------------------+ +--------------------------+ Figure 2: Widex Framework Overview The Widex Framework needs a mechanism by which the Widex Renderer determines which events have a remote scope and therefore need to be serialized and forwarded to the Widex Server. The determination of which events have a remote scope could be achieved in one of three ways: o prior agreement between the Widex Renderer and Widex Server o a list of events passed during session establishment o the Widex Server could direct the Widex Renderer to add and remove event listeners during the session The Widex Framework enables remote event listeners to be dynamically attached to DOM nodes during the session using WO.Selector messages as described in Section 4.3. Local event listeners that are not forwarded to the Widex Server may be dynamically attached through WO.Update messages as described in Section 4.1, and which update the DOM tree that is interpreted by the Widex Renderer. With the Model-View-Controller design pattern, updates to the (virtual) DOM tree held by the Widex Server are reflected as WO.Update messages that in turn result in the Widex Renderer updating its copy of the DOM tree to match the changes made by the Widex Server. A similar process occurs when the Widex Server adds or Stirbu & Raggett Expires December 21, 2006 [Page 5] Internet-Draft The WIDEX Framework June 2006 removes event listeners, where these changes are mediated by WO.Selector messages. With the DOM Event model it is possible to attach multiple event listeners for the same event. The DOM event model defines an ordering in which the listeners are invoked, and provides a means to stop further propagation of the event, and to prevent the default event handler from being invoked. In the case of a mix of local and remote event listeners, depending on where they are attached, a local event listener could stop further propagation and thereby prevent the remote event listener from being invoked. The other way around is more complicated. The stub used by the Widex Renderer for remote event listeners could itself stop further propagation, but there would be undue latency incurred if this was to be done by the corresponding event handler in the Widex Server. In an implementation where the Widex Server maintains an explicit XML DOM for the View, changes made by the Widex Server to this View result in DOM events, e.g. DOM Mutation events. The Widex Framework in the server (as shown in Figure 1) can listen for these events to generate the corresponding Widex messages. The Widex Framework in the Renderer interprets these messages to reflect the changes to its copy of the XML DOM for the View. Note that the Widex messages are independent of whether the Widex Server maintains an explicit DOM for the View, that is, an in-memory XML DOM tree, as this is an implementation dependent design choice. 3.2. Components The Widex Framework has three components: o Service Discovery and Session Setup o Widex Sync o Transport Stirbu & Raggett Expires December 21, 2006 [Page 6] Internet-Draft The WIDEX Framework June 2006 +-----------+ +--------------------------+ | | | | | Service | | Widex Sync | | Discovery | | | | and | +--------------------------+ | Session | | Setup | +--------------------------+ | | | Transport | +-----------+ +--------------------------+ Figure 3: Widex Framework Components 3.2.1. Service Discovery and Session Setup The Service Discovery and Session Setup component is treated by the Widex Framework as a black box; any service discovery mechanism being able to find matches between a Widex Server and a Widex Renderer and any session setup mechanism able to establish a session between a matching Widex Server and Widex Renderer can be used as part of the framework. We define a match or compatibility between a Widex Server and Widex Renderer when the Widex Renderer can display the user interface exported by the Widex Server. Typically this means that both devices support the same XML DOM and XML DOM Events specifications and the Widex Renderer has rendering capabilities for the XML user interface language exported by the server. Quite often, the Widex Server can make better decisions on what user interface to export to a particular Widex Renderer if it has additional information about its hardware capabilities, e.g. screen size, color depth, input methods. Therefore, the Service Discovery mechanism MUST negotiate the following capabilities: o supported XML DOM level, o supported XML DOM Events level, o supported XML user interface description language, o supported transport mechanism. The Service Discovery mechanism SHOULD negotiate the following capabilities for the Widex Renderer: o event listeners o device configuration where examples of the device configuration includes the display Stirbu & Raggett Expires December 21, 2006 [Page 7] Internet-Draft The WIDEX Framework June 2006 resolution, the color depth, and input methods. The Session Setup mechanism MUST be able to initiate the Widex Session between the Widex Server and the Widex Renderer using the selected transport mechanism. 3.2.2. Widex Synchronisation The Widex Sync component provides the functionality that enables the marshaling of XML DOM updates and events. Additionally, the Widex Sync component provides the control messages that determine which events have remote scope. 3.2.3. Transport The Transport component is treated by the Widex Framework as a black box; any transport mechanism being able to facilitate the exchange of Widex Sync messages between a Widex Server and a Widex Renderer can be used as part of the framework. The Transport mechanisms MUST deliver the Widex Sync messages as string of bits between the Widex Server and the Widex Renderer in a timely, reliable and in sequence manner. 4. Widex Synchronisation Messages 4.1. WO.Update Message The WO.Update messages contain description of changes to XML DOM trees. The updates can target individual nodes in order to update their properties and attributes, or can target parts of the DOM tree in order to change its structure, e.g. add/delete/replace nodes or branches. Typically, a Widex Servers can trigger WO.Update messages that produce the full range of mutations while Widex Renderers trigger WO.Update messages that target individual nodes to update their properties and attributes. WO.Update messages MUST be encoded using formats defined by REX [W3C.WD-rex-20060202]. 4.2. WO.Event Message The WO.Event messages are primarily used to carry events triggered on the Widex Renderer side so that they can be caught by the application logic event handlers on the Widex Server side. A secondary use of Stirbu & Raggett Expires December 21, 2006 [Page 8] Internet-Draft The WIDEX Framework June 2006 WO.Event messages is where the application logic itself raises events that may be caught by event handlers associated with the remote user interface. Note: Some UI markup languages, e.g. Glade [1], do not have events defined at document level and therefore WO.Event messages MUST be able to serialize the events emitted by the associated libraries, e.g. GTK+ [2]. 4.3. WO.Selector Message The WO.Selector message MUST contain sufficient information to enable the Widex Renderer to add or remove remote event listeners associated with particular nodes in the XML DOM. 5. Processing External Resources 5.1. References to External Resources User interface markup languages may contain references to external resources such as images and streaming audio/visual media. The means by which the Widex Renderer accesses these resources is out of scope for the Widex Framework. 5.2. Synchronising with External Resources WO.Update messages may including timing information for when they should be applied. In some cases, this will involve synchronising to streaming media, for instance, when WO.Update is used to update a user interface described in SVG, where the updates need to be synchronized with an associated audio stream. 6. IANA Considerations This document makes no request to IANA. 7. Security Considerations The Widex Framework provides no security facilities (e.g. authentication or privacy ) of its own. It relies on the framework components for all of these abilities. Stirbu & Raggett Expires December 21, 2006 [Page 9] Internet-Draft The WIDEX Framework June 2006 8. Acknowledgements The authors would like to thank Jin Yu for his contribution in developing this document. 9. References 9.1. Normative References [DOM2.Core] Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, J., Champion, M., and S. Byrne, "Document Object Model (DOM) Level 2 Core Specification", W3C Recommendation, November 2000. [DOM2.Events] Pixley, T., "Document Object Model (DOM) Level 2 Events Specification", W3C Recommendation, November 2000. [DOM2.Style] Wilson, C., Le Hegaret, P., and V. Apparao, "Document Object Model (DOM) Level 2 Style Specification", W3C Recommendation, November 2000. [DOM3.Core] Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, J., and S. Byrne, "Document Object Model (DOM) Level 3 Core Specification", W3C Recommendation, April 2004. [I-D.ietf-widex-requirements] Stirbu, V. and D. Raggett, "Widget Description Exchange Service (WIDEX) Requirements", draft-ietf-widex-requirements-02 (work in progress), May 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [W3C.WD-DOM-Level-3-Events-20060413] Hoehrmann, B., Hegaret, P., and T. Pixley, "Document Object Model (DOM) Level 3 Events Specification", World Wide Web Consortium WD http://www.w3.org/TR/2006/ WD-DOM-Level-3-Events-20060413, April 2006. [W3C.WD-rex-20060202] Berjon, R., "Remote Events for XML (REX) 1.0", World Wide Web Consortium Stirbu & Raggett Expires December 21, 2006 [Page 10] Internet-Draft The WIDEX Framework June 2006 WD http://www.w3.org/TR/2006/WD-rex-20060202, February 2006. [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation, February 2004. 9.2. Informative References [MMI.Arch] Barnett, J., "Multimodal Architecture and Interfaces", W3C Working Draft, April 2005. [MVC] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and M. Stal, "Pattern-Oriented Software Architecture, Volume 1: A System of Patterns", John Wiley & Sons , August 1996. [W3C.NOTE-xup-20020528] Yu, J., "XUP - Extensible User Interface Protocol", W3C NOTE NOTE-xup-20020528, May 2002. [W3C.REC-SVG11-20030114] Jackson, D., Ferraiolo, J., and e. 淳, "Scalable Vector Graphics (SVG) 1.1 Specification", World Wide Web Consortium Recommendation http://www.w3.org/TR/2003/ REC-SVG11-20030114, January 2003. [W3C.REC-xhtml1-20020801] Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText Markup Language (Second Edition)", World Wide Web Consortium Recommendation http://www.w3.org/TR/2002/ REC-xhtml1-20020801, August 2002. [W3C.REC-xml-events-20031014] Raman, T., Pemberton, S., and S. McCarron, "XML Events", World Wide Web Consortium Recommendation http:// www.w3.org/TR/2003/REC-xml-events-20031014, October 2003. URIs [1] [2] Stirbu & Raggett Expires December 21, 2006 [Page 11] Internet-Draft The WIDEX Framework June 2006 Appendix A. Deployment Scenarios This Appendix describes the possible scenarios for deploying the Widex Framework. A.1. Simple Widex Elements In this scenario both devices running the Widex Server and the Widex Renderer are using the same platform. A.2. Multimodal Widex Server In this scenario the application running in the Widex Server is a multi-modal application compliant with W3C's Multimodal Architecture and Interfaces [MMI.Arch], enabling him to interact with several Widex Renderers. A.3. Multiple Rendering Engines Widex Renderer In this scenario the Widex Renderer has support for multiple rendering engines, enabling it to interact with several types of Widex Servers. A.4. Hybrid In this scenario the application running in the Widex Server is a multi-modal application and at the same time the Widex Renderer has multiple rendering capabilities. It is the job of the Service Discovery and Session Setup component to determine which is the most appropriate modality of interaction. Authors' Addresses Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 08000 Email: vlad.stibu@nokia.com Stirbu & Raggett Expires December 21, 2006 [Page 12] Internet-Draft The WIDEX Framework June 2006 Dave Raggett W3C/Volantis 35 Frome Road Bradford on Avon, Wiltshire BA15 2EA United Kingdom Phone: +44 1225 866240 Email: dsr@w3.org Stirbu & Raggett Expires December 21, 2006 [Page 13] Internet-Draft The WIDEX Framework June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stirbu & Raggett Expires December 21, 2006 [Page 14]