Thanks for updating and sharing this second draft of the doc. E-mail might work better than doc comments for this, so a bit more back-and-forth below…
5. Use Cases
UC 7 parenthetical note – My comment indicated it was shown ODF already supports tracking changes to annotations. Is it entirely accurate to simply note UC
7 wasn’t done for ECT without mentioning there was discussion among four people as to whether it was a necessary/valid case? My gut says no and that the text should reflect this.
6. Discussion of Different Approaches
New third paragraph – The new text isn’t right. The “paragraph style” idea was simply me offering a different option from the core insert/delete style the
entirety of ECT uses (and the main style ODF uses, other than section 5.5.4, as noted in the introduction of the supplement) since there was discussion about pros and cons of insert/delete. “Paragraph style” was relegated to the supplement’s appendix, didn’t
get much traction and I never pushed it since it was just an idea to try to spur some design discussion in the SC. The two sentences about attempting to correct ODF’s “paragraph style” and being poorly specified are incorrect and should be stricken – “ECT
addresses…” and “Existing implementations…”.
I didn’t think anyone was unclear on this from earlier discussions. If so, please let us know and we’ll address any questions. From the “paragraph style”
introduction in the supplement doc:
“This approach is included here largely for purposes of discussion within the subcommittee since it is part of the existing ODF
change tracking model. Challenges arise when the block of markup moved to the text:tracked-changes area does not begin and end with text:p tags and when the block does not consist solely of empty XML structure. For these reasons, it is not recommended unless
the subcommittee decides otherwise, and markup examples are included for such consideration.”
6. Discussion of Different Approaches
“Doubts have been expressed quite strongly about the 'bucket' approach, a cornerstone of the ECT proposal…”
“…the current proposal “is a proposed approach with a number of open questions”.”
Why was this moved to be in quotes? It appears to imply fundamental design gaps as if noted in a document or e-mail. The footnote (partial text of my WD01 comment) notes that “some details of the proposal were called out for SC input”. Another part of that
comment read, “All the capability implied by ECT is defined in the proposal.” The text and footnote have two very different implications.
Even accounting for the fact I wrote the ECT document, these two sound to me rather leading. In recognition of my admittedly biased view, I’ll not say more
than that, but merely suggest revisions and open the issue for others to consider. That said there have indeed been questions from some about the bucket approach and I am not implying that should be suppressed. Neither has the approach been shown to be incapable,
however.
Separately… Robin had a reply comment here:
“I disagree with this conclusion, I see where it is but it makes some wrong assumptions, will reply to the email in question.”
I’m not clear which conclusion – the question of diffing applying to both ECT and GCT? That wasn’t concluded with a decision and we ought to be careful to not disregard either side of the discussion. Or something else I missed?
6. Discussion of Different Approaches
“The use of a namespace to denote attribute changes was also questioned by some.”
Not sure if that was added in response to my comment:
Weren’t the following additional concerns raised by other ODF implementers:
- Dynamic-named (i.e., generated) attributes
- Underconstrained scope of applicability of GCT markup to ODF schema
- Two ways to store deleted content complicates implementations
- Application-specific types of edit operations hinders interoperability
I don’t recall anyone complaining about using a namespace for attribute changes. My first list item above was the issue raised about the generated attributes
– ac:change001, -002, -003, etc. I believe the others still apply, as well.
6. Discussion of Different Approaches & 8.2 ECT Weaknesses
6: “It is however more limited in terms of the ability to undo changes in a different order…”
8.2: “…leading to limited ability for undo in different order”
It looks like we disagree here. This needs discussion before the text is completed.
7 & 8
I think it would be most transparent to add the list two items above to 7.2.
Similarly, it could be noted in 8.2 that while ECT does handle split start/end elements (UC 8), it’s not ideal – more verbose since a larger chunk of markup
is cached.
8.3 might also add that ECT preserves the interoperability / bugfix work implementers have already done for ODF’s existing change tracking.
8.2 ECT Weaknesses
“with no specific representation of attribute changes”
I’m not trying to be pedantic here, but that’s the same as the previous. ECT does indeed represent attribute changes. It does so in the context of its containing
element, not scoped down to the particular attribute, in situ. Perhaps just “Coarse-grained representation of changes”? Or “Coarse-grained rep of changes – at the element level only”?
8.4 ECT Threats
Re:
“Focus on editing operations may make it harder for implementation in applications that are not editing applications”,
Robin commented:
“One example I am sure about is that it makes comparison harder because the differences all need to be resolved into edit operations though the operations are not know,
only the changes.”
Not sure about that. A non-editing application that supports change tracking in a given document feature must know about the structure and representation of
that document feature (e.g., style, table). So, for example, if the change is to remove a table row, even an app that doesn’t know to allow the user to effect a table change ought to know that a delete change scoped to a table-row is the deletion of a table
row. The app doesn’t need to know edit operations, just the doc structure affected by edit operations. Scoping what the standard allow to edit operations simply scopes the open-ended environment of all doc features so app designers can plan change tracking
support into their apps.
8.4 ECT Threats (& 9.6)
“Validation of changes…”
I’m afraid I still don’t see what you’re getting at w.r.t. validation. Can you explain it differently? I suspect this relates to the text in section 2: “…validity
of the state before and after the change.” Do you mean semantic validation – that is, valid conceptually for a document? If so, is that not sufficiently provided for by schema validation? Though that assumes the schema properly scopes markup and the generalized/reusable
nature of parts of ODF may make that impossible.
How would GCT’s “simple validity checking model” actually be defined – that is, how does an app certify a document is valid beyond schema validation and a promise
that it’s conformant (which is up to the app to do each time) – and how is that different than an app applying any action implied by ODF’s markup such as deleting text, adding a table row or even ECT? That seems like saying a document is valid if a change
is made to the document in such a way that generates a valid document, but I may be missing something here. Further, most apps have an internal memory model that is not ODF XML, so the only time the question of validity even exists is when a document is written,
long after all actions have been taken.
John
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org]
On Behalf Of Robin LaFontaine
Sent: Monday, October 24, 2011 4:35 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Comments on draft consensus report
John,
Thanks for your comments - I have actioned most of these and where not there are details in the reply to your annotation. If you would like to discuss the details please let me know, I can call you if too detailed for emails.
Robin
On 15/10/2011 02:31, John Haug wrote:
I have a number of comments, in the attached file. I propose replacing two paragraphs, which are change tracked. A few minor typos are also change tracked. Everything
else is in comments (annotations).
Please feel free to discuss, comment or ask me to clarify anything.
John
Following the conference call today, we shall aim at the following schedule:
2011-10-15 all comments on draft consensus report to Robin
2011-10-22 Second draft of report
2011-11-01 Conference call to discuss (difficult timing as European clocks changed but not US clocks, so maybe an hour earlier in Europe)
Robin
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
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 "Change control for XML"
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