[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Change Tracking of Lists - Storing delete fragments
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]