--===============1263893553==
Content-Type: multipart/alternative; boundary=001485f5cd9671e5870482b106f6

--001485f5cd9671e5870482b106f6
Content-Type: text/plain; charset=ISO-8859-1

On your example further down and on ODF shortcomings:
I am not sure these deletions should be stored as a list item at all. I
think that we should store a list-item only if the whole list item is
deleted.
Perhaps a way to handle them in current ODF is to store each of them as a
different deletion region with the <text:change> tags inside each
<list-item>.

Pierre


On Fri, Mar 26, 2010 at 5:57 AM, Ganesh Paramasivam
<ganesh@crystalfab.com>wrote:

> 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
>

--001485f5cd9671e5870482b106f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On your example further down and on ODF shortcomings:<br>I am not sure thes=
e deletions should be stored as a list item at all. I think that we should =
store a list-item only if the whole list item is deleted.<br>Perhaps a way =
to handle them in current ODF is to store each of them as a different delet=
ion region with the &lt;text:change&gt; tags inside each &lt;list-item&gt;.=
<br>
<br>Pierre<br><br><br><div class=3D"gmail_quote">On Fri, Mar 26, 2010 at 5:=
57 AM, Ganesh Paramasivam <span dir=3D"ltr">&lt;<a href=3D"mailto:ganesh@cr=
ystalfab.com">ganesh@crystalfab.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar=
gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Forwarding this here for future reference.<br>
<br>
- Ganesh<br>
<br>
---------- Forwarded message ----------<br>
From: Ganesh Paramasivam &lt;<a href=3D"mailto:ganesh@crystalfab.com">ganes=
h@crystalfab.com</a>&gt;<br>
Date: Fri, Mar 26, 2010 at 10:25 AM<br>
Subject: Change Tracking of Lists - Storing delete fragments<br>
To: <a href=3D"mailto:office-comment@lists.oasis-open.org">office-comment@l=
ists.oasis-open.org</a><br>
<br>
<br>
Hi,<br>
<br>
I&#39;m currently implementing ODF change tracking in KWord, and there<br>
doesn&#39;t seem to be a way to store delete changes in lists in a ODF<br>
complaint way for some scenarios. For example, if we have a list like<br>
this<br>
<br>
1. This is a list-item-1<br>
2. This is a list-item-2<br>
3. This is a list-item-3<br>
4. This is a list-item-4<br>
<br>
And we delete the second-half of the first list-item and the first<br>
half of the second list-item<br>
<br>
1. This is a list-item-1<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0-----------------<br>
2. This is a list-item-2<br>
-------------<br>
3. This is a list-item-3<br>
4. This is a list-item-4<br>
<br>
If I were to follow the ODF delete change loading rules, we should<br>
have a delete fragment which looks like this<br>
<br>
&lt;p&gt;a list-item-1&lt;/p&gt;&lt;/list-item&gt;&lt;list-item&gt;&lt;p&gt=
;This is a&lt;/p&gt;<br>
<br>
However, such a fragment would result in a invalid XML file and<br>
consequently an invalid ODF File.<br>
<br>
The KWord approach to solving this problem is that we store the delete<br>
fragment like this<br>
<br>
&lt;list xml:id=3D&quot;list1&quot;&gt;&lt;list-item xml:id=3D&quot;list-it=
em1&quot;&gt;&lt;p&gt;a<br>
list-item-1&lt;/p&gt;&lt;/list-item&gt;&lt;list-item&gt;This is a&lt;/list-=
item&gt;&lt;/list&gt;<br>
<br>
and use the RDF metadata to specify that &quot;list1&quot; and &quot;list-i=
tem-1&quot; are<br>
not to be considered as a valid list and list-item respectively. So<br>
while loading this delete-change, on encountering a list or a<br>
list-item, we check whether it is a valid list or list-item and if<br>
they are not valid we merge the delete change into the current list<br>
and list-item respectively. This solution is very robust in handling<br>
any type of list-delete changes ( There are multiple other scenarios<br>
with similar problems that I haven&#39;t illustrated in this mail ).<br>
<br>
We would like to see this problem addressed in the spec, so that we<br>
can have a inter-operable way to do this.<br>
<br>
Thanks,<br>
Ganesh<br>
_______________________________________________<br>
koffice-devel mailing list<br>
<a href=3D"mailto:koffice-devel@kde.org">koffice-devel@kde.org</a><br>
<a href=3D"https://mail.kde.org/mailman/listinfo/koffice-devel" target=3D"_=
blank">https://mail.kde.org/mailman/listinfo/koffice-devel</a><br>
</blockquote></div><br>

--001485f5cd9671e5870482b106f6--

--===============1263893553==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1263893553==--