I still have the same two questions/comments:
1.
The application needs a little intelligence about what to provide the user after future actions.
2.
Leaving aside #1, how is “any two changes that affect one 'bucket' can only be rejected correctly in the reverse
order” any different between ECT and GCT?
1. Runtime behavior
I think runtime behavior may be conflated with storage format. The storage format needs to provide the means for applications to store the information necessary
to preserve the state of the document, which may also include information about how it got where it is. The application may manipulate the stored data as needed to achieve this – the data itself does not need to be seen as rigidly unchanging.
One critical question an application needs to consider is what it means (to the user) to record and arbitrarily reject multiple changes made to the same piece
of content. This is an application issue, not a file format issue. From the discussions within the SC, it seems clear to me that there is no good answer, correct 100% of the time, for what should happen when an interim change is rejected. We need to provide
applications with the tools needed to get done whatever job they choose, not to ensure that data written at some point in time remains static yet also correct for any future action a user might take.
This example came up in the old “Serialization and change tracking” thread I mentioned yesterday. If I replicate UC 1 in MS Word, when I make the second change,
it splits the first change into separate changes and makes the middle change a combined change to formatting. This seems to me a reasonable reaction to the fairly unclear situation of how to handle multiple overlapping changes. Now it’s clear to the user
what will be undone if any of these three changes are rejected. It may or may not be what I want in this case, but the application made a choice that it can apply to any such situation and make it unambiguous to the user what will happen if they reject changes.
OpenOffice takes a different approach. It combines all the formatting changes made to the word “bold” into a single change record. (This is probably largely
due to the current limitations around change tracking and formatting in ODF.) Again, it may or may not be what I want, but it’s a reasonable choice, one that can be applied uniformly and one that leaves the user clear on what they will get if they reject
the change. If you try a variant of UC 1 that ODF 1.1/1.2 handles more robustly, such as deleting some text and adding new text in the middle of the deleted text, OpenOffice does the same thing Word does above – the deletion change is split into two changes.
My point here is that we can’t anticipate every user action and application choice in the file format. If an app chooses to leave the cached change data static
and let the user get certain (perhaps unanticipated) results, it gets to make that choice. Another app might choose to fiddle with the cached data in such a way that reflects custom smarts about rejecting interim changes in order to let the user subsequently
reject a later change and get some specific result. (Example: The app might record the change differently such that the second change the user made was “underline these letters” rather than “apply a non-bold underline style to these letters”. Or it might
dynamically analyze the change stack and decide that there are similar adjacent changes and rejecting one should restore bold to the whole word with affecting the underline.) Yet another app may decide this is an edge case for users and do one of the options
above. So, I don’t see how providing the ability to cache state limits what the user can do.
2. GCT & ECT
First, let me make clear that I ask this to better understand this claimed difference, because I don’t see it. My intent is not to turn around a question about
ECT and cut down GCT. Taking the “Proposal 2” markup from GCT-style-change-response.odt, if change ct1 is rejected, depending on what the application does with the remaining ct2 markup, wouldn’t that result in either (A) dropping ct2 also or (B) keeping the
text:span around the “ol” in “bold” with an out-of-sync ct2 cached state? It looks to me like the same situation where a little runtime intelligence is required to handle this in a particular way. (A) might be clear and may be desirable, but it implicitly
rejects all other changes after ct1, so the user can’t keep the underlined “ol”. (B) leaves an unexpected format state (NormalStyle) waiting when the user rejects ct2. Assuming I have the GCT behavior correct:
Starting markup
<text:p
text:style-name="BoldStyle">Remove
<text:span
text:style-name="NormalStyle"
ac:change001="ct1,add,text:style-name">b</text:span>
<text:span
text:style-name="UlNormalStyle"
ac:change001="ct1,add,text:style-name"
ac:change002="ct2,modify,text:style-name,NormalStyle">ol</text:span>
<text:span
text:style-name="NormalStyle"
ac:change001="ct1,add,text:style-name">d</text:span>
</text:p>
(A) Rejecting ct1 reverts the “add” and removes the middle text:span
<text:p
text:style-name="BoldStyle">Remove
bold</text:p>
-->
Remove bold (not: Remove bold)
(B) Rejecting ct1 without implicitly dropping ct2 leaves a text:span which, if ct2 is later rejected, will revert the “ol” to NormalStyle
<text:p
text:style-name="BoldStyle">Remove
b
<text:span
ac:change002="ct2,modify,text:style-name,NormalStyle">ol</text:span>
d
</text:p>
-->
Remove bold (but after rejecting ct2: Remove bold)
Does that make sense or did I leave something insufficiently described? I apologize for the length of the above, but I wanted to make my thinking as clear
as I could. If it’s not, everyone will have a wait a while for me catch up on e-mail after I get back from vacation.
J
John
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Friday, September 09, 2011 9:36 AM
To: office-collab@lists.oasis-open.org
Subject: [office-collab] Arbitrary order rejection (was Notes on Conference call to discuss use case solutions UC4-UC8)
On 09/09/2011 01:38, John Haug wrote:
If there are any specific problems with ECT, I'd love to have the details as both Doug and I noted early on that we think arbitrary order rejection is important to users.
I believe the issue can be illustrated in the example below.
Doc-v0:
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal"/>
</style:style>
Doc-v1:
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
</style:style>
Doc-v2:
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="bold" fo:font-style="italic"/>
</style:style>
Change 1 (doc-v0 to doc-v1) adds fo:font-style="italic" and so caches
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal"/>
</style:style>
and has:
<ct:format-change-start ct:id="1"/>
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
</style:style>
<ct:format-change-end ct:id="1"/>
Change 2 (doc-v1 to doc-v2) changes fo:font-weight="normal" to fo:font-weight="bold" and so caches
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
</style:style>
and has:
<ct:format-change-start ct:id="2"/>
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="bold" fo:font-style="italic"/>
</style:style>
<ct:format-change-end ct:id="2"/>
Then if you reject 2 then reject 1 it works OK, but reject 1 then reject 2 would result in:
<style:style style:name="Style1" style:family="paragraph">
<style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
</style:style>
which is incorrect because fo:font-style="italic" remains there although change 1 has been rejected.
I believe the situation is that for ECT any two changes that affect one 'bucket' can only be rejected correctly in the reverse order, i.e. if the last change is rejected first. Of course a user does not know anything about buckets so this may lead to confusing
behaviour. This is one reason for my opinion that recording changes to attributes is important.
Robin
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php