OpenDocument - Adv Document Collab SC

Expand all | Collapse all

Groups - Conference call to discuss use case solutions UC4-UC8 added

  • 1.  Groups - Conference call to discuss use case solutions UC4-UC8 added

    Posted 08-24-2011 14:21
      |   view attached
    NOTE this call half an hour later than normal!
    This is our second conference call on the Use Cases.
    We have GCT and ECT solutions for UC4, UC5, UC6
    GCT only for UC7 (John argues this type of change is not needed so no ECT solution, outside its scope and no easy extension), and GCT for UC8 (John: not sure if you have done UC8 but please let us know, apologies if I have missed this!) -- Robin LaFontaine Conference call to discuss use case solutions UC4-UC8 has been added by Robin LaFontaine Date: Tuesday, 06 September 2011 Time: 02:00pm - 03:00pm GMT Event Description: Participant Code: 84367726

    Access Numbers
    --------------------------
    USA Toll-Free: 888-426-6840
    USA Caller Paid: 215-861-6239

    Belgium: 0800-3-9022
    Canada: 888-426-6840
    China: 10-800-711-1071 (CHINA NETCOM GROUP USERS )
    China: 10-800-110-0996 (CHINA TELECOM SOUTH USERS)
    Finland: 0800-9-18357
    Germany: 0800-000-1018
    Netherlands: 0-800-363-6036
    Norway: 800-16771
    UK: 0800-368-0638

    Codes for other countries are listed here:

    https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=84367726&accessNumber=2158616239

    Press *6 to mute/unmute line

    Chat room for meeting is at: http://webconf.soaphub.org/conf/room/odf
    Agenda: The purpose of the call is to review the remaining use cases to see whether they hightlight any issues with either proposal.

    1. Roll call
    2. Discussion of each use case and ECT and GCT solutions to determine whether or not cases are properly represented and any advantages/disadvantages of each approach
    - UC4 GCT. Overlapping style changes
    - UC5 GCT. List Edit and Conversion to Paragraphs
    - UC6 GCT. Text Frame Modifications
    - UC7 Ben. Annotation change within a frame
    - UC8 Ben. Bookmarks and XML Node identity tracking with xml:id
    3. Next steps
    4. Any other business

    Minutes: View event details: http://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=31361 PLEASE NOTE: If the above link does not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. BEGIN:VCALENDAR
    METHOD:PUBLISH
    VERSION:2.0
    PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
    X-WR-CALNAME:My Calendar
    BEGIN:VEVENT
    CATEGORIES:MEETING
    STATUS:TENTATIVE
    DTSTAMP:20110824T000000Z
    DTSTART:20110906T140000Z
    DTEND:20110906T150000Z
    SEQUENCE:0
    SUMMARY:Conference call to discuss use case solutions UC4-UC8
    DESCRIPTION:Participant Code: 84367726

    Access
    Numbers
    --------------------------
    USA Toll-Free: 888-426-6840
    USA
    Caller Paid: 215-861-6239

    Belgium: 0800-3-9022
    Canada:
    888-426-6840
    China: 10-800-711-1071 (CHINA NETCOM GROUP USERS
    )
    China: 10-800-110-0996 (CHINA TELECOM SOUTH USERS)
    Finland:
    0800-9-18357
    Germany: 0800-000-1018
    Netherlands:
    0-800-363-6036
    Norway: 800-16771
    UK: 0800-368-0638

    Codes for
    other countries are listed
    here:

    https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=84367726&accessNumber=2158616239

    Press
    *6 to mute/unmute line

    Chat room for meeting is at:
    http://webconf.soaphub.org/conf/room/odf

    Group: OpenDocument -
    Advanced Document Collaboration SC
    Creator: Robin LaFontaine
    URL: http://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=31361
    UID: http://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=31361
    END:VEVENT
    END:VCALENDAR

    Attachment(s)

    ics
    ical_31361.ics   1 KB 1 version


  • 2.  RE: [office-collab] Groups - Conference call to discuss use case solutions UC4-UC8 added

    Posted 08-24-2011 15:23
    It's the day after a US Holiday too. I will still be on leave of absence on that date. - Dennis


  • 3.  RE: [office-collab] Groups - Conference call to discuss use casesolutions UC4-UC8 added

    Posted 08-25-2011 22:38
    > for UC8 (John: not sure if you have done UC8 but please let us know, apologies if I have missed this!)

    I didn't upload a separate doc since Ben's worked example looks fine to me. Perhaps one deletion action rather than two, but that really depends on what actions the theoretical user took.

    John




  • 4.  RE: [office-collab] Groups - Conference call to discuss use casesolutions UC4-UC8 added

    Posted 08-25-2011 23:10
    On Thu, 2011-08-25 at 22:37 +0000, John Haug wrote: > > for UC8 (John: not sure if you have done UC8 but please let us know, apologies if I have missed this!) > > I didn't upload a separate doc since Ben's worked example looks fine > to me. Perhaps one deletion action rather than two, but that really > depends on what actions the theoretical user took. > > John Hi, Could you please link to the worked example as I'm having trouble finding it.


  • 5.  RE: [office-collab] Groups - Conference call to discuss use casesolutions UC4-UC8 added

    Posted 08-25-2011 23:51
    It's the case using bookmarks and xml:id - http://www.oasis-open.org/apps/org/workgroup/office-collab/document.php?document_id=42989 .

    John




  • 6.  RE: [office-collab] Groups - Conference call to discuss use casesolutions UC4-UC8 added

    Posted 08-26-2011 00:58
    On Thu, 2011-08-25 at 23:50 +0000, John Haug wrote: > It's the case using bookmarks and xml:id - > http://www.oasis-open.org/apps/org/workgroup/office-collab/document.php?document_id=42989 . > > John I should also mention that this bookmark example leaves open what happens if the start tag is in a different bucket than the end tag. This happens in UC7 for annotations which can use different start and end XML elements to indicate their scope. If as cited from earlier in this thread regarding UC7: "John argues this type of change is not needed so no ECT solution, outside its scope and no easy extension" Then we should make it overt which start/end grouped tags are forbidden if/when buckets are in use. > >


  • 7.  Cut (or deletion) of a selection with metadata (earlier - Re: [office-collab]Groups - Conference call to discuss use case solutions UC4-UC8 added)

    Posted 08-26-2011 10:17
    On 26.08.2011 02:57, monkeyiq wrote: > On Thu, 2011-08-25 at 23:50 +0000, John Haug wrote: >> It's the case using bookmarks and xml:id - >> http://www.oasis-open.org/apps/org/workgroup/office-collab/document.php?document_id=42989 . >> >> John > I should also mention that this bookmark example leaves open what > happens if the start tag is in a different bucket than the end tag. This > happens in UC7 for annotations which can use different start and end XML > elements to indicate their scope. > > If as cited from earlier in this thread regarding UC7: > "John argues this type of change is not needed > so no ECT solution, outside its scope and > no easy extension" > > Then we should make it overt which start/end grouped tags are forbidden > if/when buckets are in use. > > @Ben: I can not follow you on the above scenario. Why does grouped start/end tags have to be forbidden? @all: Allow me to give some general remarks on selections with metadata (bookmarks/annotations/styles/etc.). We should be aware that there are in two types of metadata on selections: breakable & unbreakable Selections with breakable metadata will remain valid after the change of the selection (change of its content). A typical example for "breakable selection with metadata" are styles. If there is a style on some text portion and we cut half of of the text, the style remains. Another example is adding the author of a text selection as metadata. If half of the text was cut, the other half was still written by the author. The metadata is still valid, when parts were deleted. Selections with unbreakable selection with metadata will remain valid after a change of the selection. A typical example for "unbreakable selection with metadata" is a telefone number, date of birth, etc. If the selection is cut into half, or the selection was changed in general the metadata is invalid - at least the user should be getting a notice (be questioned) from the application. Unless the metadata is being differentiated by some destinct ODF XML (as styles of selections with metadata have their own ODF XML are always known to be breakable), the application simply does not know if it is allowed to split selection with metadata or not. What does this means for annotations and bookmarks? The correct application behavior is unspecified. We might assume as a heuristic always breakable metadata, similar as styles. In this case if only a single start/end tag was within in a selection that had been removed (or cut/pasted), the application has to move this tag out of the cut/deleted selection. Basically the start/end tag(s) remains at the same position while the rest was moved/deleted. Do we all agree on the above basic view on ODF requirements? PS: Unfortuantely the awareness of the above problem came just after the specification of the first milestone of metadata for ODF, otherwise I would have suggested the introduction of a RDF property to mark if a selection of metadata can be changed. Svante


  • 8.  Re: [office-collab] Cut (or deletion) of a selection with metadata (earlier - Re: [office-collab] Groups - Conference call to discuss usecase solutions UC4-UC8 added)

    Posted 08-26-2011 21:43
    On Fri, 2011-08-26 at 12:16 +0200, Svante Schubert wrote: > On 26.08.2011 02:57, monkeyiq wrote: > > On Thu, 2011-08-25 at 23:50 +0000, John Haug wrote: > >> It's the case using bookmarks and xml:id - > >> http://www.oasis-open.org/apps/org/workgroup/office-collab/document.php?document_id=42989 . > >> > >> John > > I should also mention that this bookmark example leaves open what > > happens if the start tag is in a different bucket than the end tag. This > > happens in UC7 for annotations which can use different start and end XML > > elements to indicate their scope. > > > > If as cited from earlier in this thread regarding UC7: > > "John argues this type of change is not needed > > so no ECT solution, outside its scope and > > no easy extension" > > > > Then we should make it overt which start/end grouped tags are forbidden > > if/when buckets are in use. > > > > > @Ben: I can not follow you on the above scenario. Why does grouped > start/end tags have to be forbidden? http://markmail.org/message/oznxxsbpnkbxyaal If the start or end, but not both of the XML elements for the range marking do not both fall into the same ECT bucket then you get two opening tags and one closing tag (or the converse). Note that the UC7 example above uses annotations, but a bookmark range works just as well. And I assume there are a few other XML elements in ODF which work in the same manner and will present a similar issue.


  • 9.  Notes on Conference call to discuss use case solutions UC4-UC8

    Posted 09-08-2011 16:39
    Notes on ADC SC Call - 6th Sept 2011 Present ----------- Andreas Robin (Chair) John Patrick Rob Svante Thorsten B Tristan (Robin's office was suffering a power outage so he apologised that he could not access notes made for the call.) UC4 ------ Robin - with ECT buckets it seems that it is not possible to reject changes in any order, only reverse order gives the correct result. Patrick - asked for clarification on why we need to reject out of order. Robin gave the example of moving a text frame and then editing the text. You may wish to only reject the move. UC5 ------ The main issues with this use case is the deletion and re-addition of the text content. It also has the same problems as UC4 but this was already covered in previous call. UC6 ------ ECT is very verbose. Again, cannot reject in any order. Patrick - is the verbosity worse than the current change tracking format? There is not really a comparable example in the current change tracking John - the main concern is how an application matches together the fine-grained GCT changes with a viewable edit operation. Robin responded to say that they are modifying the spec to add editing operation information. Understood that this is an issue for an editing application reading in tracked changes, and needs to be addressed. UC7 + 8 ------------ No significant comments on these use cases. Consensus report ------------------------- Robin will work on a first draft of this, should be complete by month end. Report to contain an introduction to the different approaches, report on work done in the SC and a SWOT analysis for each approach. Comments from SC members would be useful - Rob queried the wisdom of including member's names with quotes. If the document is to be sent out for public review, it can be an issue in that quotes would then need to be approved by companies. Decision was made to include quotes without names. Noted that there will be a revised version of GCT addressing some of the issues raised. There is no revision to ECT expected. AOB ------ Svante asked if we could define what would be in the first milestone. Robin commented that this could only be done once we had decided on which approach to move forward with. Date of next call will need to be re-scheduled as John's dates away have changed, date to be confirmed early in October. -- -- ----------------------------------------------------------------- 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


  • 10.  RE: [office-collab] Notes on Conference call to discuss use case solutions UC4-UC8

    Posted 09-08-2011 20:52
    I have regularly rejected/accepted changes out of order in OpenOffice.org. In fact, you can reject a deletion and accept the insertion that was made in its place. (Obviously, "in its place" is not remembered in the current implementation nor the specification.) The two chunks of material then remain side-by-side in the way they were presented as a tracked deletion and tracked insertion. The cases of one change being imbedded in another is odd except for moves (which are not explicitly provided for in ODF 1.2 change tracking) where one does need to be more clever. But not very much more clever. I am guessing but it might only be movement that has this property of being reversible with later changes *that don't cross the boundary between moved-in and pre-existing* kept intact. If there can be a cross-over that edit breaks hierarchy in this manner, something trickier needs to happen. In other cases, the right thing happens because it has to. - Dennis


  • 11.  RE: [office-collab] Notes on Conference call to discuss use casesolutions UC4-UC8

    Posted 09-09-2011 00:38
    Something tickled my mind when the question about arbitrary rejection order was raised Tuesday morning, but I was either not awake enough to remember the details or was already juggling too many windows with a laptop screen and touchpad to find prior discussion on this topic.

    Both GCT and ECT, using their different representations, store the previous state for each change that is made. Conceptually, each should be in the same position with regard to a specific change being rejected and what should be restored.

    Recall the e-mail thread from June ("Serialization and change tracking ") about this topic, using UC 1 as the example. Here's the first e-mail: http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201106/msg00015.html .

    That thread looked at arbitrary order rejection for both ECT and GCT, so I think it's fair to say both representations can handle it. 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. More fundamentally, it also uncovered that what results from various orders of rejection in cases when there are multiple changes to the same content depends on how the application chooses to structure the change-tracking markup when the changes are made and how it handles the remaining change markup. (e.g.: Tristan: I suppose it depends on how the change is made in the first place. John: Yes, I think that €™s the rub. Off the top of my head, I think it varies based on how the style change is effected in markup)

    It appears to me that a little runtime intelligence is required to determine what a particular rejection should yield (perhaps room for application choice / differentiation) and how to "clean up" the remaining change tracking markup.

    If I read Dennis' comment correctly, I think the above is in line with what he mentions about OpenOffice.

    John




  • 12.  Arbitrary order rejection (was Notes on Conference call to discussuse case solutions UC4-UC8)

    Posted 09-09-2011 16:36
    On 09/09/2011 01:38, John Haug wrote: 91C4760493E4094B9871E5A496374DA23B1ED599@DF-M14-02.exchange.corp.microsoft.com type= cite > 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


  • 13.  RE: [office-collab] Arbitrary order rejection (was Notes onConference call to discuss use case solutions UC4-UC8)

    Posted 09-09-2011 19:29
      |   view attached




    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 b ol d )
     
    (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 b ol d )
     
     
     
    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






  • 14.  Re: [office-collab] Arbitrary order rejection (was Notes on Conferencecall to discuss use case solutions UC4-UC8)

    Posted 09-10-2011 11:27
    On 09/09/2011 20:29, John Haug wrote: 91C4760493E4094B9871E5A496374DA23B1EDBE0@DF-M14-02.exchange.corp.microsoft.com type= cite > 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? I hope that the example provided shows that for ECT this is true, but please let me know if you are not convinced. UC8 also provides a good example of this issue. So, how is GCT different? For the example below we would have for GCT this representation: <style:style style:name= Style1 style:family= paragraph >   <style:text-properties fo:font-weight= bold ac:a3_d22e5= ct2,modify,fo:font-weight,normal     fo:font-style= italic ac:a3_d22e10= ct1,insert,fo:font-style   /> </style:style> (I used the sandbox here to get this: http://www.deltaxml.com/samples/track-changes/sandbox.html ) You can reject either ct1 or ct2 here in either order to get back to the initial version. Reject ct1 and the font-style attribute goes. Reject ct2 and the font-weight reverts to normal. There is no collateral damage. This is how GCT can handle this situation correctly and differs from ECT in this respect. This is a small example, UC8 is a larger one. Regarding your example in 2 below, yes you are correct that GCT cannot handle this any better than ECT because we are at the lowest level of granularity. Consider an attribute color= red (and I respectfully use US spelling!), then this changes to green then to black . What happens if we undo the change of red to green, then undo the change of green to black? Well, it is not really possible or sensible to do that at that level of granularity. But when we change the font-weight we do not expect collateral damage in the change to another attribute, which happens with ECT in my example - that is where ECT and GCT differ. 91C4760493E4094B9871E5A496374DA23B1EDBE0@DF-M14-02.exchange.corp.microsoft.com type= cite >   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.   ..snip   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 b ol d )   (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 b ol d )       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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44