Comments on draft consensus report

Thanks for these comments, John, I will reply inline
to some and call out others into separate email because it will be
too long otherwise.
It might be easier to call out
any of these into a separate thread if we need to discuss further.
Robin
On 25/10/2011 01:51, John Haug wrote:
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.
OK, we can add a reference to the discussion so readers can follow
it.

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.”
I may have misunderstood the supplement here, will take out to
separate email.

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.
I will include a clear reference to the fact that the quote is from
the proposal, it should be made clear I agree. It is important that
readers understand the nature of the proposal, and as this is now
not clear due to changes in the ECT overview it should be mentioned
elsewhere. I am not sure if your reference to the proposal includes
the supplement or not - but that is an issue for item above in a
separate email.
In terms of capability of ECT, what worries me is that it was only
in the implementation that ODF's current CT was shown to be
deficient, and we have no implementation for ECT, and no
clarification of the current ODF CT. It is a risk that needs to be
made clear to readers. Perhaps there is work that could be done to
reduce this risk, but it has not been done over the past 6 months.

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?
It is about diffing, per the other email thread  Some thoughts on
Change Tracking .

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.
Yes, you asked for this to be noted, so I did add it for that
reason. The 'use of a namespace to denote attribute changes' is
dynamic-named.. can change that to generated names if that is the
real issue. However, I have never really understood the problem
here, this particular 'feature' of GCT was commended at the plugfest
when first presented. Perhaps there is a problem here I am not aware
of and if someone could say why using a namespace/generating
attribute name is a problem that would be helpful. But it is
certainly possible to do it another way if there is a problem.
Unconstrained scope: this is to do with the need for an editing
application to pattern-match changes to identify the edit operation,
and is handled in the proposal new section 5.2. There is more detail
needed in 7.2 to say how to apply GCT only partially to a schema,
i.e. do not add GCT elements where they are not intended to be used.
That is a discussion in the SC that would be needed and per
Thorsten's request I added a comment to the report in 7.3 para 2
that work is needed here.
Two ways to store... This has been discussed in emails, ODF can
mandate one, no problem here. Whether GCT exists in a more generic
form is a question that has been raised and is now included in the
report under 2. GCT, last para.
Application-specific types of edit... Again the SC may decide
against these, there are potentially edit operations that are:
1. Agreed as part of the standard
2. Defined by a particular 'advanced' application to extend 1 and
eventually become part of the standard, when agreed as useful to
other editing applications (this would be a well-defined extension
mechanism)
3. Others which are not defined edit operations but are still
changes made to the document (revision changes)

The SC may decide only 1 is allowed, so an advanced application
could not save meta-data about its ability to do a text-to-table
edit for example. Rob suggested conformance levels are an
acknowledged way to handle this type of situation.

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.
Seems so! This is the thread  Arbitrary order rejection (was Notes
on Conference call to discuss use case solutions UC4-UC8) . Let's
continue any discussion in that thread rather than here. Please do
reply to my message 10 Sept 2011 to continue.

7 & 8
I think it would be most transparent to add the
list two items above to 7.2.
As soon as I am convinced, I will do that!
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.
I need to look again at UC8, will do.
8.3 might also add that ECT preserves the
interoperability / bugfix work implementers have already
done for ODF’s existing change tracking.
This is surely the strength 8.1,  Builds on current ODF change
tracking , but can make that stronger with your comment.

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”?
Based on your comments, I changed it to above, rather than 'no
representation of attribute changes'. Perhaps 'attribute changes
represented only by add/delete of whole element' would be clearer.

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.
This is where we work, so I am pretty sure about this. Consider a
global find and replace. An editing app could easily identify that
and note the edit operation. But to work that out when comparing two
ODF documents is a lot harder. FYI we implemented our ODT compare
extension entirely as XML pipelined filters, no other data
structures involved. That sort of app, i.e. working directly with
the XML, should be a real opportunity for ODF, e.g. in
auto-generated documents, batch editing apps etc. ODF should not
make it too hard for them.

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.
OK, let me try another angle. An ODF document should comply with the
schema, for sure, and also with other types of validation check (a
validator would really help inter-operability and I am surprised ODF
has got this far without one, but I believe some people are working
on this). By these 'other types of validation check' I mean
schematron or other XML checking mechanisms, e.g. as defined in DSDL
(ISO/IEC 19757). It is hard work to define the rules and write the
code for these validators.
If change tracking is added, then the validator needs to be extended
to check it. However, for GCT we have a methodology for this defined
in GCT proposal, section 3, items 6 and 7. This would mean that the
document validator, i.e. one for a document with no change tracking,
can be used to validate the change tracking as follows:
1. Take a change-tracked document A
2. Extract the latest version of the document from A, validate this
against the schema and other validation rules
3. If there are no tracked changes in A, we are finished, otherwise
continue
4. Roll back (reject) the last tracked change in A
5. Go to 2
The key step is 4 which is implemented for GCT (using XSLT).
ECT could do the same if there was code to reject any tracked change
(this does not exist for current ODF, and would be very hard to
implement due to the complexities of paragraph style).
ECT would need to have detailed rules for each type of edit, I
believe, and the ability to define these, and validate the tracked
changes, is a 'threat' because this does not exist now, is not
covered in the ECT proposal, and may (hence threat not weakness)
prove difficult.
I do not understand your last sentence,  Further..  so may have
missed something there. We need to be able to say if a given ODF
document is valid, wherever it came from.


John
From:

[ mailto: ]
On Behalf Of  Robin LaFontaine
Sent:  Monday, October 24, 2011 4:35 AM
To:

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
From:

[ mailto: ]
On Behalf Of  Robin LaFontaine
Sent:  Tuesday, October 11, 2011 8:47 AM
To:

Subject:  [office-collab] Timetable for next steps

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:  
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

---------------------------------------------------------------------

To unsubscribe, e-mail:

For additional commands, e-mail:


---------------------------------------------------------------------

To unsubscribe, e-mail:  
For additional commands, e-mail:  
--
--

-----------------------------------------------------------------

Robin La Fontaine, Director, DeltaXML Ltd   Change control for XML
T: +44 1684 592 144  E:  
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:  
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK