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: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org]
On Behalf Of Robin LaFontaine
Sent: Monday, December 12, 2011 9:20 AM
To: office-collab@lists.oasis-open.org
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
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: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
--------------------------------------------------------------------- To unsubscribe, e-mail:
office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
office-collab-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change"
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, e-mail:
office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
office-collab-help@lists.oasis-open.org