From widex-bounces@ietf.org Fri Jun 02 21:20:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FmKp0-0008ST-OK; Fri, 02 Jun 2006 21:20:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FmKoz-0008SO-Dc
	for widex@ietf.org; Fri, 02 Jun 2006 21:20:57 -0400
Received: from smtp104.sbc.mail.mud.yahoo.com ([68.142.198.203])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmKow-0005cV-Vi
	for widex@ietf.org; Fri, 02 Jun 2006 21:20:57 -0400
Received: (qmail 22839 invoked from network); 3 Jun 2006 01:20:54 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@64.186.173.202 with
	login)
	by smtp104.sbc.mail.mud.yahoo.com with SMTP; 3 Jun 2006 01:20:53 -0000
From: "Jin Yu" <jyu@openxup.org>
To: <Vlad.Stirbu@nokia.com>,
	<widex@ietf.org>
Subject: RE: [Widex] Updated Widex framework draft
Date: Fri, 2 Jun 2006 18:20:45 -0700
Organization: OpenXUP.org
Message-ID: <001d01c686ab$f18124a0$1e0aa8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B0223D7FB@trebe101.NOE.Nokia.com>
Thread-Index: AcaEpb8YEiThetIGRVumagg6M26dzgAY6yWw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

Hi,

In the current draft, there are two ways to attach event listeners to a node in
the DOM tree: at programming level using DOM3's EventTarget interface, and at
document level using XML events and ad-hoc syntax.

By "programming level", I assume what it means is for the application code to
use the DOM3 EventTarget API in the virtual view / DOM at the server side (not
the real view / DOM at the renderer side); and then those API calls get
serialized into WO.Selector messages and delivered to the renderer.

DOM3 uses the term "programming level" because it doesn't have remote events in
mind. "Programming" means using script to attach listeners to nodes on the
client side. For us, I think what's important is WO.Selector messages, and how
the messages are generated is not a big concern. Of course, we could mention
that one possibility is for the server side toolkit to offer DOM3' EventTarget
API to operate on the virtual view.

So I would re-categorize the ways to attach event listeners to a DOM node -
inline (within UI DOM tree) or external (outside of UI DOM tree):

- inline listener specification

This includes ad-hoc syntax from various UI languages, e.g. HTML' onClick
attribute. In addition, one could use the global attributes from XML Events if
the hosting UI language supports them. In this category, WO.Update messages
should be used to maintain the listeners.

- external listener specification

This involves using WO.Selector messages to add / remove / update event
listeners in the renderer. The messages would carry the generic <listener>
element from XML Events. For example:

<addEventListener>
  <listener id="ls1" event="sul:mouse-click" observer="aCircle"/>
</addEventListener>

<removeEventListener>
  ...
</removeEventListener>

The "handler", "phase", and "propagate" attributes of the listener element may
not be relevant to network event delivery, but we can worry about that later in
the Message Formats draft.

The benefit of using external specification is that it's more flexible and
reusable (just like the CSS case).

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

> From: Vlad.Stirbu@nokia.com [mailto:Vlad.Stirbu@nokia.com] 
> Sent: Wednesday, May 31, 2006 4:31 AM
> To: widex@ietf.org
> Subject: [Widex] Updated Widex framework draft
>
> Hi, 
> Updated version of the Widex framework draft available at 
> http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-framework-01.txt. 
> It will be available shortly also in the IETF drafts repository.
> 
> Vlad


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Sun Jun 04 06:57:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FmqIq-0006bL-4G; Sun, 04 Jun 2006 06:57:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FmqIo-0006bG-KK
	for widex@ietf.org; Sun, 04 Jun 2006 06:57:50 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmqIk-0004R8-A7
	for widex@ietf.org; Sun, 04 Jun 2006 06:57:50 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 39EFB4EFB2;
	Sun,  4 Jun 2006 06:57:45 -0400 (EDT)
Date: Sun, 4 Jun 2006 11:57:39 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Updated Widex framework draft
In-Reply-To: <001d01c686ab$f18124a0$1e0aa8c0@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606031330091.8874@localhost.localdomain>
References: <001d01c686ab$f18124a0$1e0aa8c0@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 2 Jun 2006, Jin Yu wrote:

> In the current draft, there are two ways to attach event listeners 
> to a node in the DOM tree: at programming level using DOM3's 
> EventTarget interface, and at document level using XML events and 
> ad-hoc syntax.
>
> By "programming level", I assume what it means is for the 
> application code to use the DOM3 EventTarget API in the virtual 
> view / DOM at the server side (not the real view / DOM at the 
> renderer side); and then those API calls get serialized into 
> WO.Selector messages and delivered to the renderer.
>
> DOM3 uses the term "programming level" because it doesn't have 
> remote events in mind. "Programming" means using script to attach 
> listeners to nodes on the client side. For us, I think what's 
> important is WO.Selector messages, and how the messages are 
> generated is not a big concern. Of course, we could mention that 
> one possibility is for the server side toolkit to offer DOM3' 
> EventTarget API to operate on the virtual view.
>
> So I would re-categorize the ways to attach event listeners to a 
> DOM node - inline (within UI DOM tree) or external (outside of UI 
> DOM tree):

I appreciate the desire to make the draft easier to understand,
but I don't think your suggested wording is quite right, however
with a few email exchanges, I am sure we can work something out.

The overview in section 3.1 attempts to describe how event listeners 
are bound using existing mechanisms:

   a) via the DOM EventTarget interface
   b) via markup

Which of these two is better is context dependent and not something
that Widex should take a position on.

It then outlines the means by which a Widex Server and Renderer
can arrange for event listeners that forward events from the
Widex Renderer to the Widex Server. I think we agree that at
a high level this comes down to:

  1) by prior arrangement
  2) a list of events passed at session establishment
  3) dynamically during the application session

We agree that there are two ways for the Widex Server to dynamically 
add event listeners, one being based upon updating the markup 
through WO.Update messages and the other that uses WO.Selector
messages to directly invoke the EventTarget interface.

Not all event listeners will forward their events to the Server,
as markup languages may include local scripts. These could bind
event listeners via either markup or the EventTarget interface.
I don't think the terminology of inline and external listeners
quite works. For instance, is an event listener bound through
a line of script in a linked script file inline or external?
It isn't inline in the markup, and yet it doesn't forward the
event to the Widex Server.

I will try to come up with proposed rewording for sections 3.1
and 4.3 to make the document clearer.

BTW to support WO.Selector, I have proposed an extension to the DOM3 
Event specification. The idea is to define a pair of new events that 
are associated with adding or removing event listeners. If you think 
in terms of synchronizing DOM trees for the MVC View, then the 
action of adding a listener to the View results in the generation
of a DOM AddListenerEvent that the Widex Server then forwards to the 
Widex Renderer to synchronize the Renderer's copy of the DOM tree. 
This works in just the same way as for DOM Mutation events. If 
this proposal is accepted, the REX specification would be extended 
to provide an XML serialization for the new events.

Regards,

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEgrynb3AdEmxAsUsRApSdAKDfZMEt2CNZKuD5pvhpgbMA52fDcgCgm5lw
UCUf/SPLCd81JLtGgzIMLm8=
=/DMz
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Sun Jun 04 16:56:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FmzeW-0006ey-Ck; Sun, 04 Jun 2006 16:56:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FmzeV-0006et-1f
	for widex@ietf.org; Sun, 04 Jun 2006 16:56:51 -0400
Received: from smtp104.sbc.mail.mud.yahoo.com ([68.142.198.203])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmzeU-0006wh-9L
	for widex@ietf.org; Sun, 04 Jun 2006 16:56:51 -0400
Received: (qmail 56098 invoked from network); 4 Jun 2006 20:56:49 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@69.109.106.228 with
	login)
	by smtp104.sbc.mail.mud.yahoo.com with SMTP; 4 Jun 2006 20:56:48 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>
Subject: RE: [Widex] Updated Widex framework draft
Date: Sun, 4 Jun 2006 13:56:38 -0700
Organization: OpenXUP.org
Message-ID: <000a01c68819$63001eb0$6602a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaHxbh6JwmNbqCUSOegA392aPUxLwAQuKRQ
In-Reply-To: <Pine.LNX.4.62.0606031330091.8874@localhost.localdomain>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> It then outlines the means by which a Widex Server and Renderer
> can arrange for event listeners that forward events from the
> Widex Renderer to the Widex Server. I think we agree that at
> a high level this comes down to:
> 
>   1) by prior arrangement
>   2) a list of events passed at session establishment
>   3) dynamically during the application session

Yes, I agree.

> We agree that there are two ways for the Widex Server to dynamically
> add event listeners, one being based upon updating the markup
> through WO.Update messages and the other that uses WO.Selector
> messages to directly invoke the EventTarget interface.

Here is my understanding of how the EventTarget interface could be used to add /
remove listeners:

1. application code on the server side uses the interface to operate on the
virtual view / DOM; the server toolkit then serializes the interface calls into
WO.Selector messages.

2. the renderer receives the WO.Selector messages and then uses this interface
to manipulate the event listeners. Note that in this case it is the renderer
implementation that is using the interface.

3. application code on the render side (e.g. JavaScript) uses this interface to
manipulate the event listeners. In this case, the EventTarget interface has
nothing to do with WO.Selector messages.

So, "programming level" is not equivalent to WO.Selector messages, because:

- as I said in #3, script manipulation on the renderer side has nothing to do
with WO.Selector messages. Actually, I don't think #3 is relevant to our
discussion here; it's outside of the scope of Widex.

- using EventTarget is just one way of implementing and generating WO.Selector
messages. For example, one could have listener specifications in some
server-side template, and then the template could be loaded by the server to
output WO.Selector messages.

> Not all event listeners will forward their events to the Server,
> as markup languages may include local scripts. These could bind
> event listeners via either markup or the EventTarget interface.
> I don't think the terminology of inline and external listeners
> quite works. For instance, is an event listener bound through
> a line of script in a linked script file inline or external?
> It isn't inline in the markup, and yet it doesn't forward the
> event to the Widex Server.

Yes, you are right; external vs. inline may not be accurate in this case. I
think we agree on principals there are two ways to manage listeners, through
WO.Update messages and WO.Selector messages. I just don't feel very comfortable
with "programming level" being the defining factor, for the reasons stated
above.

Also, since you mentioned it, I'm wondering if it makes any sense to distinguish
local vs. remote event listeners? By local, I mean events are handled locally by
some scripts and not sent to the server; and for remote, the events will be sent
to the server and handled remotely. I think we are more concerned about remote
events, but of course, WO.Selector messages could include both local and remote
event listeners.

> BTW to support WO.Selector, I have proposed an extension to the DOM3
> Event specification. The idea is to define a pair of new events that
> are associated with adding or removing event listeners. If you think
> in terms of synchronizing DOM trees for the MVC View, then the
> action of adding a listener to the View results in the generation
> of a DOM AddListenerEvent that the Widex Server then forwards to the
> Widex Renderer to synchronize the Renderer's copy of the DOM tree.
> This works in just the same way as for DOM Mutation events. If
> this proposal is accepted, the REX specification would be extended
> to provide an XML serialization for the new events.

Yes, I think this will be great.

BTW, I have a terminology issue w.r.t. DOM3 Event and REX. I think the term
"event" is overloaded: mutation to the DOM is not the same as mutation event. I
regard the first as the "action" and the latter as the "event", and that action
triggers event. Therefore, DOM mutations trigger DOM mutation events. Obviously
here we are more interested in DOM mutations, not DOM mutation events.

The REX spec treats UI updates as DOM mutation events, which is somewhat
confusing. Similar concern has been raised in the public-webapi mailing list
(<http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0030>).

The same applies to the event listeners, so I would call it AddListenerAction,
rather than AddListenerEvent.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 06 12:52:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fnemk-00005D-RU; Tue, 06 Jun 2006 12:52:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnemj-0008Um-4b
	for widex@ietf.org; Tue, 06 Jun 2006 12:52:05 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnemg-0000I4-LW
	for widex@ietf.org; Tue, 06 Jun 2006 12:52:05 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k56Gq1Oa028938 for <widex@ietf.org>; Tue, 6 Jun 2006 19:52:01 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Jun 2006 19:52:01 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Jun 2006 19:52:01 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 6 Jun 2006 19:50:33 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B022D1267@trebe101.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New I-D: Widex over BEEP
Thread-Index: AcaJiVObfYrh93RhS864tSiH/2dX9g==
From: <Vlad.Stirbu@nokia.com>
To: <widex@ietf.org>
X-OriginalArrivalTime: 06 Jun 2006 16:52:01.0420 (UTC)
	FILETIME=[8823A4C0:01C68989]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Subject: [Widex] New I-D: Widex over BEEP
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1455094502=="
Errors-To: widex-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1455094502==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C68989.885D4115"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C68989.885D4115
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

The draft will be available shortly in the IETF draft repository. Till
then, you can find it here:
http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-beep-00.txt.

Regards,
Vlad

Abstract

   This document describes a lightweight implementation of a remote user
   interface protocol, compatible with the Widget Description Exchange
   Service (Widex) framework.  The protocol is using the Block
   Extensible Exchange Protocol (BEEP) as the application transport
   substrate for the Widget Description Exchange Service.


------_=_NextPart_001_01C68989.885D4115
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.21">
<TITLE>New I-D: Widex over BEEP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The draft will be available =
shortly in the IETF draft repository. Till then, you can find it =
here:</FONT>

<BR><A =
HREF=3D"http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-beep-00.txt=
"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-beep-00.txt</F=
ONT></U></A><FONT SIZE=3D2 FACE=3D"Courier New">.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Vlad</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Abstract</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; This document =
describes a lightweight implementation of a remote user<BR>
&nbsp;&nbsp; interface protocol, compatible with the Widget Description =
Exchange<BR>
&nbsp;&nbsp; Service (Widex) framework.&nbsp; The protocol is using the =
Block<BR>
&nbsp;&nbsp; Extensible Exchange Protocol (BEEP) as the application =
transport<BR>
&nbsp;&nbsp; substrate for the Widget Description Exchange =
Service.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C68989.885D4115--


--===============1455094502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex

--===============1455094502==--




From widex-bounces@ietf.org Tue Jun 06 14:10:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fng0S-0005gs-1O; Tue, 06 Jun 2006 14:10:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fng0Q-0005gn-1e
	for widex@ietf.org; Tue, 06 Jun 2006 14:10:18 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fng0O-0001B7-K2
	for widex@ietf.org; Tue, 06 Jun 2006 14:10:18 -0400
Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k56IBcW8031646
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <widex@ietf.org>; Tue, 6 Jun 2006 13:11:39 -0500
Mime-Version: 1.0 (Apple Message framework v750)
Content-Transfer-Encoding: 7bit
Message-Id: <EC52D40F-825E-4B25-9B81-B62B839DE28F@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: widex@ietf.org
From: Dean Willis <dean.willis@softarmor.com>
Date: Tue, 6 Jun 2006 13:10:19 -0500
X-Mailer: Apple Mail (2.750)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: [Widex] Draft agenda for IETF 66 posted
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org


I've taken the liberty of posting a very drafty agenda for WIDEX at  
IETF 66 at:

http://www.softarmor.com/widex/meets/ietf66/agenda.html

Please review and suggest changes.

Note that the actual meeting time/date is unknown, as the IETF agenda  
has not yet stabilized.

--
Dean


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 06 14:39:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FngSK-0004EM-7m; Tue, 06 Jun 2006 14:39:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FngSI-0004Dj-7l
	for widex@ietf.org; Tue, 06 Jun 2006 14:39:06 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngSG-0005ZL-16
	for widex@ietf.org; Tue, 06 Jun 2006 14:39:06 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 601A14F1A1;
	Tue,  6 Jun 2006 14:39:03 -0400 (EDT)
Date: Tue, 6 Jun 2006 19:38:49 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Widex] Draft agenda for IETF 66 posted
In-Reply-To: <EC52D40F-825E-4B25-9B81-B62B839DE28F@softarmor.com>
Message-ID: <Pine.LNX.4.62.0606061930310.9004@localhost.localdomain>
References: <EC52D40F-825E-4B25-9B81-B62B839DE28F@softarmor.com>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 6 Jun 2006, Dean Willis wrote:

>
> I've taken the liberty of posting a very drafty agenda for WIDEX 
> at IETF 66 at:
>
> http://www.softarmor.com/widex/meets/ietf66/agenda.html

Thanks. I am hoping that we can spend some time looking at the new
REX draft which should be available by then, and at the issues that 
are turning up for binding to specific protocols. Vlad has been 
working on BEEP, and I will have something to report on HTTP, and
perhaps we can also get a discussion on SIP?

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEhcvAb3AdEmxAsUsRAs8rAKDB0Tujdv+BrgRlpBxLzkqP+wvPLwCbBFy5
J9X6P5W3PIgjN8oCgqXxtPY=
=uaxc
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 06 15:59:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FnhiJ-0004gQ-4v; Tue, 06 Jun 2006 15:59:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhiH-0004g8-Ra
	for widex@ietf.org; Tue, 06 Jun 2006 15:59:41 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhiG-0008Tq-CS
	for widex@ietf.org; Tue, 06 Jun 2006 15:59:41 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k56JxdYZ000381; Tue, 6 Jun 2006 22:59:39 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Jun 2006 22:59:38 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 6 Jun 2006 22:59:38 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Widex] Draft agenda for IETF 66 posted
Date: Tue, 6 Jun 2006 22:59:36 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B022D12C2@trebe101.NOE.Nokia.com>
In-Reply-To: <Pine.LNX.4.62.0606061930310.9004@localhost.localdomain>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Widex] Draft agenda for IETF 66 posted
Thread-Index: AcaJmQzGFtbALd6XTgORzQm/AR4fOAACmPdw
From: <Vlad.Stirbu@nokia.com>
To: <dsr@w3.org>, <dean.willis@softarmor.com>
X-OriginalArrivalTime: 06 Jun 2006 19:59:38.0357 (UTC)
	FILETIME=[BDCBEA50:01C689A3]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

Hi,

I think that we could take some time off requirements slot to make room
for REX discussion.

Vlad

>-----Original Message-----
>From: ext Dave Raggett [mailto:dsr@w3.org]=20
>Sent: 06 June, 2006 21:39
>To: Dean Willis
>Cc: widex@ietf.org
>Subject: Re: [Widex] Draft agenda for IETF 66 posted
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tue, 6 Jun 2006, Dean Willis wrote:
>
>>
>> I've taken the liberty of posting a very drafty agenda for WIDEX at=20
>> IETF 66 at:
>>
>> http://www.softarmor.com/widex/meets/ietf66/agenda.html
>
>Thanks. I am hoping that we can spend some time looking at the=20
>new REX draft which should be available by then, and at the=20
>issues that are turning up for binding to specific protocols.=20
>Vlad has been working on BEEP, and I will have something to=20
>report on HTTP, and perhaps we can also get a discussion on SIP?
>
>  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
>  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>
>iD8DBQFEhcvAb3AdEmxAsUsRAs8rAKDB0Tujdv+BrgRlpBxLzkqP+wvPLwCbBFy5
>J9X6P5W3PIgjN8oCgqXxtPY=3D
>=3Duaxc
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Widex mailing list
>Widex@ietf.org
>https://www1.ietf.org/mailman/listinfo/widex
>

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 14 07:42:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FqTld-0007E9-OP; Wed, 14 Jun 2006 07:42:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTld-0007Dz-9Z
	for widex@ietf.org; Wed, 14 Jun 2006 07:42:37 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTld-0004qk-82
	for widex@ietf.org; Wed, 14 Jun 2006 07:42:37 -0400
Received: from homer.w3.org ([128.30.52.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqTjU-0000nw-VP
	for widex@ietf.org; Wed, 14 Jun 2006 07:40:26 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id E672E4F001
	for <widex@ietf.org>; Wed, 14 Jun 2006 07:40:23 -0400 (EDT)
Date: Wed, 14 Jun 2006 12:40:16 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: widex@ietf.org
Message-ID: <Pine.LNX.4.62.0606141136420.8955@localhost.localdomain>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Subject: [Widex] Proposed rewording for Framework draft
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems that Jin isn't keen on the use of the term "programming
level" in section 3.1, so how about replacing:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

By

  The DOM describes two ways to associate an event
  listener to a node in the tree:

  1.  Using the DOM EventTarget interface as specified by
      DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413] or a
      method specific to the UI markup language.
  2.  Using markup, either with XML Events
      [W3C.REC-xml-events-20031014] or a language specific
      syntax, e.g.  XHTML [W3C.REC-xhtml1-20020801] or SVG 1.1
      [W3C.REC-SVG11-20030114].

And replacing:

  Following the DOM model, associating event listeners to a node
  in the tree at document level is done using WO.Update messages
  as described in Section 4.1, while at the programming level is
  done using WO.Selector messages as described in Section 4.3.

By

  The Widex Framework enables event listeners to be attached
  to DOM nodes using either WO.Update messages as described in
  Section 4.1, or through WO.Selector messages as described in
  Section 4.3.

Which avoids the use of "programming" vs "document level".

However, this leaves open the issue of how to distinguish
local and remote event listeners. The DOM EventTarget interface
only deals with local event handlers. XML Events allows you
to specify handlers via URIs but the assumption seems to be
that these are scripts that are downloaded and executed locally
by the markup language interpreter.

It seems to me that WO.Update messages can only be used to add local 
event listeners, unless there is specific provision for remote event 
listeners in the markup language itself. Remote event listeners can 
be added by WO.Selector messages, or as part of session 
establishment, or by prior arrangement.

I would therefore like to propose that we discard the text:

  DOM model describes mainly two ways to associate an event
  listener to a node in the tree:

  1.  at the programming level, using the EventTarget interface as
      specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
      or a method specific to the UI markup language.
  2.  at the document level, using XML Events
      [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
      ones provided by the UI markup language itself, e.g.  XHTML
      [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].

The text following figure 2 would then be:

  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.

I suggest we add something about how the MVC pattern allows
server-side operations on the DOM to be reflected to the
Widex Renderer as a way of helping to address the concerns
over the terminology of DOM Mutation events.

How about:

  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 removes event listeners,
  where these changes are mediated by WO.Selector messages.

  In a little more detail, changes made by the Widex Server
  to the XML DOM for the 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 has an explicit or a virtual
  View.

We can take up the terminological issue of events versus
actions in the REX specification. I don't think we need
to cover that in Widex where we seem have consensus on
the three kinds of messages (Update, Event, and Selector).

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEj/Wmb3AdEmxAsUsRAhJ2AKDIcW3yjcXKKrcyo9L4OcVeIGlAsgCgz8U/
5DWtIcIkPWRG0rFwNy3gAI8=
=5XTI
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 14 07:55:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FqTxe-0005Tu-1d; Wed, 14 Jun 2006 07:55:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTxc-0005Tn-Mk
	for widex@ietf.org; Wed, 14 Jun 2006 07:55:00 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTxb-0008EU-H1
	for widex@ietf.org; Wed, 14 Jun 2006 07:55:00 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 0A52E4EECF
	for <widex@ietf.org>; Wed, 14 Jun 2006 07:54:58 -0400 (EDT)
Date: Wed, 14 Jun 2006 12:54:51 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: widex@ietf.org
Subject: Re: [Widex] Proposed rewording for Framework draft
In-Reply-To: <Pine.LNX.4.62.0606141136420.8955@localhost.localdomain>
Message-ID: <Pine.LNX.4.62.0606141252230.8955@localhost.localdomain>
References: <Pine.LNX.4.62.0606141136420.8955@localhost.localdomain>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I forgot to cover changes to section 4.3:

I suggest replacing:

  The WO.Selector message MUST contain information about the
  event listeners associated to a node in the tree at the
  programming level only.

By:

  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.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEj/kRb3AdEmxAsUsRAqdzAJ9DZ/V45nxwFVSdh/vRD8PtjW6c+gCfUx2i
tsAbvF3OQOLaeOMxpiAomqY=
=pFdk
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 14 22:00:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fqh9b-00057l-Co; Wed, 14 Jun 2006 22:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqh9a-00057S-Q5
	for widex@ietf.org; Wed, 14 Jun 2006 22:00:14 -0400
Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fqh9X-0003Gc-TD
	for widex@ietf.org; Wed, 14 Jun 2006 22:00:14 -0400
Received: (qmail 19062 invoked from network); 15 Jun 2006 02:00:09 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@220.130.149.100
	with login)
	by smtp106.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2006 02:00:09 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>,
	<widex@ietf.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Wed, 14 Jun 2006 18:59:51 -0700
Organization: OpenXUP.org
Message-ID: <000401c6901f$671ede60$9101a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
In-Reply-To: <Pine.LNX.4.62.0606141136420.8955@localhost.localdomain>
Thread-Index: AcaPp6b0+SkdFnO2QpOMnPo26OYxkwAbfhlg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: 
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> It seems that Jin isn't keen on the use of the term "programming
> level" in section 3.1, so how about replacing:
> 
>   DOM model describes mainly two ways to associate an event
>   listener to a node in the tree:
> 
>   1.  at the programming level, using the EventTarget interface as
>       specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
>       or a method specific to the UI markup language.
>   2.  at the document level, using XML Events
>       [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
>       ones provided by the UI markup language itself, e.g.  XHTML
>       [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].
> 
> By
> 
>   The DOM describes two ways to associate an event
>   listener to a node in the tree:
> 
>   1.  Using the DOM EventTarget interface as specified by
>       DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413] or a
>       method specific to the UI markup language.
>   2.  Using markup, either with XML Events
>       [W3C.REC-xml-events-20031014] or a language specific
>       syntax, e.g.  XHTML [W3C.REC-xhtml1-20020801] or SVG 1.1
>       [W3C.REC-SVG11-20030114].
> 
> And replacing:
> 
>   Following the DOM model, associating event listeners to a node
>   in the tree at document level is done using WO.Update messages
>   as described in Section 4.1, while at the programming level is
>   done using WO.Selector messages as described in Section 4.3.
> 
> By
> 
>   The Widex Framework enables event listeners to be attached
>   to DOM nodes using either WO.Update messages as described in
>   Section 4.1, or through WO.Selector messages as described in
>   Section 4.3.
> 
> Which avoids the use of "programming" vs "document level".

Just want to clarify - later on you proposed to remove this paragraph (#1 and
#2), so the above replacement wouldn't be used anyway?

> However, this leaves open the issue of how to distinguish
> local and remote event listeners. The DOM EventTarget interface
> only deals with local event handlers. XML Events allows you
> to specify handlers via URIs but the assumption seems to be
> that these are scripts that are downloaded and executed locally
> by the markup language interpreter.

Yes, DOM EventTarget was not designed with remote events in mind. So that's why
in one of my previous mails I was saying it would be useful for us only in the
case when it operates on the server-side virtual DOM and then the calls in turn
get serialized into WO.Selector messages.

As for XML Events, you are right. I think implicitly the resource pointed to by
the handler attribute is to be downloaded and executed in the renderer side.
Perhaps, we can suggest some new wording or syntax for the handler attribute?
Actually, all we need is a magic value *remote*, so the renderer knows to send
the event to the server rather than handle it locally. 

> It seems to me that WO.Update messages can only be used to add local
> event listeners, unless there is specific provision for remote event
> listeners in the markup language itself. Remote event listeners can
> be added by WO.Selector messages, or as part of session
> establishment, or by prior arrangement.

I think it's good to clearly distinguish local and remote event listeners.
However, technically speaking, WO.Update messages could be used to update remote
event listeners if the UI language has the explicit support for the notion of
remote events. Similarly, there is no reason why WO.Selector can't be used to
update local listeners.

On the other hand, currently there is no UI language having explicit support for
remote event listeners. So I'm ok with saying that WO.Update messages are to be
used for managing local listeners only. But some explanation is needed to inform
our readers of the rationales behind this design.

We may also want to say something about the behavior of multiple event listeners
(a mix of local and remote listeners) for the same event. For example, in XUP,
if a local listener can fully handle an event locally, it can prevent a remote
listener from being called.

> I suggest we add something about how the MVC pattern allows
> server-side operations on the DOM to be reflected to the
> Widex Renderer as a way of helping to address the concerns
> over the terminology of DOM Mutation events.
> 
> How about:
> 
>   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 removes event listeners,
>   where these changes are mediated by WO.Selector messages.

Yes, I think this is a good explanatory text.

>   In a little more detail, changes made by the Widex Server
>   to the XML DOM for the 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 has an explicit or a virtual
>   View.

I think this is more like an implementation suggestion (i.e. using DOM mutation
events on the server side). There are other implementation techniques for the
server to trace and serialize the UI updates. For example, in the OpenXUP
server, we don't use DOM events at all for performance reasons. The server has a
UI tracker, which tracks every API calls to the UI tree; and at the end of the
request processing, the content of the UI tracker is serialized into UI updates
and sent to the client.

> We can take up the terminological issue of events versus
> actions in the REX specification. I don't think we need
> to cover that in Widex where we seem have consensus on
> the three kinds of messages (Update, Event, and Selector).

Yes, Widex's terminology is fine. My problems are with REX ...

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Thu Jun 15 04:51:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FqnZS-0007OV-G8; Thu, 15 Jun 2006 04:51:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnZQ-0007Kd-D9
	for widex@ietf.org; Thu, 15 Jun 2006 04:51:20 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqnZP-0002MU-4M
	for widex@ietf.org; Thu, 15 Jun 2006 04:51:20 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 50CB34F0C8;
	Thu, 15 Jun 2006 04:51:18 -0400 (EDT)
Date: Thu, 15 Jun 2006 09:51:14 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
In-Reply-To: <000401c6901f$671ede60$9101a8c0@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606150937580.9070@localhost.localdomain>
References: <000401c6901f$671ede60$9101a8c0@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 14 Jun 2006, Jin Yu wrote:

> Just want to clarify - later on you proposed to remove this 
> paragraph (#1 and #2), so the above replacement wouldn't be used 
> anyway?

Correct.

> We may also want to say something about the behavior of multiple 
> event listeners (a mix of local and remote listeners) for the same 
> event. For example, in XUP, if a local listener can fully handle 
> an event locally, it can prevent a remote listener from being 
> called.

I think that comes down to the processing model for events. In the 
case of DOM events, there is provision to stop propagation and to
prevent the default handler from being invoked. It is therefore a
matter of where the remote event listener is attached. A local
handler could then prevent the remote event listener from being
invoked. The otherway round is more complicated. The stub used
in the Widex Renderer could stop further propagation, but there
would be undue latency to allow the corresponding handler in the
Widex Server to be able to do so.

We could include some text on this in the Widex Framework draft,
but is it really necessary? It seems like being at a different
level of detail.


>> I suggest we add something about how the MVC pattern allows
>> server-side operations on the DOM to be reflected to the
>> Widex Renderer as a way of helping to address the concerns
>> over the terminology of DOM Mutation events.
>>
>> How about:
>>
>>   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 removes event listeners,
>>   where these changes are mediated by WO.Selector messages.
>
> Yes, I think this is a good explanatory text.
>
>>   In a little more detail, changes made by the Widex Server
>>   to the XML DOM for the 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 has an explicit or a virtual
>>   View.
>
> I think this is more like an implementation suggestion (i.e.
> using DOM mutation events on the server side). There are other 
> implementation techniques for the server to trace and serialize 
> the UI updates. For example, in the OpenXUP server, we don't use 
> DOM events at all for performance reasons. The server has a UI 
> tracker, which tracks every API calls to the UI tree; and at the 
> end of the request processing, the content of the UI tracker is 
> serialized into UI updates and sent to the client.

Agreed, but what should we say if anything in the Widex Framework
draft?

>> We can take up the terminological issue of events versus
>> actions in the REX specification. I don't think we need
>> to cover that in Widex where we seem have consensus on
>> the three kinds of messages (Update, Event, and Selector).
>
> Yes, Widex's terminology is fine. My problems are with REX ...

Fine, I will see what can be done to resolve that in the W3C
work.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEkR+Hb3AdEmxAsUsRAtoBAKCB+xGTKteAqbiRZ4g62cbu3gmCpwCghhER
aKmbcesy1PQ6CadaPUM0cyg=
=v/GY
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Thu Jun 15 22:55:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fr4Ul-0003Qm-Mr; Thu, 15 Jun 2006 22:55:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr4Uk-0003Qh-GS
	for widex@ietf.org; Thu, 15 Jun 2006 22:55:38 -0400
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fr4Ui-0007pK-Uo
	for widex@ietf.org; Thu, 15 Jun 2006 22:55:38 -0400
Received: (qmail 64159 invoked from network); 16 Jun 2006 02:55:35 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp103.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2006 02:55:34 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Thu, 15 Jun 2006 19:55:18 -0700
Organization: OpenXUP.org
Message-ID: <000801c690f0$501e6d80$0202fea9@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
In-Reply-To: <Pine.LNX.4.62.0606150937580.9070@localhost.localdomain>
thread-index: AcaQWN+gIku4mVYuTwG/pUcVvlxUqQAjiiSw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> > We may also want to say something about the behavior of multiple
> > event listeners (a mix of local and remote listeners) for the same
> > event. For example, in XUP, if a local listener can fully handle
> > an event locally, it can prevent a remote listener from being
> > called.
> 
> I think that comes down to the processing model for events. In the
> case of DOM events, there is provision to stop propagation and to
> prevent the default handler from being invoked. It is therefore a
> matter of where the remote event listener is attached. A local
> handler could then prevent the remote event listener from being
> invoked. The otherway round is more complicated. The stub used
> in the Widex Renderer could stop further propagation, but there
> would be undue latency to allow the corresponding handler in the
> Widex Server to be able to do so.
> 
> We could include some text on this in the Widex Framework draft,
> but is it really necessary? It seems like being at a different
> level of detail.

I think it would be nice to have some text explaining how remote events and
listeners relate to (or work with) DOM's event model. Something along the line
you wrote above seems to be very reasonable.

> >>   In a little more detail, changes made by the Widex Server
> >>   to the XML DOM for the 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 has an explicit or a virtual
> >>   View.
> >
> > I think this is more like an implementation suggestion (i.e.
> > using DOM mutation events on the server side). There are other
> > implementation techniques for the server to trace and serialize
> > the UI updates. For example, in the OpenXUP server, we don't use
> > DOM events at all for performance reasons. The server has a UI
> > tracker, which tracks every API calls to the UI tree; and at the
> > end of the request processing, the content of the UI tracker is
> > serialized into UI updates and sent to the client.
> 
> Agreed, but what should we say if anything in the Widex Framework
> draft?

I think we could just rephrase your paragraph a bit, implying it's a possible
implementation approach. Also, I don't quite understand the last sentence - what
do you mean by "explicit view"? My understanding is that the server's view is
always virtual, whereas the renderer keeps the concrete (or physical) view.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 16 04:45:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fr9xE-0004M3-NV; Fri, 16 Jun 2006 04:45:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9xE-0004Ly-F7
	for widex@ietf.org; Fri, 16 Jun 2006 04:45:24 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr9xE-0004xO-66
	for widex@ietf.org; Fri, 16 Jun 2006 04:45:24 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 546264EFB2;
	Fri, 16 Jun 2006 04:45:23 -0400 (EDT)
Date: Fri, 16 Jun 2006 09:45:16 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
In-Reply-To: <000801c690f0$501e6d80$0202fea9@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606160916060.8838@localhost.localdomain>
References: <000801c690f0$501e6d80$0202fea9@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 15 Jun 2006, Jin Yu wrote:

>>> We may also want to say something about the behavior of multiple 
>>> event listeners (a mix of local and remote listeners) for the 
>>> same event. For example, in XUP, if a local listener can fully 
>>> handle an event locally, it can prevent a remote listener from 
>>> being called.
>>
>> I think that comes down to the processing model for events. In the
>> case of DOM events, there is provision to stop propagation and to
>> prevent the default handler from being invoked. It is therefore a
>> matter of where the remote event listener is attached. A local
>> handler could then prevent the remote event listener from being
>> invoked. The otherway round is more complicated. The stub used
>> in the Widex Renderer could stop further propagation, but there
>> would be undue latency to allow the corresponding handler in the
>> Widex Server to be able to do so.
>>
>> We could include some text on this in the Widex Framework draft,
>> but is it really necessary? It seems like being at a different
>> level of detail.
>
> I think it would be nice to have some text explaining how remote 
> events and listeners relate to (or work with) DOM's event model. 
> Something along the line you wrote above seems to be very 
> reasonable.

So how about:

  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.

Which leaves open the possibility for WO.Selector messages
to specify whether or not the event listener stub used in
the Widex Renderer should call the preventDefault method or
the stopPropagation method on DOM events.

>>>>   In a little more detail, changes made by the Widex Server
>>>>   to the XML DOM for the 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 has an explicit or a virtual
>>>>   View.
>>>
>>> I think this is more like an implementation suggestion (i.e.
>>> using DOM mutation events on the server side). There are other
>>> implementation techniques for the server to trace and serialize
>>> the UI updates. For example, in the OpenXUP server, we don't use
>>> DOM events at all for performance reasons. The server has a UI
>>> tracker, which tracks every API calls to the UI tree; and at the
>>> end of the request processing, the content of the UI tracker is
>>> serialized into UI updates and sent to the client.
>>
>> Agreed, but what should we say if anything in the Widex Framework 
>> draft?
>
> I think we could just rephrase your paragraph a bit, implying it's 
> a possible implementation approach. Also, I don't quite understand 
> the last sentence - what do you mean by "explicit view"? My 
> understanding is that the server's view is always virtual, whereas 
> the renderer keeps the concrete (or physical) view.

It is up to the implementation whether or not the Widex Server
has a virtual or explicit XML DOM for the View. However, that
has no effect on the Widex Protocol.

So how about:

  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 has an explicit or a virtual
  View.

Regards,

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEkm+ib3AdEmxAsUsRAiM1AKC2oI1nxVpz8awk7GTG7gM1JCxsygCg0y7n
sjnjZ91kGQn6mBmjzXY6N8U=
=N5R9
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 16 04:57:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrA9M-0000qy-94; Fri, 16 Jun 2006 04:57:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA9L-0000qs-3C
	for widex@ietf.org; Fri, 16 Jun 2006 04:57:55 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA9J-0005RC-KJ
	for widex@ietf.org; Fri, 16 Jun 2006 04:57:55 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5G8vpff026753; Fri, 16 Jun 2006 11:57:52 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Jun 2006 11:57:12 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Jun 2006 11:57:11 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Fri, 16 Jun 2006 11:57:04 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E80E@trebe101.NOE.Nokia.com>
In-Reply-To: <000801c690f0$501e6d80$0202fea9@martsbs.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Widex] Proposed rewording for Framework draft
Thread-Index: AcaQWN+gIku4mVYuTwG/pUcVvlxUqQAjiiSwAA7XHqA=
From: <Vlad.Stirbu@nokia.com>
To: <jyu@openxup.org>, <dsr@w3.org>
X-OriginalArrivalTime: 16 Jun 2006 08:57:11.0438 (UTC)
	FILETIME=[DAEAE2E0:01C69122]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

Hi Jin,=20

>
>> >>   In a little more detail, changes made by the Widex Server
>> >>   to the XML DOM for the 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 has an explicit or a virtual
>> >>   View.
>> >

>
>I think we could just rephrase your paragraph a bit, implying=20
>it's a possible implementation approach. Also, I don't quite=20
>understand the last sentence - what do you mean by "explicit=20
>view"? My understanding is that the server's view is always=20
>virtual, whereas the renderer keeps the concrete (or physical) view.
>
>Regards,
>
>Jin
>________________________________________
>Jin Yu
>OpenXUP.org

The "explicit view" on the Widex Server is when the UI exported through
Widex is of a desktop application, case in which a physical view is kept
also on the Widex Server.

Vlad=20

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 16 09:47:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrEfD-0000jc-SE; Fri, 16 Jun 2006 09:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEfD-0000iQ-1u
	for widex@ietf.org; Fri, 16 Jun 2006 09:47:07 -0400
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrEfB-0006Iz-Dx
	for widex@ietf.org; Fri, 16 Jun 2006 09:47:07 -0400
Received: (qmail 53439 invoked from network); 16 Jun 2006 13:47:04 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp103.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2006 13:47:04 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Fri, 16 Jun 2006 06:46:46 -0700
Organization: OpenXUP.org
Message-ID: <000f01c6914b$52896ab0$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaRITZxWEESd5kPTRKlMn0ygsfPMQAJjqSg
In-Reply-To: <Pine.LNX.4.62.0606160916060.8838@localhost.localdomain>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> So how about:
> 
>   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.
> 
> Which leaves open the possibility for WO.Selector messages
> to specify whether or not the event listener stub used in
> the Widex Renderer should call the preventDefault method or
> the stopPropagation method on DOM events.

Sounds good.

> > I think we could just rephrase your paragraph a bit, implying it's
> > a possible implementation approach. Also, I don't quite understand
> > the last sentence - what do you mean by "explicit view"? My
> > understanding is that the server's view is always virtual, whereas
> > the renderer keeps the concrete (or physical) view.
> 
> It is up to the implementation whether or not the Widex Server
> has a virtual or explicit XML DOM for the View. However, that
> has no effect on the Widex Protocol.
> 
> So how about:
> 
>   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 has an explicit or a virtual
>   View.

Sorry but I'm still a bit confused about the meaning of "explicit view", after
your explanation above and Vlad's explanation in the other email:

> The "explicit view" on the Widex Server is when the UI exported through
> Widex is of a desktop application, case in which a physical view is kept
> also on the Widex Server.

What's the difference between desktop app and non-desktop app? If you are
referring to web apps, then I don't see a difference here. In both cases, the
server would keep a virtual DOM / view (e.g. HTML DOM for web app, XUL DOM for
desktop app), and the physical view is kept in the renderer.

Or perhaps when you say desktop app, you are referring to X11-based app. In that
case, the roles are reversed. The server is indeed keeping a physical view,
whereas the client is keeping a virtual view. To me, Widex is the reverse of
X11, so I guess our Widex server shouldn't be keeping physical view.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 16 12:14:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrGxp-0004WB-2V; Fri, 16 Jun 2006 12:14:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGxo-0004W6-0O
	for widex@ietf.org; Fri, 16 Jun 2006 12:14:28 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGxl-0003On-OQ
	for widex@ietf.org; Fri, 16 Jun 2006 12:14:27 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id D3EE54EF0F;
	Fri, 16 Jun 2006 12:14:24 -0400 (EDT)
Date: Fri, 16 Jun 2006 17:14:16 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
In-Reply-To: <000f01c6914b$52896ab0$1e02a8c0@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606161706230.8802@localhost.localdomain>
References: <000f01c6914b$52896ab0$1e02a8c0@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jun 2006, Jin Yu wrote:

>> So how about:
>>
>>   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 has an explicit or a virtual
>>   View.
>
> Sorry but I'm still a bit confused about the meaning of "explicit 
> view", after your explanation above and Vlad's explanation in the 
> other email:
>

Vlad writes:

>> The "explicit view" on the Widex Server is when the UI exported 
>> through Widex is of a desktop application, case in which a 
>> physical view is kept also on the Widex Server.

Jin responds:

> What's the difference between desktop app and non-desktop app? If 
> you are referring to web apps, then I don't see a difference here. 
> In both cases, the server would keep a virtual DOM / view (e.g. 
> HTML DOM for web app, XUL DOM for desktop app), and the physical 
> view is kept in the renderer.
>
> Or perhaps when you say desktop app, you are referring to 
> X11-based app. In that case, the roles are reversed. The server is 
> indeed keeping a physical view, whereas the client is keeping a 
> virtual view. To me, Widex is the reverse of X11, so I guess our 
> Widex server shouldn't be keeping physical view.

I believe that whether or not the Widex Server maintains an
explicit in-memory XML DOM tree for the View is implementation
dependent and shouldn't effect the Widex protocol. If this is
just a question of wording, will the following work for you?

  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 has an explicit or a virtual
  View, that is, an in-memory XML DOM tree, as this is
  an implementation dependent design choice.

Regards,

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEktjfb3AdEmxAsUsRAoc/AJ4vOiLTWkBOqNnUNibGCH5jeOHFswCg0n5V
21JvzQVBhuj257SuWnyvvAk=
=QM11
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 16 19:43:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrNyD-0002At-Dz; Fri, 16 Jun 2006 19:43:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNyC-0002Ao-MY
	for widex@ietf.org; Fri, 16 Jun 2006 19:43:20 -0400
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrNyB-0004zE-1s
	for widex@ietf.org; Fri, 16 Jun 2006 19:43:20 -0400
Received: (qmail 55401 invoked from network); 16 Jun 2006 23:43:18 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp103.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2006 23:43:17 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Fri, 16 Jun 2006 16:42:59 -0700
Organization: OpenXUP.org
Message-ID: <000001c6919e$9ce06610$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkA
In-Reply-To: <Pine.LNX.4.62.0606161706230.8802@localhost.localdomain>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> Vlad writes:
> 
> >> The "explicit view" on the Widex Server is when the UI exported
> >> through Widex is of a desktop application, case in which a
> >> physical view is kept also on the Widex Server.
> 
> Jin responds:
> 
> > What's the difference between desktop app and non-desktop app? If
> > you are referring to web apps, then I don't see a difference here.
> > In both cases, the server would keep a virtual DOM / view (e.g.
> > HTML DOM for web app, XUL DOM for desktop app), and the physical
> > view is kept in the renderer.
> >
> > Or perhaps when you say desktop app, you are referring to
> > X11-based app. In that case, the roles are reversed. The server is
> > indeed keeping a physical view, whereas the client is keeping a
> > virtual view. To me, Widex is the reverse of X11, so I guess our
> > Widex server shouldn't be keeping physical view.
> 
> I believe that whether or not the Widex Server maintains an
> explicit in-memory XML DOM tree for the View is implementation
> dependent and shouldn't effect the Widex protocol. If this is
> just a question of wording, will the following work for you?
> 
>   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 has an explicit or a virtual
>   View, that is, an in-memory XML DOM tree, as this is
>   an implementation dependent design choice.

I think I got it. I see there are three ways for the server to maintain the
view:

1. the server maintains an in-memory copy of the XML DOM representing the view
on the renderer side.

2. the server could use some more efficient data structure, e.g. a UI tree or
graph to represent the view on the renderer side.

3. the server could represent the view as a string or binary blob. That's the
case for HTML page-based applications today. But the drawback is the WO.Update
messages will always contain full page updates, not incremental updates.

Do you call #1 explicit view and #2 and #3 virtual view? For me, I'd call all
three cases virtual view, since the physical view (the rendering) is only at the
renderer side and the server only keeps the data model that represents the view.
So I'd refer to #1 as something like "explicit DOM" rather than "explicit view".

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Sat Jun 17 11:11:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrcSG-0007ni-0o; Sat, 17 Jun 2006 11:11:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FrcSF-0007nZ-3V
	for widex@ietf.org; Sat, 17 Jun 2006 11:11:19 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrZor-00020o-PN
	for widex@ietf.org; Sat, 17 Jun 2006 08:22:29 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrZhU-0003Hm-7D
	for widex@ietf.org; Sat, 17 Jun 2006 08:14:52 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5HCEmcg018175; Sat, 17 Jun 2006 15:14:50 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Jun 2006 15:14:33 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Jun 2006 15:14:33 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Sat, 17 Jun 2006 15:14:27 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B023988EC@trebe101.NOE.Nokia.com>
In-Reply-To: <000001c6919e$9ce06610$1e02a8c0@martsbs.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Widex] Proposed rewording for Framework draft
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkAABp/cLA=
From: <Vlad.Stirbu@nokia.com>
To: <jyu@openxup.org>, <dsr@w3.org>
X-OriginalArrivalTime: 17 Jun 2006 12:14:33.0136 (UTC)
	FILETIME=[97885B00:01C69207]
X-Spam-Score: -1.9 (-)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

Hi,

Here is the proposed reworded text, following Figure 2, considering the
discussion in this thread:

   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
   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 has an explicit or a virtual
   View, that is, an in-memory XML DOM tree, as this is an
   implementation dependent design choice.

Please check if the above text is in line which what was discussed in
the thread... I may have missed something.

I'll post an updated version of the draft on Monday, before the deadline
for IETF66. Wait for your comments...

Vlad

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Sun Jun 18 21:12:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fs8J6-0001uB-EN; Sun, 18 Jun 2006 21:12:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs8J4-0001tC-V0
	for widex@ietf.org; Sun, 18 Jun 2006 21:11:58 -0400
Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fs8J3-0001QG-31
	for widex@ietf.org; Sun, 18 Jun 2006 21:11:58 -0400
Received: (qmail 91327 invoked from network); 19 Jun 2006 01:11:56 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp106.sbc.mail.mud.yahoo.com with SMTP; 19 Jun 2006 01:11:55 -0000
From: "Jin Yu" <jyu@openxup.org>
To: <Vlad.Stirbu@nokia.com>,
	<dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Sun, 18 Jun 2006 18:11:32 -0700
Organization: OpenXUP.org
Message-ID: <000001c6933d$51d59dc0$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkAABp/cLAAA5QPEA==
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B023988EC@trebe101.NOE.Nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

>    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

For the second bullet, I prefer "a list of messages..." rather than "a list of
events...". The word "event" is overloaded here; I don't think it refers to "UI
event", which is used predominantly in rest of the text.

>    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 has an explicit or a virtual
>    View, that is, an in-memory XML DOM tree, as this is an
>    implementation dependent design choice.

Perhaps we can rephrase the last sentence as:

"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."

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Mon Jun 19 03:49:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FsEVq-0002kD-8j; Mon, 19 Jun 2006 03:49:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEVp-0002k8-Fi
	for widex@ietf.org; Mon, 19 Jun 2006 03:49:33 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEVo-0007iF-2B
	for widex@ietf.org; Mon, 19 Jun 2006 03:49:33 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5J7nQlP007864; Mon, 19 Jun 2006 10:49:30 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Jun 2006 10:49:29 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 19 Jun 2006 10:49:28 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Mon, 19 Jun 2006 10:49:26 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B02398B9F@trebe101.NOE.Nokia.com>
In-Reply-To: <000001c6933d$51d59dc0$1e02a8c0@martsbs.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Widex] Proposed rewording for Framework draft
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkAABp/cLAAA5QPEABX3KYQ
From: <Vlad.Stirbu@nokia.com>
To: <jyu@openxup.org>, <dsr@w3.org>
X-OriginalArrivalTime: 19 Jun 2006 07:49:28.0722 (UTC)
	FILETIME=[E496DF20:01C69374]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

=20

>-----Original Message-----
>From: ext Jin Yu [mailto:jyu@openxup.org]=20
>Sent: 19 June, 2006 04:12
>To: Stirbu Vlad (Nokia-TP-MSW/Tampere); dsr@w3.org
>Cc: widex@ietf.org
>Subject: RE: [Widex] Proposed rewording for Framework draft
>

>>=20
>>    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=20
>add and remove
>>       event listeners during the session
>
>For the second bullet, I prefer "a list of messages..." rather=20
>than "a list of events...". The word "event" is overloaded=20
>here; I don't think it refers to "UI event", which is used=20
>predominantly in rest of the text.
>

I think that the meaning of this bullet is that you get the list of
events that have remote scope using the service discovery and session
setup component of the framework. They are exchanged according to the
particular mechanism and they will not be defined in this WG, e.g. as
WOs. For this reason, I tend to think that using the term messages is
confusing.

Vlad

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Mon Jun 19 09:46:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FsK5X-0007ZF-Nu; Mon, 19 Jun 2006 09:46:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FsK5W-0007Z9-Dk
	for widex@ietf.org; Mon, 19 Jun 2006 09:46:46 -0400
Received: from smtp101.sbc.mail.mud.yahoo.com ([68.142.198.200])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsK5U-0005Sh-Gk
	for widex@ietf.org; Mon, 19 Jun 2006 09:46:46 -0400
Received: (qmail 34656 invoked from network); 19 Jun 2006 13:46:43 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp101.sbc.mail.mud.yahoo.com with SMTP; 19 Jun 2006 13:46:43 -0000
From: "Jin Yu" <jyu@openxup.org>
To: <Vlad.Stirbu@nokia.com>,
	<dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Mon, 19 Jun 2006 06:46:20 -0700
Organization: OpenXUP.org
Message-ID: <000a01c693a6$c2b67730$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AcaRX/S0Os7dkDeMQ2ienBBi+DJLuwAPJqkAABp/cLAAA5QPEABX3KYQAAwhMRA=
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B02398B9F@trebe101.NOE.Nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> >>    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
> >
> >For the second bullet, I prefer "a list of messages..." rather
> >than "a list of events...". The word "event" is overloaded
> >here; I don't think it refers to "UI event", which is used
> >predominantly in rest of the text.
> >
> 
> I think that the meaning of this bullet is that you get the list of
> events that have remote scope using the service discovery and session
> setup component of the framework. They are exchanged according to the
> particular mechanism and they will not be defined in this WG, e.g. as
> WOs. For this reason, I tend to think that using the term messages is
> confusing.

I agree that this bullet won't be defined by this WG. But the term "event" is
even more confusing since it's already overloaded. So what's a better term?

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Mon Jun 19 10:31:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FsKmP-0001kk-Ei; Mon, 19 Jun 2006 10:31:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlT-0000rU-5H
	for widex@ietf.org; Mon, 19 Jun 2006 10:30:07 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKYQ-0001ay-Es
	for widex@ietf.org; Mon, 19 Jun 2006 10:16:39 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 914344EF0F;
	Mon, 19 Jun 2006 10:16:37 -0400 (EDT)
Date: Mon, 19 Jun 2006 15:16:30 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
In-Reply-To: <000a01c693a6$c2b67730$1e02a8c0@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606191503470.9381@localhost.localdomain>
References: <000a01c693a6$c2b67730$1e02a8c0@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 19 Jun 2006, Jin Yu wrote:

>>>>    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
>>>
>>> For the second bullet, I prefer "a list of messages..." rather
>>> than "a list of events...". The word "event" is overloaded
>>> here; I don't think it refers to "UI event", which is used
>>> predominantly in rest of the text.
>>>
>>
>> I think that the meaning of this bullet is that you get the list of
>> events that have remote scope using the service discovery and session
>> setup component of the framework. They are exchanged according to the
>> particular mechanism and they will not be defined in this WG, e.g. as
>> WOs. For this reason, I tend to think that using the term messages is
>> confusing.
>
> I agree that this bullet won't be defined by this WG. But the term 
> "event" is even more confusing since it's already overloaded. So 
> what's a better term?

The bullet point needs to be read in the context of the preceding 
paragraph:

  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

This I believe makes it pretty clear that what is being discussed 
are events that are raised in the Windex Renderer and which need to 
be forwarded to the Widex Server as WO.Event messages. The bullet 
point suggests that one way for the Widex Server to indicate which 
such events it is interested in is via a list of events that is 
exchanged with the Widex Renderer at session establishment. Widex 
won't define the events, but it is within our scope to define a 
mechanism for passing a list of event names as part of session 
establishment for a binding to specific protocol. This is something
we can now start talking about in more detail, but it would be
good to first reach agreement on publishing the framework draft.


  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFElrHEb3AdEmxAsUsRAvtvAKCtSWO8GIUYC6vXgVtkQOeW+4vjbwCggLAc
lXhqoAf+AAzeGn11vzFMtjk=
=JiY1
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Mon Jun 19 22:55:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FsWOn-0001G5-Iu; Mon, 19 Jun 2006 22:55:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWOl-0001Fh-MN
	for widex@ietf.org; Mon, 19 Jun 2006 22:55:27 -0400
Received: from smtp112.sbc.mail.mud.yahoo.com ([68.142.198.211])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsWOj-0002K4-Qi
	for widex@ietf.org; Mon, 19 Jun 2006 22:55:27 -0400
Received: (qmail 66053 invoked from network); 20 Jun 2006 02:55:25 -0000
Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@143.89.91.139 with
	login)
	by smtp112.sbc.mail.mud.yahoo.com with SMTP; 20 Jun 2006 02:55:24 -0000
From: "Jin Yu" <jyu@openxup.org>
To: "'Dave Raggett'" <dsr@w3.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
Date: Mon, 19 Jun 2006 19:55:02 -0700
Organization: OpenXUP.org
Message-ID: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <Pine.LNX.4.62.0606191503470.9381@localhost.localdomain>
Thread-Index: AcaTqvuChyZlSffoRwe1n7RsnOecOQAaRFwg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

> The bullet point needs to be read in the context of the preceding
> paragraph:
> 
>   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
> 
> This I believe makes it pretty clear that what is being discussed
> are events that are raised in the Windex Renderer and which need to
> be forwarded to the Widex Server as WO.Event messages. The bullet
> point suggests that one way for the Widex Server to indicate which
> such events it is interested in is via a list of events that is
> exchanged with the Widex Renderer at session establishment. Widex
> won't define the events, but it is within our scope to define a
> mechanism for passing a list of event names as part of session
> establishment for a binding to specific protocol. This is something
> we can now start talking about in more detail, but it would be
> good to first reach agreement on publishing the framework draft.

Ok, I see, the word "event" here indeed means "UI event". But it's not really
sending event, as in the WO.Event messages. Here, we are talking about
exchanging a list of event names. So maybe change it to "a list of event names"?

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 20 07:42:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FsedF-0002ZR-Av; Tue, 20 Jun 2006 07:42:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FsedE-0002ZB-Qi
	for widex@ietf.org; Tue, 20 Jun 2006 07:42:56 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsbua-0002GH-5i
	for widex@ietf.org; Tue, 20 Jun 2006 04:48:40 -0400
