[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Fwd: Change Tracking of Lists - Storing delete fragments
From:       Ganesh Paramasivam <ganesh () crystalfab ! com>
Date:       2010-03-26 4:58:25
Message-ID: 9ecf537e1003252157m4d580e4dl15948ba3181e8e6d () mail ! gmail ! com
[Download RAW message or body]

Forwarding this here for future reference.

- Ganesh

---------- Forwarded message ----------
From: Ganesh Paramasivam <ganesh@crystalfab.com>
Date: Fri, Mar 26, 2010 at 10:25 AM
Subject: Change Tracking of Lists - Storing delete fragments
To: office-comment@lists.oasis-open.org


Hi,

I'm currently implementing ODF change tracking in KWord, and there
doesn't seem to be a way to store delete changes in lists in a ODF
complaint way for some scenarios. For example, if we have a list like
this

1. This is a list-item-1
2. This is a list-item-2
3. This is a list-item-3
4. This is a list-item-4

And we delete the second-half of the first list-item and the first
half of the second list-item

1. This is a list-item-1
             -----------------
2. This is a list-item-2
-------------
3. This is a list-item-3
4. This is a list-item-4

If I were to follow the ODF delete change loading rules, we should
have a delete fragment which looks like this

<p>a list-item-1</p></list-item><list-item><p>This is a</p>

However, such a fragment would result in a invalid XML file and
consequently an invalid ODF File.

The KWord approach to solving this problem is that we store the delete
fragment like this

<list xml:id="list1"><list-item xml:id="list-item1"><p>a
list-item-1</p></list-item><list-item>This is a</list-item></list>

and use the RDF metadata to specify that "list1" and "list-item-1" are
not to be considered as a valid list and list-item respectively. So
while loading this delete-change, on encountering a list or a
list-item, we check whether it is a valid list or list-item and if
they are not valid we merge the delete change into the current list
and list-item respectively. This solution is very robust in handling
any type of list-delete changes ( There are multiple other scenarios
with similar problems that I haven't illustrated in this mail ).

We would like to see this problem addressed in the spec, so that we
can have a inter-operable way to do this.

Thanks,
Ganesh
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]