[Standards] Shared Editing

Jonathan Chayce Dickinson chayce.za at gmail.com
Thu Aug 30 10:51:51 UTC 2007

Joonas Govenius wrote:
> On 8/29/07, Jonathan Chayce Dickinson <chayce.za at gmail.com> wrote:
>> Joonas Govenius wrote:
>>> Right, we could do that. It's just another way of refering to the
>>> elements. I just think it's easier to require each element to have a
>>> unique id so we don't need to adjust references to elements like that
>>> when simultaneous changes are made.
>> The problem is that by using LUIDs is that you can't merge the diffs.
>> *If* you can sort out the concurrency issues using another method, LUIDs
>> are better than indexing: they are simpler and probably faster. But I
>> just can't scratch my brain for getting it to work with LUIDs.
> The problems can be solved by giving each node a "weight" (which I
> currently call the Z value) according to which the child nodes of a
> given element are arranged. The remaining problem is how to you store
> the GUID and the "weight". You can store them as attributes in the
> case of elements but what about text nodes? Suggestions on that would
> be greatly appreciated.

Text nodes are going to have to require seperate markup along the lines 
of the output of classical binary diff algorithm output.

<configure target='18/kingclaudius at shakespeare.lit/castle'
           <insert at="100"><b>foo</b></insert>
           <remove at="20" length="20"></remove>
           <insert at="20">bar</insert>
	<remove-attribute name='font'/>

Note that a edit equates to a remove/insert operation, including it is 
redundant IMHO. So for text nodes all you need is insert/remove, as 

  Jonathan Dickinson

> Joonas

jonathan chayce dickinson
ruby/c# developer

email:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070830/6f300233/attachment.bin>

More information about the Standards mailing list