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
|