Comment on REX 1.0: adding sequence management

Hi,

  Reading REX 1.0 public draft 02 [1], the spec is
well defined and can see that this covers many use
cases. Maybe adding small optional attributes in 'rex'
element may helpful under broadcast/multicast
environment. Suggested optional attributes are:

1) Sequence number of REX messages
2) Specifying a REX message that shall be processed
   prior to the REX message just has been received.

  The first feature might look as follows:

<rex xmlns='http://www.w3.org/2006/rex' seq=1>
	<!-- initial document -->
</rex>

  The REX message above set 'seq' attribute. The value
of 'seq' attribute is incremented for new REX message.
However it is legitimate to transmit the same REX
message with the same 'seq' value. In this case, if
the receiver already has received the message, it can
ignore the message. The receiver only receives and
processes the REX messages that has 'seq' value that
is larger than the one the receiver has received
previously. This is useful when the network is
non-reliable (i.e. mutlicast, broadcast) where
transmitter may automatically repeat transmission of
the REX messages for better reliability.

  The second feature might look as follows:

<rex xmlns='http://www.w3.org/2006/rex' target=1 seq=2>
	<!-- update to the REX message seq=1 -->
</rex>

  Let's say if you want to use REX to update SVG cartoon
under multicast environment or broadcast environment.
You need to transmit key frames and updates to let any
receiver to tune in any time. MPEG used in digital
broadcast does it to realize good compression rate, random
access and arbitrary tune-in at the sametime. So, in
this case, the REX message could be transmitted like:

  1) REX message seq=1: creating new document A
  2) REX message seq=2, target=1: update document A
  3) REX message seq=3, target=1: update document A
  4) REX message seq=4: creating new document B
  5) REX message seq=5, target=4: update document A
  6) REX message seq=6, target=4: update document A

If a reciver starts receiving the REX message from
seq=3, it will wait until it receive the REX message
seq=4. Because, it hasn't received the REX message
seq=1, it cannot process the REX message seq=3. The
REX message seq=4 is processed by every receiver as it
doesn't have 'target' attribute.

  The restriction to the 'target' attribute should be
carefully considered. Otherwise, it ends up requiring
to remember all received 'seq' values. Maybe one
resolution is that 'target' value shall be restricted
to the 'seq' value of the last REX message without
'target' attribute.

  This type of feature may already been discussed by
the group, if that's the case please ignore this.

[1] http://www.w3.org/TR/rex/
--
Takanari Hayama, Ph.D. (taki@igel.co.jp)
IGEL Co.,Ltd
http://www.igel.co.jp/

Received on Wednesday, 10 May 2006 18:28:20 UTC