[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] An Abiword / Calligra developer's view of theChange Tracking events.
|
Hi Ben – A few comments on your questions below. > I think perhaps many citations in the extended proposal are to older change tracking rather than the "generic" one. Indeed, correct. The extended proposal is intended to consider ways the existing change tracking model that has been in ODF since 1.0 can be extended to cover core cases it does not currently support. > How closely does the "extended" proposal mirror what is performed by Microsoft Word for non ODF formats? For me, it would be interesting to see how these things play out, and how the user interface offers such functionality in an existing
implementation of the "extended" proposal. Even if that implementation stores in non ODF currently. Please note that there is not yet a prototype of the extended proposal. We haven’t jumped the gun to build anything into Word without appropriate discussion and agreement in the SC; that is, Microsoft isn’t
attempting to force something we’ve built onto the ODF standard. I apologize in advance if I misunderstood and that’s not what you were implying, but I do want to make sure that’s clear to everyone. > As an example, the move content on page 4/19 of the extended proposal mentions that move is currently handled as delete/insert and no link between the two. Clearly in the generic proposal such a link is explicit as mentioned on page
17/23 of the generic proposal. There is an explicit linkage among the various markup changes that reflect the user action. Note that the
ct:move-insertion and two ct:move-deletions are all under a single
text:changed-region. The text:changed-region is associated with the single user action of move, and the individual markup changes needed to reflect that user action are represented by its child elements
ct:move-insertion and ct:move-deletion. (Note this is logically parallel to, if not exactly equivalent to, the generic proposal’s notion of a change transaction consisting of multiple atomic changes.) The element names
ct:move-insertion and ct:move-deletion also explicitly identify the insertion and deletions as part of a move. (And for those who were also searching around to find the reference in the generic proposal, it’s
§6.10, page 14/20 – the table of contents needs to be updated.) > Perhaps a more fluid example would be moving a paragraph with D&D and then deciding that other content should subsequently be moved too as part of a single semantic "reorganize" operation. Interesting abstraction. My initial thought is we need not try to infer that multiple user actions are part of a larger conceptual action. My next thought is that is really an implementation concern rather
than a file format one. That is, if an application had a way to surface such a concept to the user, it could then decide to use the syntactic features of the file format to accomplish that. For the file format, it’s handy (to me) to think of the
text:changed-region as equivalent to a single user action since this is likely the highest level action an application would track and is made up of numerous format-specific bits of markup – even though an implementation could certainly consider that
to be some other larger single-concept action that envelops multiple user actions. That same line of thinking applies for my thoughts on your comments here – I see these as separate user actions: For example, I might move a paragraph and then decide to move a non-contiguous one but would really like to emphasise that these moves are very strongly related. And what if I fixed a spelling mistake after the first move but before
the second? > IMHO it would be rare to expect the user to control-select many non contiguous blocks and decide to move them at once. I agree it’s lower down the priority list of user actions. But I wanted to demonstrate that this more complex case was also possible since it implicitly defines how to handle a move of a single paragraph. Does that help? John -----Original Message----- > The timing of the "extended" proposal seems a little odd to me, as it was mentioned last year in Brussels that projects were looking to implement the generic proposal for ODF change tracking. This is a strange thing to say to the members of an OASIS technical committee, Ben. You and others may have chosen to implement a non-standardized proposal prior to any consideration of it within OASIS's open and transparent standards
process, for whatever reason, but I disagree that such decisions should guide the work of this group. We need to follow the consensus-based OASIS process, regardless of what was said between private parties at a non-OASIS event in Brussels last year. This committee has agreed upon a timeline that allows for proposals to be submitted through the end of March, and we have respected that process and adhered to it. If an SC member were to submit a proposal tomorrow, which is still prior
to the deadline we have agreed upon, I believe this group has an obligation to take such a proposal seriously based on the timeline that we have publicly agreed upon. > I think perhaps many citations in the extended proposal are to older change tracking rather than the "generic" one. Correct. The mission of this committee, as covered in the Statement of Purpose, is to "draft enhancements to ODF," so the extended proposal makes reference to the change tracking in the ODF standard and provides suggestions for improving
that part of the standard. Thank you for your comments on the details of the proposal. I'll let John respond to those. Regards, Doug -----Original Message----- From: monkeyiq
[mailto:monkeyiq@gmail.com]
Sent: Friday, March 25, 2011 7:38 PM To: office-collab@lists.oasis-open.org Cc: Ben Martin Subject: [office-collab] An Abiword / Calligra developer's view of the Change Tracking events. Hi, As I have been a non vocal member of the list, many folks will likely not know me. I have hacked on KOffice/Calligra and Abiword. For the latter I have made a reasonable headway toward implementing the original "generic" change tracking
proposal for ODF. I am not particularly affiliated with any company. This includes DeltaXML who proposed the "generic" change tracking and Microsoft who proposed the "extended" change tracking. I am more in favour of discussing things on the mailing list than conference calls. My timezone tends to make the conference calls harder to make. At the very least I should highlight to the group that there is a git branch of Abiword publicly available on github which supports the "generic" change tracking proposal for paragraph split/merge, text addition/deletion, move paragraph,
toggle heading style, and growing support for the delta:merge swiss army knife. This will be folded into an upcoming mainstream release of abiword. So there are two existing implementations of the "generic" proposal; abiword and the work of Ganesh Paramasivam on KWord/Calligra. The timing of the "extended" proposal seems a little odd to me, as it was mentioned last year in Brussels
that projects were looking to implement the generic proposal for ODF change tracking. In the interests of friendly collaboration I would have hoped that alternatives would have been tabled at that time or shortly thereafter. In light of the now existing implementations
of the generic proposal, my vote would be to use the generic proposal and cherry pick things from the "extended" proposal as needed. How closely does the "extended" proposal mirror what is performed by Microsoft Word for non ODF formats? For me, it would be interesting to see how these things play out, and how the user interface offers such functionality in an existing
implementation of the "extended" proposal. Even if that implementation stores in non ODF currently. Over the last few days I have been bringing myself up to speed on the "extended" proposal. I think perhaps many citations in the extended proposal are to older change tracking rather than the "generic" one. As an example, the move
content on page 4/19 of the extended proposal mentions that move is currently handled as delete/insert and no link between the two. Clearly in the generic proposal such a link is explicit as mentioned on page 17/23 of the generic proposal. The moving of multiple non-contiguous blocks of text as mentioned in the "extended" proposal is quite interesting. Perhaps a more fluid example would be moving a paragraph with D&D and then deciding that other content should subsequently
be moved too as part of a single semantic "reorganize" operation. IMHO it would be rare to expect the user to control-select many non contiguous blocks and decide to move them at once. The question then becomes does a delta:change-transaction provide fine enough granularity to capture these cases, or should we also have something at a sub revision level, like text:changed-region, to allow markup of these grouped
moves. Or alternately, should some RDF be able to reference each delta:insertion-change-idref to allow such relations and others to be captured explicitly. It seems to me having sub revision level constructs also runs the risk of being forgotten by the user. For example, I might move a paragraph and then decide to move a non-contiguous one but would really like to emphasise that these
moves are very strongly related. And what if I fixed a spelling mistake after the first move but before the second? One thing which might be useful at a sub revision level would be time_t values (relative to UTC 1970 or as ISO 8601/dc:date encoding). This way a second paragraph move would also explicitly let the viewer know that it was moved on the same day 12 minutes after the last paragraph move. And 7 minutes after the text "great stuff" was added. I'll split out subsequent comment on the extended proposal to another email as this is getting long already. --------------------------------------------------------------------- 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]