Received: from homer.w3.org ([128.30.52.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsboO-0002on-F7
	for widex@ietf.org; Tue, 20 Jun 2006 04:42:19 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 62D334F0C8;
	Tue, 20 Jun 2006 04:42:15 -0400 (EDT)
Date: Tue, 20 Jun 2006 09:42:08 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Jin Yu <jyu@openxup.org>
Subject: RE: [Widex] Proposed rewording for Framework draft
In-Reply-To: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
Message-ID: <Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 19 Jun 2006, Jin Yu wrote:

>> The bullet point needs to be read in the context of the preceding
>> paragraph:
>>
>>   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
>>
>> This I believe makes it pretty clear that what is being discussed
>> are events that are raised in the Windex Renderer and which need to
>> be forwarded to the Widex Server as WO.Event messages. The bullet
>> point suggests that one way for the Widex Server to indicate which
>> such events it is interested in is via a list of events that is
>> exchanged with the Widex Renderer at session establishment. Widex
>> won't define the events, but it is within our scope to define a
>> mechanism for passing a list of event names as part of session
>> establishment for a binding to specific protocol. This is something
>> we can now start talking about in more detail, but it would be
>> good to first reach agreement on publishing the framework draft.
>
> Ok, I see, the word "event" here indeed means "UI event". But it's 
> not really sending event, as in the WO.Event messages. Here, we 
> are talking about exchanging a list of event names. So maybe 
> change it to "a list of event names"?

Yes, saying "event names" would be fine.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEl7Tmb3AdEmxAsUsRAp7vAJ97Yg167n34bXDKrbUdaP9ssSY8DwCg56am
cMNDM668BPU3TWqEFEQyS5c=
=DdaO
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 20 23:30:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FstPj-00051N-HI; Tue, 20 Jun 2006 23:29:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FstPi-00051F-CS
	for widex@ietf.org; Tue, 20 Jun 2006 23:29:58 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FstPe-0008TU-1S
	for widex@ietf.org; Tue, 20 Jun 2006 23:29:58 -0400
Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5L3VFST024421
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <widex@ietf.org>; Tue, 20 Jun 2006 22:31:26 -0500
Mime-Version: 1.0 (Apple Message framework v750)
Content-Transfer-Encoding: 7bit
Message-Id: <A5178513-BE5C-41AC-A6DB-5D1B8CE68CFB@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: widex@ietf.org
From: Dean Willis <dean.willis@softarmor.com>
Date: Tue, 20 Jun 2006 22:29:39 -0500
X-Mailer: Apple Mail (2.750)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Widex] Are we really done with the requirements draft?
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

I see Rosfran's open questions on the requirements draft were  
resolved by the latest rev.

I've seen no discussion since.

So a poll -- those of you who have read the draft and thing it's good  
to go to the IESG, please respond affirmatively. And those who think  
otherwise, please respond negatively. Those of you who don't care,  
please continue what you were doing.

Note that this isn't a vote. It's a tool for estimating rough consensus.

--
Dean, the consensunator.



_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 21 20:19:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FtCux-0000k0-6C; Wed, 21 Jun 2006 20:19:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCuv-0000do-SO
	for widex@ietf.org; Wed, 21 Jun 2006 20:19:29 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCuu-0001o5-EC
	for widex@ietf.org; Wed, 21 Jun 2006 20:19:29 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5M0JQ5Z025708; Thu, 22 Jun 2006 03:19:27 +0300
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Jun 2006 03:19:26 +0300
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Jun 2006 19:19:24 -0500
Received: from [172.19.141.56] ([172.19.141.56]) by daebe102.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Jun 2006 19:19:22 -0500
Message-ID: <4499DFF1.7070603@indt.org.br>
Date: Wed, 21 Jun 2006 21:10:25 -0300
From: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Organization: INdT/Recife
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Dave Raggett <dsr@w3.org>
Subject: Re: [Widex] Proposed rewording for Framework draft
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
	<Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jun 2006 00:19:22.0958 (UTC)
	FILETIME=[83238EE0:01C69591]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org


     After reading all the recent discussions, and reviewing again the 
Widex framework draft, I would like to suggest a better rephrasing to 
the last paragraph from section 4.2:

"4.2.  WO.Event Message

    The WO.Event messages are primarily used to carry events triggered on
  (...)
    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]."


Would changes to:

    "Note: Some UI markup languages, e.g.  Glade [1], which are 
originally designed for only working with standalone UI architectures 
(i.e., that doesn't implements a networked MVC, where we have a 
change-propagation mechanism that ensures consistency between 
remotelly-located user interface and model), and do not have a defined 
syntax for event modeling (at least, not at document level), this kind 
of UI event was not originally made to be carried as a string of bits 
through the network. So, when using Widex with these applications, the 
WO.Event messages MUST be able to serialize the events (where "events" 
would means "GTK+ signals") emitted by its associated UI libraries, e.g. 
GTK+ [2]."


-- 
Rosfran Borges

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Thu Jun 22 12:01:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FtRcp-000261-UB; Thu, 22 Jun 2006 12:01:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRco-00025w-M2
	for widex@ietf.org; Thu, 22 Jun 2006 12:01:46 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRcn-0006E5-FR
	for widex@ietf.org; Thu, 22 Jun 2006 12:01:46 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 57FCC4EED1;
	Thu, 22 Jun 2006 12:01:44 -0400 (EDT)
Date: Thu, 22 Jun 2006 17:01:41 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Subject: Re: [Widex] Proposed rewording for Framework draft
In-Reply-To: <4499DFF1.7070603@indt.org.br>
Message-ID: <Pine.LNX.4.62.0606221658150.9424@localhost.localdomain>
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
	<Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
	<4499DFF1.7070603@indt.org.br>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 21 Jun 2006, Rosfran Lins Borges wrote:

>
>    After reading all the recent discussions, and reviewing again the Widex 
> framework draft, I would like to suggest a better rephrasing to the last 
> paragraph from section 4.2:
>
> "4.2.  WO.Event Message
>
>   The WO.Event messages are primarily used to carry events triggered on
> (...)
>   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]."
>
>
> Would changes to:
>
>   "Note: Some UI markup languages, e.g.  Glade [1], which are 
> originally designed for only working with standalone UI 
> architectures (i.e., that doesn't implements a networked MVC, 
> where we have a change-propagation mechanism that ensures 
> consistency between remotelly-located user interface and model), 
> and do not have a defined syntax for event modeling (at least, not 
> at document level), this kind of UI event was not originally made 
> to be carried as a string of bits through the network. So, when 
> using Widex with these applications, the WO.Event messages MUST be 
> able to serialize the events (where "events" would means "GTK+ 
> signals") emitted by its associated UI libraries, e.g. GTK+ [2]."

I think I get your intention, but the wording you suggest is a 
little hard to read with all the bracketed clauses.


  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEmr7qb3AdEmxAsUsRAqsEAJ9WU+KwFjFq+cLrY59+i53E2IAAZQCfUtnF
hlUOBG1uimF4fN6efqFTGjk=
=LTdT
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 23 09:54:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ftm7f-0004wG-3q; Fri, 23 Jun 2006 09:54:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftm7d-0004wB-8J
	for widex@ietf.org; Fri, 23 Jun 2006 09:54:57 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftm7b-0007GK-PC
	for widex@ietf.org; Fri, 23 Jun 2006 09:54:57 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5NDsp1X022605; Fri, 23 Jun 2006 16:54:54 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Jun 2006 16:54:52 +0300
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Jun 2006 08:54:46 -0500
Received: from [172.19.141.56] ([172.19.141.56]) by daebe102.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Jun 2006 08:54:46 -0500
Message-ID: <449BF07F.30805@indt.org.br>
Date: Fri, 23 Jun 2006 10:45:35 -0300
From: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Organization: INdT/Recife
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Dave Raggett <dsr@w3.org>
Subject: Re: [Widex] Proposed rewording for Framework draft
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
	<Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
	<4499DFF1.7070603@indt.org.br>
	<Pine.LNX.4.62.0606221658150.9424@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.62.0606221658150.9424@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2006 13:54:46.0417 (UTC)
	FILETIME=[9634B810:01C696CC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org



    Maybe I'm worried too much, because I had been supposing a reader of 
this draft that may possibly knows nothing about Glade XML schema and/or 
GTK+ "signals and slots" event model. I hope it is more concise now:

    "Note: Some UI markup languages, e.g.  Glade [1], which are designed 
only for standalone UI architectures (e.g., doesn't have a 
change-propagation mechanism, defined at document level, which ensures 
consistency between remotelly-located user interface and model), 
originally cannot sends these UI events as a string of bits through the 
network. So, when using Widex with this kind of UI event model, the 
WO.Event messages MUST be able to serialize the events (e.g. GTK+ 
signals) emitted by its associated UI libraries, e.g. GTK+ [2]."

--
Rosfran Borges

ext Dave Raggett wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 21 Jun 2006, Rosfran Lins Borges wrote:
> 
>>
>>    After reading all the recent discussions, and reviewing again the 
>> Widex framework draft, I would like to suggest a better rephrasing to 
>> the last paragraph from section 4.2:
>>
>> "4.2.  WO.Event Message
>>
>>   The WO.Event messages are primarily used to carry events triggered on
>> (...)
>>   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]."
>>
>>
>> Would changes to:
>>
>>   "Note: Some UI markup languages, e.g.  Glade [1], which are 
>> originally designed for only working with standalone UI architectures 
>> (i.e., that doesn't implements a networked MVC, where we have a 
>> change-propagation mechanism that ensures consistency between 
>> remotelly-located user interface and model), and do not have a defined 
>> syntax for event modeling (at least, not at document level), this kind 
>> of UI event was not originally made to be carried as a string of bits 
>> through the network. So, when using Widex with these applications, the 
>> WO.Event messages MUST be able to serialize the events (where "events" 
>> would means "GTK+ signals") emitted by its associated UI libraries, 
>> e.g. GTK+ [2]."
> 
> 
> I think I get your intention, but the wording you suggest is a little 
> hard to read with all the bracketed clauses.
> 
> 
>  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
>  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFEmr7qb3AdEmxAsUsRAqsEAJ9WU+KwFjFq+cLrY59+i53E2IAAZQCfUtnF
> hlUOBG1uimF4fN6efqFTGjk=
> =LTdT
> -----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Fri Jun 23 13:07:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ftp7q-0005sv-Uf; Fri, 23 Jun 2006 13:07:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftp7q-0005sq-Ek
	for widex@ietf.org; Fri, 23 Jun 2006 13:07:22 -0400
Received: from homer.w3.org ([128.30.52.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftp7o-00060U-60
	for widex@ietf.org; Fri, 23 Jun 2006 13:07:22 -0400
Received: from localhost (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 24ED04EFDE;
	Fri, 23 Jun 2006 13:07:18 -0400 (EDT)
Date: Fri, 23 Jun 2006 18:07:12 +0100 (BST)
From: Dave Raggett <dsr@w3.org>
X-X-Sender: dsr@localhost.localdomain
To: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Subject: Re: [Widex] Proposed rewording for Framework draft
In-Reply-To: <449BF07F.30805@indt.org.br>
Message-ID: <Pine.LNX.4.62.0606231731520.8578@localhost.localdomain>
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
	<Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
	<4499DFF1.7070603@indt.org.br>
	<Pine.LNX.4.62.0606221658150.9424@localhost.localdomain>
	<449BF07F.30805@indt.org.br>
X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Jun 2006, Rosfran Lins Borges wrote:

>  Maybe I'm worried too much, because I had been supposing a reader 
> of this draft that may possibly knows nothing about Glade XML 
> schema and/or GTK+ "signals and slots" event model. I hope it is 
> more concise now:
>
>  "Note: Some UI markup languages, e.g.  Glade [1], which are 
> designed only for standalone UI architectures (e.g., doesn't have 
> a change-propagation mechanism, defined at document level, which 
> ensures consistency between remotelly-located user interface and 
> model), originally cannot sends these UI events as a string of 
> bits through the network. So, when using Widex with this kind of 
> UI event model, the WO.Event messages MUST be able to serialize 
> the events (e.g. GTK+ signals) emitted by its associated UI 
> libraries, e.g. GTK+ [2]."

Although I am a native English speaker, I still have difficulty
in understanding the above. Here is my attempt to explain this
based upon reading the web pages describing GLADE:

  Note: some UI markup languages don't make use of XML DOM events.
  An example is Glade [1], which is a user interface builder for
  GTK+ [2]. Glade generates XML files that describe the user
  interface. These files are interpreted by libGlade [3] to build
  the user interface at runtime. To use Glade and GTK+ with Widex,
  the WO.Event messages MUST be able to  serialize the GTK+ signals
  that act as UI events, and which are raised by the associated
  GTK+ UI libraries.


[1] http://glade.gnome.org/
[2] http://www.gtk.org/
[3] http://www.jamesh.id.au/software/libglade/


  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEnB/Hb3AdEmxAsUsRAlWSAJ9QZqLsLEIDIJox0rPGoHNYorZBTQCfUzl5
0einBkIkprtQs2JB4ZUZ9Po=
=5GhN
-----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Tue Jun 27 00:41:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fv5Og-0001gE-Cu; Tue, 27 Jun 2006 00:41:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv5Of-0001g9-W0
	for widex@ietf.org; Tue, 27 Jun 2006 00:41:58 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv5Oe-0007gu-M3
	for widex@ietf.org; Tue, 27 Jun 2006 00:41:57 -0400
Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be
	forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5R4hXbq021425
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <widex@ietf.org>; Mon, 26 Jun 2006 23:43:34 -0500
Mime-Version: 1.0 (Apple Message framework v750)
Content-Transfer-Encoding: 7bit
Message-Id: <75B7516F-70CA-415D-8021-EFEE6F5BC7E9@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: widex@ietf.org
From: Dean Willis <dean.willis@softarmor.com>
Date: Mon, 26 Jun 2006 23:41:53 -0500
X-Mailer: Apple Mail (2.750)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Widex] Revised agenda for IETF 66
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

I've posted a revised agenda at:

http://www.softarmor.com/widex/meets/ietf66/agenda.html

Text follows. Please provide feedback on list.


Draft Agenda for WIDEX at IETF 66
Monday, July 10 2006 1740-1950 Room 519B

1740 	Agenda Bash 	
	Chairs
1745 	Requirements Draft 	
	Vlad Stirbu 	
	draft-ietf-widex-requirements-02
1800 	Framework Draft
	Vlad Stirbu
	draft-stirbu-widex-framework-01
1835 	BEEP bindings
	Vlad Stribu
	draft-stirbu-widex-beep-00.txt
1855 	REX
	Dave Raggett
	None
1915 	HTTP Bindings
	Dave Raggett
	None
1935 	SIP Bindings
	TBD
	None

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 28 19:42:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FvjgH-0006ba-Qv; Wed, 28 Jun 2006 19:42:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjgE-0006X8-H6
	for widex@ietf.org; Wed, 28 Jun 2006 19:42:46 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvjgA-0000ML-0Y
	for widex@ietf.org; Wed, 28 Jun 2006 19:42:46 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5SNgd8L019004; Thu, 29 Jun 2006 02:42:40 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Jun 2006 02:42:40 +0300
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Jun 2006 18:42:38 -0500
Received: from [172.19.141.56] ([172.19.141.56]) by daebe102.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Jun 2006 18:42:37 -0500
Message-ID: <44A3125A.4080505@indt.org.br>
Date: Wed, 28 Jun 2006 20:35:54 -0300
From: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Organization: INdT/Recife
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Dave Raggett <dsr@w3.org>
Subject: Re: [Widex] Proposed rewording for Framework draft
References: <000901c69414$f052c1d0$1e02a8c0@martsbs.local>
	<Pine.LNX.4.62.0606200940170.8780@localhost.localdomain>
	<4499DFF1.7070603@indt.org.br>
	<Pine.LNX.4.62.0606221658150.9424@localhost.localdomain>
	<449BF07F.30805@indt.org.br>
	<Pine.LNX.4.62.0606231731520.8578@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.62.0606231731520.8578@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2006 23:42:38.0075 (UTC)
	FILETIME=[89D15CB0:01C69B0C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Vlad.Stirbu@nokia.com, widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org


    It's a lot cleaner and concise now, you really got the idea on my 
unsuccessfull GTK+ and Glade explanations! Thanks for the good input...

-- 
Rosfran Borges

ext Dave Raggett wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 23 Jun 2006, Rosfran Lins Borges wrote:
> 
>>  Maybe I'm worried too much, because I had been supposing a reader of 
>> this draft that may possibly knows nothing about Glade XML schema 
>> and/or GTK+ "signals and slots" event model. I hope it is more concise 
>> now:
>>
>>  "Note: Some UI markup languages, e.g.  Glade [1], which are designed 
>> only for standalone UI architectures (e.g., doesn't have a 
>> change-propagation mechanism, defined at document level, which ensures 
>> consistency between remotelly-located user interface and model), 
>> originally cannot sends these UI events as a string of bits through 
>> the network. So, when using Widex with this kind of UI event model, 
>> the WO.Event messages MUST be able to serialize the events (e.g. GTK+ 
>> signals) emitted by its associated UI libraries, e.g. GTK+ [2]."
> 
> 
> Although I am a native English speaker, I still have difficulty
> in understanding the above. Here is my attempt to explain this
> based upon reading the web pages describing GLADE:
> 
>  Note: some UI markup languages don't make use of XML DOM events.
>  An example is Glade [1], which is a user interface builder for
>  GTK+ [2]. Glade generates XML files that describe the user
>  interface. These files are interpreted by libGlade [3] to build
>  the user interface at runtime. To use Glade and GTK+ with Widex,
>  the WO.Event messages MUST be able to  serialize the GTK+ signals
>  that act as UI events, and which are raised by the associated
>  GTK+ UI libraries.
> 
> 
> [1] http://glade.gnome.org/
> [2] http://www.gtk.org/
> [3] http://www.jamesh.id.au/software/libglade/
> 
> 
>  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
>  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFEnB/Hb3AdEmxAsUsRAlWSAJ9QZqLsLEIDIJox0rPGoHNYorZBTQCfUzl5
> 0einBkIkprtQs2JB4ZUZ9Po=
> =5GhN
> -----END PGP SIGNATURE-----

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Wed Jun 28 19:47:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fvjki-0002XG-JW; Wed, 28 Jun 2006 19:47:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvjkh-0002W1-Ol
	for widex@ietf.org; Wed, 28 Jun 2006 19:47:23 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjkg-0001X9-8I
	for widex@ietf.org; Wed, 28 Jun 2006 19:47:23 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k5SNlHXm010987; Thu, 29 Jun 2006 02:47:21 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Jun 2006 02:47:18 +0300
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by
	daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Jun 2006 18:47:10 -0500
Received: from [172.19.141.56] ([172.19.141.56]) by daebe102.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Jun 2006 18:47:09 -0500
Message-ID: <44A31374.109@indt.org.br>
Date: Wed, 28 Jun 2006 20:40:36 -0300
From: Rosfran Lins Borges <rosfran.borges@indt.org.br>
Organization: INdT/Recife
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Widex] Revised agenda for IETF 66
References: <75B7516F-70CA-415D-8021-EFEE6F5BC7E9@softarmor.com>
In-Reply-To: <75B7516F-70CA-415D-8021-EFEE6F5BC7E9@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2006 23:47:09.0939 (UTC)
	FILETIME=[2BDC8430:01C69B0D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org


     There is a broken link in the web site, related with the IETF draft 
on Widex Framework meeting (1800) - it's referring to an expired version 
(01), and not the newer (version 2).

-- 
Rosfran Lins Borges

ext Dean Willis wrote:
> I've posted a revised agenda at:
> 
> http://www.softarmor.com/widex/meets/ietf66/agenda.html
> 
> Text follows. Please provide feedback on list.
> 
> 
> Draft Agenda for WIDEX at IETF 66
> Monday, July 10 2006 1740-1950 Room 519B
> 
> 1740     Agenda Bash    
>     Chairs
> 1745     Requirements Draft    
>     Vlad Stirbu    
>     draft-ietf-widex-requirements-02
> 1800     Framework Draft
>     Vlad Stirbu
>     draft-stirbu-widex-framework-01
> 1835     BEEP bindings
>     Vlad Stribu
>     draft-stirbu-widex-beep-00.txt
> 1855     REX
>     Dave Raggett
>     None
> 1915     HTTP Bindings
>     Dave Raggett
>     None
> 1935     SIP Bindings
>     TBD
>     None
> 
> _______________________________________________
> Widex mailing list
> Widex@ietf.org
> https://www1.ietf.org/mailman/listinfo/widex


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex



From widex-bounces@ietf.org Thu Jun 29 18:15:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fw4nI-0007VH-Sy; Thu, 29 Jun 2006 18:15:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4nI-0007T1-Cn
	for widex@ietf.org; Thu, 29 Jun 2006 18:15:28 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3kh-0004Xn-UN
	for widex@ietf.org; Thu, 29 Jun 2006 17:08:43 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw3Yn-0007ZT-9t
	for widex@ietf.org; Thu, 29 Jun 2006 16:56:26 -0400
Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be
	forged)) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5TKvlNd005630
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 29 Jun 2006 15:57:57 -0500
In-Reply-To: <44A31374.109@indt.org.br>
References: <75B7516F-70CA-415D-8021-EFEE6F5BC7E9@softarmor.com>
	<44A31374.109@indt.org.br>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0C4B3F9F-A54B-4BE6-AB47-9229D50F4C07@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Widex] Revised agenda for IETF 66
Date: Thu, 29 Jun 2006 15:56:03 -0500
To: Rosfran Lins Borges <rosfran.borges@indt.org.br>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: widex@ietf.org
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF  <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>,
	<mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org


On Jun 28, 2006, at 6:40 PM, Rosfran Lins Borges wrote:

>
>     There is a broken link in the web site, related with the IETF  
> draft on Widex Framework meeting (1800) - it's referring to an  
> expired version (01), and not the newer (version 2).
>

Thanks. That should now be fixed.

--
dean

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex