[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] Thoughts and Comments onextended-change-tracking-proposal
|
1. The supplement seems to introduce a new way to handle delete changes The reference to Insert/Delete style is the same pattern from the first document. I gave it a name here to differentiate it from the “paragraph style” approach I wanted to at least bring up in case it was worth
discussion. 2. Doesn't the introduction of the new mechanism break backward compatibility to the old ODF 1.2 change tracking format. See also the above. The general question of backward compatibility needs to be looked at in detail across the board for both proposals, particularly with input from implementers who have existing change tracking support. I think
both proposals may have back-compat issues. Depending on various choices the SC would need to make about the specific changes it would introduce, I think the extended one could be designed to be additive only – introduce only new mechanisms. Whether an implementation would naturally ignore or get stuck on the existence of new elements/attributes in an ODF 1.3 file is, I think implementation-specific. Back-compat is a particularly tricky issue to
work around with any new file format change and my experience with it has been that the file format and interpreter need to have some level of forward compat built in – that is, designed in such a way as to be resilient to future changes. With XML, we don’t
have the binary problem of leaving buckets of reserved bits open and ignored. But I think there is still some onus that spans the interpreter and whether the file format has any mechanism to identify future things. My experience here is more with OOXML,
which has a well-defined and built-in mechanism for future changes / extensions that means extensions can be made without violating old schema. I’m less familiar with how these sorts of issues have been handled with ODF in the past. 4. the way paragraph/list-item and list-item merges are handled These points are valid. I tried to give this a nod as a detailed design question for the SC to discuss in the future by raising it in the second paragraph under Introduction > Insert/delete style, but perhaps
it wasn’t as clear as it needed to be. I think it would be useful to have specific element names for the various types of changes that are being tracked. This would make each category of change explicit and make the job of the implementer easier as well,
I suspect. 5. The table splits and merges Yes, I believe you are correct. Thank you – I’m afraid I missed that by virtue of omitting attributes in the examples for simplicity. My first thought is that wrapping the changed cell in a change-start and
change-end (and caching the old cell in the text:changed-region) would allow the cell property change to be captured. I think this is another case for the point we’re talking about in #4 – a specific name for these wrapping elements and the caching element
in the text:changed-region would identify it as a merge or split and (even though cell add/delete isn’t proposed to be supported, and isn’t by any app I recall off the top of my head that supports tables or spreadsheets). How does that strike people? Apologies in advance for any terseness or errors above. I’m rushing to finish a few things here before crossing our
local mountain range for a conference this weekend. Which is partially impassable due to avalanches and mudslides… Should be a fun drive! John -----Original Message----- John, Please find below my comments on the supplement. Thanks, Ganesh 1. The supplement seems to introduce a new way to handle delete changes ( it is called as the Insert/Delete style and is conceptually different from the ODF 1.2 delete change handling mechanism ). So, the new mechanism should be applied
to the <p> to <p> and <p> to <h> merges too ( The two use-cases that are explicitly handled in the current ODF 1.2 specification ) . Right ? 2. Doesn't the introduction of the new mechanism break backward compatibility to the old ODF 1.2 change tracking format. 3. There are some problems/bugs in the way paragraph-list merges are handled by the ODF 1.2 mechanism ( called as Paragraph Style ) examples in the document. For sake of brevity, I will not list out the problems here ( as you have mentioned
in the document that this is not a recommended approach ). 4. This opinion is subjective, but I do have some issues with the way paragraph/list-item and list-item merges are handled by the new mechanism. Some concerns that I have are - The change mark-up does not accurately capture user-intent because it converts a delete user-intent into a combination of insertion-deletion user-intent. - Two roles being assigned to insert changes ( actual insert change, side-effect insert-change ). So insert-change handling code at all places ( loading, saving, displaying etc ) needs to have logic to differentiate between the two roles. 5. The table splits and merges examples seems to ignore the number-rows-spanned and number-columns-spanned attributes of table-cell and instead depends only on covered-cell. The covered-cell should always be handled in conjunction with
the other two attributes to accurately determine to which table-cell the covered-cell belongs to. Some side effects of this are - A horizontal merge of a cell and a vertical merge of a upper-right-diagonal cell would result in the removal of the same covered-cell and the insertion of a a new cell in the same location. The resultant change-markup for these two completely different use-cases would be exactly the same. - If a cell-split or a cell-merge change is rejected, it would not be possible to know the previous merge/split state of these cells because the values of these two attributes are not stored as a part of the change-markup. I think all table-cell split and merge examples might need re-work to address this issue. Am I missing something here ? On Thu, Mar 31, 2011 at 5:12 AM, John Haug <johnhaug@exchange.microsoft.com> wrote: > Sorry for the delay on this. It took some time, plus other commitments. > The examples in this doc are fairly straightforward extrapolations of
> the patterns established in the main proposal doc and in line with the
> general flavor of existing ODF change tracking. > > > >
http://www.oasis-open.org/committees/document.php?document_id=41677 > > > > I hope it helps further everyone’s understanding and the discussion. > > > > John > > > > From: John Haug
[mailto:johnhaug@exchange.microsoft.com] > Sent: Tuesday, March 22, 2011 6:02 PM > > To:
office-collab@lists.oasis-open.org > Subject: RE: [office-collab] Thoughts and Comments on > extended-change-tracking-proposal > > > > By the way, while I look into this, I’d like to solicit input from
> others on how some of these cases should look. Again, we intended
> this document to be a starting point of discussion, a catalyst for the
> subcommittee to create an inclusive design, not a specification of how
> I think every detail of a design must look. I’d love to hear from
> others who have expertise in this area as they likely have some insights I may not. > > > > John > > > > From: John Haug
[mailto:johnhaug@exchange.microsoft.com] > Sent: Monday, March 21, 2011 5:45 PM > To:
office-collab@lists.oasis-open.org > Subject: RE: [office-collab] Thoughts and Comments on > extended-change-tracking-proposal > > > > Hi Ganesh – > > Yes, as general text edits, we would certainly intend for #1 and #3 to
> be supported in an extension to the current change tracking model.
> Same for #2 as a basic table edit. > > > > I can start looking at building example markup snippets, though that
> will take some time given the number of specific cases called out.
> Until then, some general guidance that might help: While working on
> the proposal it came out that each category of change essentially established a basic pattern. > So while each of the specific items listed below as example cases
> would be a separate markup snippet, they follow common patterns and
> you should be able to get a quick sense of the markup/implementation
> complexity by looking at similar examples in the proposal document. > > > > John > > > > > > -----Original Message----- > From: Ganesh Paramasivam
[mailto:ganesh@crystalfab.com] > Sent: Sunday, March 20, 2011 11:45 PM > To:
office-collab@lists.oasis-open.org > Subject: [office-collab] Thoughts and Comments on > extended-change-tracking-proposal > > > > Hi, > > > > I have had a change to go through the new change-tracking proposal and
> please find below my initial thoughts and comments. > > > > I'm aware of the fact that this specification is intended as a
> "general vision document" than a full specification, but it would be
> nice to know the over-all approach that the proposal intends to take
> to support the below mentioned use-cases because that would a criteria
> ( implementation complexity and feasibility to support not-so-simple
> scenarios ) in comparing multiple approaches. > > > > Thanks, > > Ganesh > > > > 1. Missing support for certain types of delete merges. > > The use-cases that come under this category are > > - Paragraph merge with a list-item > > - A list-item merge with paragraph. > > - List-item merge with another list-item > > - List merge with another list. > > These use-cases are illustrated under the category "Other" ( I.1
> through > I.7) at
http://wiki.oasis-open.org/office/ChangeTrackingUseCases > > > > 2. Missing support for table cell splits and merges ( Single as well
> as multiples and combinations. example:- two consecutive horizontal
> merges followed by a vertical merge ) These use-cases are illustrated
> under the category "Tables" ( C.7 through C.10) at >
http://wiki.oasis-open.org/office/ChangeTrackingUseCases > > > > 3. Clarification needed for multiple and over-lapping change
> use-cases. It is not entirely clear whether these use-cases are
> supported or not. Would be great to see this specifically addressed in the proposal. > > Some examples ( non-exhaustive ) of this category are > > - A paragraph addition followed by a merge of the paragraph with a
> preceding paragraph. > > - Text addition followed by format-change followed by deletion of the
> text > > - Paragraph addition followed by style-change followed by deletion of
> the paragraph. > > - Text-deletion followed by deletion of the paragraph > > - Text-addition followed by deletion of the paragraph. > > - List-item addition followed by a merge with a succeeding paragraph. > > Some of these use-cases are illustrated under the category "Multiple
> Changes" (F.1 through F.11) at >
http://wiki.oasis-open.org/office/ChangeTrackingUseCases > > > > --------------------------------------------------------------------- > > 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]