[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] Groups - Event "Discuss draft02 consensus report (Conference Call)" added
|
Notes on the conference call. Here are some notes on the conference call, using the chat room as the basis but with further comments added. NOTE lines commencing: 'Robin La Fontaine:' are from chat room, and each item typically has 'Robin>' lines which are quoted from Robin's email, and 'John:' is John's comments in that email, in particular the threads "Comments on draft consensus report" and "6. Discussion of Different Approaches (was Comments on draft consensus report)". 'ThorstenB:' and 'Svante Schubert:' are from chat room (some re-organisation of lines for clarity) Precisely who said what is not as important as gaining an understanding of the issue. Present ----------- Svante John Thorsten Robin Tristan Robin La Fontaine: 1. Roll call 2. Discussion of consensus report draft02 3. Next steps 4. Any other business Agreed not to go through page by page but rather address issues raised in emails. Robin had prepared a list of these, 1-13, noted below. 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 ODF should not include functionality just because it might be useful to somebody, it should be more about defining a format that implementations can get working in an interoperable way. This requires compromise. Ben has said this is an issue for him as an implementor, but it is not an issue for Thorsten. So we conclude that ODF should take account of different application needs and not server only one type of application/implementation. Robin La Fontaine: 2. What hppens to changes to ODF that are not in XML? Thread "Some thoughts on Change Tracking" Relates to single-file XML representation, then they would be in XML. This effects both proposals and should be raised as an issue in the consensus report. Robin La Fontaine: 3. ODF 1.2 does CT using insert/delete, apart from 5.5.4 Thread "6. Discussion of Different Approaches (was Comments on draft consensus report)" Robin> but rather proposes insert/delete style John: i.e., the way CT is done in ODF (other than as specified in Part 1, section 5.5.4). Just to be clear that its not something brand new. John said it might be best to just disregard the whole section on 'paragraph style'. ECT is in effect an extension of 5.5 in the ODF Spec. 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. Robin La Fontaine: 5. ECT has only ONE way to handle each situation However, supplement says, "The examples may show different ways to support these cases using the additional syntax introduced by this proposal." Robin> this implies that with ECT there could be two ways to handle some changes John: Im not suggesting there be multiple ways to handle something. That paragraph merely intended to acknowledge that ODF may already support some of the cases listed in the Compound Changes section. I added that section as part of the supplement following discussion on the list of other complicated cases involving multiple changes happening. The first example, Add paragraph and merge with preceding paragraph, is already handled by ODF and the example markup used ODF 1.2 syntax. The others, however, used some of what ECT proposed, such as ct:format-change-start and the ct:id attribute to allow multiple children within a text:changed-region. Clarified by replacing the word 'different' with 'improved' in "The examples may show different ways to support these cases using the additional syntax introduced by this proposal." Robin La Fontaine: 6. Scope of "editing text content" covers editing text in paragraphs and table cells and also merging lists and merging/splitting table cells but not add/delete row/column for tables. Is this the general understanding? Does "editing text content" cover anything else? Robin> But the supplement introduces other edit operations so this extends the scope, so it is in fact wider than the table in the proposal. Is that correct? John: What other edit operations? It covers additional use cases around the same types of content. Specific operations such as merging lists? Id think that falls under the category of editing text content. Merge the edit operations in the supplement with those in the main proposal document, the operations in the supplement are additional. Robin La Fontaine: 7. Arbitrary order rejection Under email discussion No further comments - John is looking back at the email thread. 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. Robin La Fontaine: 9. Does ODF CT need to identify the edit operation for a change, e.g. 'delete table row' or 'split table cell'? Background: This info was added to GCT to avoid applictions needing to pattern-match to associate a change with an edit-operation. Has the requirement been understood correctly? Robin> Application-specific types of edit John: Since the proposal makes this recommendation and would need specific handling for ODF (further work), I think this ought to be called out. Svante Schubert: Yes, otherwise applications are not able to specify the mandatory set of changes to be supported Svante Schubert: If two ODF applications are not able to rely on a such a mandatory CT set, there is information loss very likely and not reliability on this feature Svante's opinion is that defining editing operations is more than just a helpful thing to do, it is essential for interoperability. This therefore applies to both ECT and GCT and would be useful work to do independent of the way forward. Robin La Fontaine: 10. XML-centric and non-XML centric applications Is ODF document comparison a reasonable thing to do? If so, a tool is surely entitled to use an XML-centric approach. Robin> to work that out when comparing two ODF documents is a lot harder John: I dont see where comparing two documents comes into play here. Robin said that comparison was just an example of an XML-centric application. No issue here but could be highlighted in the report. It may be that there are conflicts in requirements between the two approaches or that we just need to be aware of two discrete sets of requirements. Robin La Fontaine: 11. ODF document validation, including CT (I do not think there is an issue here, if there is we need to identify it clearly) Robin> I do not understand your last sentence, "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." 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: 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 doesnt 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. Agreed not an issue, ODF validation needed including CT, which can potentially be done in different ways. Robin La Fontaine: 12. Edit rules Robin> ECT would need to have detailed rules for each type of edit John: Is this not the sort of behavior covered by how change markup is used in ODF today? Robin: Yes, that is the point: it is not well defined and this needs to be corrected, otherwise we will just continue the current problems. Covered in discussion of 9 above. Robin La Fontaine: 13. Spreadsheets CT stay as they are in 1.2 for ECT. Is this correct? No plans (for ECT) to remove the change tracking currently defined. John has no objections to making similar extensions to those already suggested in ECT. Table in consensus report is OK to say ECT maintains current partial support for spreadsheets per ODF 1.2 Next steps: Robin will prepare a new version of the report. If possible we will then agree by email that we can send it on to TC otherwise anyone may call for another conf call to discuss. Thanks to all for attending (and hoping no-one missed the call by being an hour late!). On 27/10/2011 12:57, Robin LaFontaine wrote: Submitter's message -- -- ----------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]