Joonas Govenius wrote:
On 8/29/07, Jonathan Chayce Dickinson <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/castle'
version='1'>
<content>
<insert at="100"><b>foo</b></insert>
<remove at="20" length="20"></remove>
<insert at="20">bar</insert>
</content>
<remove-attribute name='font'/>
</configure>
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
demonstrated.
Regards, Jonathan Dickinson
Joonas
-- jonathan chayce dickinson ruby/c# developer email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] <some profound piece of wisdom>
smime.p7s
Description: S/MIME Cryptographic Signature
