Subject: [Widex] WiDeX and XUP

From: "Jin Yu" <[email-masked]>
Date: Mon, 8 May 2006 15:49:14 -0700

Hi,

I just went through the WiDeX charter and requirements draft. It's very
interesting. I find it shares many goals with XUP (Extensible User Interface
Protocol), which was published as a W3C Note 4 years ago:
<http://www.w3.org/TR/xup/>.

XUP focuses on XML-based user interfaces languages (e.g. XUL, XAML, XHTML)
and manipulates DOM instances of those languages. XUP has two main concepts:
UI updates and UI events.

In XUP, UI updates are just remote DOM manipulations (add, remove, update
elements, etc.) of a UI model, which is a DOM instance of an XML UI
language. In addition, the UI updates are bi-directional. That is, the user
agent sends UI updates to server, containing end user's direct manipulations
as well as the UI changes made by client-side scripts; and the server sends
UI updates to the user agent, containing server-side application's changes
to the UI model.

On the other hand, UI events are events generated by the end user operating
the user agent; e.g. mouse-click, key-press. XUP allows any UI events to be
sent from the user agent to the server. Event details are defined by
concrete UI languages such as XUL and XAML. In addition, XUP supports
multiple event models. It supports DOM-style capture / bubbling events, as
well as Java Swing-style delegation-based events.

Currently XUP uses SOAP as the transport protocol. However, the SOAP binding
is not critical, and XUP could be used with other transport mechanisms as
well.

We have built an open source project OpenXUP (<http://www.openxup.org>) on
top of XUP. On that web site you can find an implementation prototype as
well as some research papers we have published.

I hope XUP and OpenXUP will be a useful reference material for this WG.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

_______________________________________________
Widex mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/widex

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 May 2006 00:03:25 -0500

> <http://www.w3.org/TR/xup/>.
. . .

Thanks. This is very interesting.

open question: What's the key differentiator between WIDEX and XUP?

--
Dean

---

From: Rosfran Lins Borges <[email-masked]>
Date: Tue, 09 May 2006 23:30:52 -0300

Hi,
        As a reader of this list, and an enthusiast of everything 
related with technology and its applications (such as the evolving 
Remote UI), I've been looking at the Widex evolution since the initial 
draft, and I compiled a small list of comments concerning this newly 
released Widex Requirements document. I hope my comments may be useful 
to everybody interested. Next, there are some points I felt that may 
potentially be misunderstood:
        At the second section (section 2, "Widex Entities"), there is a 
description about a lot of complex interactions among Widex Server 
instances and Widex Renderers. We can correctly understand that there is 
a component relationship [1:1] between the Widex Server and the User 
Interface (that, by its way, relates with the application logic), and a 
relation [1:m] (1 to many), where for each Widex Server instance, there 
are some Widex Renderer related instances. By reading this paragraph, 
one can see that may be missing a little something about Widex Renderers 
and User Interfaces, and it would be: 1) something really missing, and 
maybe the Widex requirements now hasn't been worrying so much about it, 
and this will be pretty specified in the framework. or 2) it is a open 
question, it will be put in the hands of implementors. But, this is a 
very important concern, because there are a lot of UI mappings (such as 
session IDs, timestamps for UI events, UI component/widgets IDs, etc.), 
which should be considered on remote UI framework models (e.g., 
synchronizing the UI Model state between the UI application and Widex 
Renderer). Below, the part of the draft I got this:

/--- ( Widex Requirements snippet start) ---
//
2.  Widex Entities
(...)
   There might be several Widex Servers in the same device, one for each
   application that can export the user interface and for each Widex
   server there might be several Widex Renderers which are rendering the
   user interface.
--- ( Widex Requirements snippet finish) ---/

    I observed yet that there are explanations using the term "device", 
which couldn't be interpreted as a "distributed/networked device", as it 
really is meaning:

/--- ( Widex Requirements snippet start) ---
//3.2.  Remote User Interface

   The Remote User Interface (RUI) is a technique in which *a user
   interface is rendered on another device than the one that runs the
   application logic *while keeping the user interface synchronised with
   the application logic.

--- ( Widex Requirements snippet finish) ---/

    The next thing I had noted was in the section 3.3, "Widex Objects": 
RUI (Remote UI Objects) are not defined anymore in this draft, it was 
changed to Widex Objects (WO). You can see this typo below:

/--- ( Widex Requirements snippet start) ---

//3.3.  Widex Objects

 (...)

   There are two types of WOs:

   WO Update (*RUI*.Update):
      *WO*.Update messages contain description of changes to XML DOM
      trees.  The updates can target individual nodes in order to update

--- ( Widex Requirements snippet finish) ---/

    The next section, 3.4, has two concerns: the first one is the typo 
that refers to a "RUIO" (Remote UI Object), when it should be "WO" 
(Widex Object); second aspect in this paragraph is the description of 
the transport protocol as a component that transports WOs as a "string 
of bits, without looking at them": this would mean that the protocol 
must to send the WOs through the network transport layer using some kind 
of data serialization, which will get the original XML-based data for 
all the UI events and updates, and create a binary representation of 
them before sending/receiving. But I am just guessing. And I hadn't 
understood the requisite that says that WO data must to be transported 
using this protocol, and it cannot "look at them" ("them" referring to 
the WO data):

/--- ( Widex Requirements snippet start) ---/
/3.4.  Transport Protocol

   The Transport Protocol is a protocol that just transports the *RUI*Os
   as a string of bits, without looking at them.
//--- ( Widex Requirements snippet //finish //) ---/

       There are 3 NAT traversal scenarios described in the draft, but 
since there is a item at section 5.3 ("The WOs MUST support server 
initiated updates"), this creates a new need, since we complain with the 
rule that says: "the session setup mechanism MUST be able to establish 
sessions  from both Widex Renderers and Widex Servers, e.g. remote user 
interface pull and push" (section 5.2, "Session Setup"). Since Widex 
Session Setup can establish a session from both Renderers and Servers, I 
can see a scenario where a Widex Server must to establish a session, and 
send some kind of UI model (WO update) to the Renderer located in a 
public network, them it should guess about some kind of NAT traversal to 
allow a proper interaction between Renderer and Server. For example, a 
remote user interface push to the Renderer in a public network, and a 
Server that works in a private network enviroment, like a house; the 
Server providing instantaneous security images from user's home, let's 
suppose. So, I guess is missing the case when the Widex Server is 
located inside a private network.

/--- ( Widex Requirements snippet //start // ) ---/
/4.1.2.  Scenario 2: Widex Server Located in Internet

   In this scenario the Server is located somewhere in the Internet, has
   a globally routable, public IP address (and/or FQDN), and the client
   is behind a NAT device.  The access network is a network where/
/--- ( Widex Requirements snippet //finish // ) ---/

    At a first sight, the first item of the section 5.3 is not clear 
enough: we can think in the "semantics" term, the "markup" concept is 
very clear too, but I couldn't relate these 2 words with the last word 
of this item, "synchronized": one cannot make assumptions with 
"semantincs synchronized", nor "markup synchronized", but maybe this 
ought to really means that "the WOs MUST NOT be aware of the semantics 
of the markup language that describes its event and update messages, 
which is one of the attributes negotiated at the Widex Session 
instantiation". I could see this only after some readings in the draft:
 
/--- ( Widex Requirements snippet start) ---/
/5.3.  Widex Objects Requirements

   o  The WOs MUST NOT be aware of the *semantics of the markup that is
      synchronized.*
/
/--- ( Widex Requirements snippet finish) ---/

    I hope that it had been well explained (I tried!). Let me see if you 
found something useful in my explanation...

Regards,
Rosfran Borges