office-collab — archive

Groups - ODF Change Tracking: Analysis and Proposals Version 1.0 uploaded

From: Robin LaFontaine <[email protected]>
To: [email protected]
Date: Fri, 16 Dec 2011 21:03:00 -0000

Thanks, John. There is no formal mechanism for the SC to vote but as no-one else has made any comment on 03 I think it is reasonable to pass this on up to the TC now. On 5th Dec in an email to the list I said, If there are no objections or requests for a call by next TC call (Monday 12th Dec) then I will submit to the TC. There have been no such objections or requests, except your comments, which are now resolved. Also, as all SC members are also TC members they will of course have an opportunity to make comments or vote on it there. So I think it is time to move it up to the TC. Robin On 16/12/2011 20:42, John Haug wrote: Thanks, looks good. I think the WD 04 works. Do we need to do some sort of quick ballot to approve this at the SC level? From: [email protected] [ mailto:[email protected] ] On Behalf Of Robin LaFontaine Sent: Friday, December 16, 2011 9:38 AM To: [email protected] Subject: Re: [office-collab] Groups - ODF Change Tracking: Analysis and Proposals Version 1.0 uploaded Thanks for the response on these - let's see if we can get this done before we all go for holiday! I think we are just about there now. Issue 1: OK, will make suggested changes for now. Issue 2: Yes, indeed work is needed in both. I have amended Other SC members do not see this as a problem. to Other SC members do not see this as a problem, and pointed out that other work is needed in GCT therefore it is not clear if this comparison means more work overall or not. Issue 3: OK, now reads: Proposed solutions for these issues have now been included in GCT though not designed in detail. Re edit ops, I think this applies to both anyway, but agree work is needed for sure! Issue 4: OK, will change as you suggest. Issue 5: I have added a new weakness to GCT to be consistent as you suggest: Work is needed to map the representation of a change into an internal data structure Issue 6: changed as you suggest Issue 7: changed as you suggest Hope this will work, I am attaching the proposed amended document with changes shown, I have not uploaded anything to the server yet but will do so it this seems OK for you (in that case I will also submit to TC for their review, which would be nice before year end). Have a great holiday! Robin On 14/12/2011 01:31, John Haug wrote: Thanks for the thoughtful and organized reply. #1 – Sounds OK. I did let that question drop off my brain. I’ll try to look at it, but I’m out of the office for a couple weeks in a few days… #2 – Thorsten mentioned “ well the same applies to GCT. The very fact that it needs annotations is testament to this issue. ” early on the “Some thoughts on Change Tracking” thread but unfortunately hasn’t yet followed up with more. I’m not sure what particular case he had in mind. Both approaches require indexing into and analyzing markup quite a bit to gather the info needed to determine exactly what changed and this equivalence is why I commented on the text calling out ECT comparison being necessary to determine what has changed while leaving unstated that a fair amount of legwork is needed in both to pin down what changed. See the attached file. I wanted to walk through an example to prove to myself whether I was correct in my assumption that the work for the two is terribly similar. I used a very simple case of multiple format changes to a piece of text and worked out a high-level general algorithm for how to determine exactly what happened in a given user change action. The comparison of the cached markup for ECT is but one part of a multi-step process of indexing and examining markup that is required for both approaches. This case only involves user changes that result in changes to XML attributes; one involving structural (element) changes would be yet more complicated for both. Of course, if I have anything wrong in the attached, please let me know. So what am I getting at, right? I’d like to see appropriate context for the “ECT requires comparison” note that doesn’t seem to imply “you have to do a bunch of work in ECT to know what changed but don’t need to do a bunch of work in GCT”. Both require legwork and ECT does also have a comparison component. #3 – Re: scope – by “implemented” I thought you meant that it hadn’t been implemented by Ganesh or Ben, since prototype implementations are mentioned elsewhere. Perhaps “designed” is clearer? It’s a fairly big open task to determine how to limit the scope of where GCT attributes and elements would be allowed within ODF schemas. Re: caching – just mentioning that there are decisions yet to be made – i.e., everything isn’t as wrapped up and ready to ship. Re: generated names – Yes, if that method is adopted. Sorry, my oversight. Re: edit ops – “Standard” ones are preferable to app-specific, but these are not yet defined. As it stands, they’re optional and undefined, so by default they’re app-specific, right? Similar to the scope topic – a mechanism/framework is proposed but needs further design work to complete, so we ought not imply everything is done. #4 – I’m not looking to nitpick over XML/non-XML vs. edit-op-based/non-edit-op-based, though I do think the crux isn’t so much about editing operations as about being centric to higher-level document concepts (text, table, image, etc.) vs. lower-level XML representation. The itch in my mind here is that someone skimming this report will read this as ECT doesn’t work well for apps that aren’t full editing apps, which isn’t true, and think that categories such as ODF viewers are simply unsupported. How about: “Similarly, the ECT emphasis on document components may cause more difficulty for applications whose internal models are XML-centric.” #5 – Dependent on #3 #6 – As in #4, how about: “Should be easy to implement for applications whose internal models are based on document components.” #7 – As in #4, how about: “Focus on document components may make it harder for implementation in applications whose internal models are XML-centric” John From: [email protected] [ mailto:[email protected] ] On Behalf Of Robin LaFontaine Sent: Monday, December 12, 2011 9:20 AM To: [email protected] Subject: Re: [office-collab] Groups - ODF Change Tracking: Analysis and Proposals Version 1.0 uploaded Thanks for the comments. I have pasted in here to discuss. This results in some updates to the document which I am happy to do when we have finished our discussion. Issue 1. “detailed specification for the algorithm” - Uncertain what is implied/requested here. Both ECT and GCT have fairly straightforward processes for replacing the “new” markup with the cached info, or is the meat of this sentence just the bit about “clarification...”, which is really just the bit in the paragraph above about “clearer definition is needed”? I see your problem with this - the current ODF spec has no such spec for the 'reject' algorithm, so that might be part of the clarification. I could move: There is no detailed specification for the algorithm that needs to be applied to reverse tracked changes up into previous paragraph, that might be clearer because it is primarily a problem with the current spec though compounded with more extensions. Regarding: clarification is needed in situations where similar changes may use the paragraph style or the insert/delete style, e.g. list merge and list item merge in the ECT Supplement. This is something I have requested and not seen so the comment remains valid I believe, see notes on conf call in email 2 Nov: Robin La Fontaine: 4. How does an application know whether to execute 5.5.4 algorithm or insert/delete in ECT? Example: in Supplement, List item merging uses insert/delete, List merging uses paragraph style. Robin> though I was unable to get the right results applying the insert/delete style algorithm John: Since ECT doesnt propose removing 5.5.4, it applies in this case since the change marker is inside a <text>. The example works if 5.5.4 is followed. See 3 above. John will check out why solution to List merge and List item merge (in the ECT supplement) appear to be different, e.g. the text 'Line 2' is duplicated in one solution and not in the other. It is not clear exactly how the paragraph-style and insert/delete differ and when one or other applies. Perhaps I missed an email on that, if so I apologise, please let me know. Issue 2 Other SC members have also pointed out that comparison work is needed for GCT. Isn't it conceptually similar to needing to process a bunch of markup to determine what exactly has changed for GCT? Simple cases are simple for GCT (e.g., attribute value changes), but more complex ones involving various remove-leaving-content and the like require processing. In ECT's case, both simple and complex cases involve a diff of a block of markup. This was discussed in our 1 Nov conf call: Robin La Fontaine: 1. ECT requires applications to do comparison of bucket content, GCT does not require this Thread Some thoughts on Change Tracking Andreas/Thorsten: please demonstrate if GCT needs to diff like ECT Thorsten will look at this and comment. Hopefully Andreas will do the same ThorstenB: Robin, I still maintain my position that this ECT needs to diff content is a red herring - the frame has changed, that's what the application displays at that level of granularity Let me know if I missed an update on this but I do not recall any example where comparison is needed within GCT. Regarding complexity of implementation of GCT this has been raised elsewhere in the report (7.4), but it is not to do with comparison. Issue 3 This implies that all questions about GCT are resolved. Re: scope, but the last paragraph of section 2 indicates that while a mechanism was added, how to define such a profile for ODF hasn't been looked at. Re: caching deleted text, the update raised new concerns that there are now two ways to handle deleted content. Re: generated names, this implies something was done in the update, but there are no changes to this. The update also adds a mechanism for noting app-specific edit operations, but the app-specific nature raised new concerns about more work being needed to define them for ODF, or that interop will be negatively affected if left to individual apps. Re scope, yes, that is why it says but not yet implemented . But perhaps it would be better to say, Proposed solutions... rather than Solutions... Caching deleted text: the two ways provide a choice for the SC not for the user. The revised GCT spec says: 15. An application can elect to cache deleted content in situ, i.e. where it was deleted, or in another place in the document. They cannot be mixed, one or other must be chosen. and there was confusion about the term 'application' here per email discussions: the intent is for ODF to mandate one way to do it. Two ways would be a problem, I agree, so the SC can just pick one. Generated names: In the revised GCT spec section 8.2 there is an update to address this, if the attributes are cached rather than in situ then generated names are not needed, just an ID attribute. But we still do not know the issue with generate names, again see 1 Nov conf call notes: Robin La Fontaine: 8. Generated attribute names in specified namespace: what is the issue here? Robin> can change that to generated names if that is the real issue. However, I have never really understood the problem here John: I believe that was the issue (that it uses generated names). Frank and Andreas raised questions on this and Ill have to defer to them to explain more since theyre developers. John not sure what the issue is with generated attribute names. It could be a technical issue or merely a dislike of the idea. Andreas and Frank may be able to give more details. App-specific edit operations: New GCT spec 5.2 states: This mechanism could easily be extended so that a given editing application which has an operation that is not defined in the standard, would be able to create a new definition perhaps using its own namespace as a prefix. So the SC can decide not to allow such extensions, though it is an opportunity it seems to me! Issue 4 Based on the last call and the subsequent notes, I suggest we rename the editing vs. non-editing app nomenclature to XML-centric vs. non-XML-centric to avoid the past confusion over cases such as a non-editing app that has an internal memory model that is not XML-centric? The form of the memory model appears to be what causes the differences. There are two distinct issues here and I think they should not be merged into one. The statement here is about reflecting edit operations in CT (edit tracking) rather than revisions to the document (revision tracking). This has nothing to do with the underlying structure of the application, which is the discussion re XML-centric or non-XML-centric. It is true that currently most editing applications are non-XML-centric but that may change - the issues are separate. Issues 5,6,7 Your comments in section 8 refer to the above discussions so are covered by them. Robin On 07/12/2011 02:16, John Haug wrote: I finally had a chance to look at this late last week. I’m afraid I do have a few comments, primarily around the last few areas where there are differences of opinion without solid conclusions. Even though we’ve discussed this in calls and on e-mail, they’re still depicted in the draft as conclusive fact with no hint that there is still (or ever was) disagreement. I pulled together some comments in the attached document. John From: [email protected] [mailto:[email protected]] On Behalf Of Robin LaFontaine Sent: Monday, December 05, 2011 9:40 AM To: [email protected] Subject: Re: [office-collab] Groups - ODF Change Tracking: Analysis and Proposals Version 1.0 uploaded All, This was discussed in the TC call today and the TC is anxious to move this on to get comments from TC members and then wider through a public review. So please would each of you indicate if you are OK with this as it stands (subject to some detailed editing for references etc) or if you think we need another call to discuss within the SC. If there are no objections or requests for a call by next TC call (Monday 12th Dec) then I will submit to the TC. I hope then we may be able to look at Svante's work, when available, as well as have a break over the holiday period. It will be good to get this published, the exercise has been productive. Best regards, Robin On 18/11/2011 18:06, Robin LaFontaine wrote: Submitter's message I have revised the consensus report based on email discussions and conference call 2011-11-01. It was quite difficult to trace through all the points so apologies if I have missed any. Please send comments to the list and we will review in a week to see if we need to set up another conference call or if we can do any final revision without a call. I believe we are getting near to a final version now! Thanks for all the input. I will send a markup of changes out also to the list. -- Robin LaFontaine Document Name : ODF Change Tracking: Analysis and Proposals Version 1.0 Description This document describes and comments on the initial work, from January to September 2011, of the Advanced Document Collaboration Subcommittee. Two contrasting approaches to the representation of changes (commonly known as 'change tracking') are described and compared. The intention is to provoke constructive comments from the wider community in order for the TC to direct the subcommittee on the way forward. Download Latest Revision Public Download Link Submitter : Robin LaFontaine Group : OpenDocument - Advanced Document Collaboration SC Folder : Standards Date submitted : 2011-11-18 10:06:07 Revision : 2 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK