W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: REX and XUP

From: Paul Libbrecht <paul@activemath.org>
Date: Mon, 22 May 2006 10:39:12 +0200
Message-ID: <447178B0.1080602@activemath.org>
To: Robin Berjon <robin.berjon@expway.fr>
Cc: Jin Yu <jinyu@martsoft.com>, public-webapi@w3.org

May I raise the fear that both REX and XUP might get affected by XQuery 
Update ? I've just heard about it:
    http://www.w3.org/TR/xqupdate/
To me XUpdate tasted much tinier but with the power of XQuery nowadays...
paul

Robin Berjon wrote:
> On Feb 12, 2006, at 23:05, Jin Yu wrote:
>> I just went through the REX working draft. It's very interesting and I
>> believe this is essential for a richer and more interactive web. In the
>> draft, I did not find any reference to XUP, which is very similar in 
>> nature;
>> so I just want to bring it up to share with you.
>
> That's my fault. When I started looking at similar solutions existing 
> elsewhere to see if the need had already been addressed, I looked in 
> many places... but not W3C! XUP looks like a very nice start for a 
> specification, it's a shame that while W3C accepted your Member 
> Submission (back then called "Notes") but that it was not put on the 
> Recommendation track by a WG. Do you know why that was the case?
>
>> In XUP, UI updates are the same as mutation events in REX's terminology.
>> Basically, 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 XUP, 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 scripts; and the server sends UI 
>> updates to
>> the user agent, containing server-side application's changes to the UI
>> model.
>
> This can be done in REX as well: there is no assumption that the 
> communication is only unidirectional (although that mode is supported 
> since it's a strong requirement). If there are intended 
> request/response semantics, they are expected to be at the protocol 
> binding layer (so for instance if someone made a SOAP binding for REX, 
> I would expect it to have some strong similarities with XUP).
>
>> In addition, XUP supports multiple event models. It supports DOM-style
>> capture / bubbling events, as well as Java Swing-style delegation-based
>> events.
>
> For REX we decided to only support DOM Events as that is simpler and 
> is more likely to integrate well with the event infrastructure used by 
> many W3C UI technologies. Can you think of specific things that could 
> not be done by using only this model?
>
>> The major difference with REX is that XUP is a protocol, and it has a 
>> SOAP
>> binding. The SOAP binding is not critical; in fact XUP could be used 
>> with
>> other transport mechanisms as well.
>
> Right, REX is meant to be a "pluggable" piece of technology, to be 
> reused in a variety of situations. Proposals have already been made to 
> integrate it with streaming protocols, with BEEP, and with HTTP. No 
> one has yet suggested providing a SOAP binding for it, but I would 
> expect that to be straightforward enough. The precise reason why it 
> isn't a protocol is because when we started we already knew that 
> people wanted to use it both in broadcasting and in request/response 
> scenarios.
>
>> I hope XUP will be a useful reference material for this WG.
>
> It definitely is, thank you very much. In fact, we intend to "steal" 
> some of its features at some point :) Of notable interest are session 
> initiation (for protocol bindings) and listener manipulation.
>
> Thanks a lot!
>
> --Robin Berjon
>    Senior Research Scientist
>    Expway, http://expway.com/
>
>
>
Received on Monday, 22 May 2006 08:39:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT