RE: [office-collab] Comments on draft consensus report

Hi all –

Sorry for the delay in replying – I was out of the office at the end of last week. Let’s see… I replied earlier to questions in the new thread about “6. Discussion of Different Approaches”. I replied last week on the “Some thoughts on Change Tracking” thread (re: GCT also requiring diffing); no subsequent mail on that yet. I’ll go back and look again at “Arbitrary order rejection”.

> 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

Concern that there is no implementation yet is valid. If that’s the point, let’s make that point rather than broad statements that when taken alone seem to imply a core part of ECT has been discredited. As it is, this is already noted in 8.4.

> can change that to generated names if that is the real issue. However, I have never really understood the problem here

I believe that was the issue (that it uses generated names). Frank and Andreas raised questions on this and I’ll have to defer to them to explain more since they’re developers.

> There is more detail needed in 7.2 to say how to apply GCT only partially to a schema

That was my key point about unconstrained scope.

> Application-specific types of edit

Since the proposal makes this recommendation and would need specific handling for ODF (further work), I think this ought to be called out.

> As soon as I am convinced, I will do that!

Well, if there are differences of opinion among SC members that haven’t been resolved to an agreed conclusion, I think that obliges us to keep the issues visible.

> 8.4 ECT Threats / 8.4 ECT Threats (& 9.6)

I think I see a difference in perspectives that may be making it harder for us to fully understand one another at times. I believe you’re coming from an XML-centric perspective and I’m coming from a non-XML-centric one (document-centric?). Rather than editing app vs. non-editing app, I think the distinction as it applies here is whether the app operates at the XML level or the document level. An example of a non-editing app that doesn’t operate at the XML level might be an ODF viewer that translates the XML into a memory model conducive to presenting it to the user in some fashion. I fail to see why it would be any harder for that app to handle ECT than an editor.

> to work that out when comparing two ODF documents is a lot harder

I don’t see where comparing two documents comes into play 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.

> 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.
This is the point I make above – most (many, certainly) apps do not execute solely at the XML level. They read the XML and parse it into data structures in memory that are reflective of whatever task the app performs. My point was that it essentially doesn’t matter from a validation perspective what an app does at runtime before actually writing out an ODF document. I also understand your follow-up point that validity of a doc containing a set of tracked changes also means those changes can be rejected in a mechanical manner and yield a valid doc. Which leads to…

> ECT would need to have detailed rules for each type of edit

Is this not the sort of behavior covered by how change markup is used in ODF today?

John

From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Robin LaFontaine
Sent: Thursday, October 27, 2011 8:45 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] 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: 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

From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Robin LaFontaine
Sent: Tuesday, October 11, 2011 8:47 AM
To: office-collab@lists.oasis-open.org
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: 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

--

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

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

office-collab message