OASIS Open Document Format for Office Applications (OpenDocument) TC

Questions/comments concerning the Select Committee report on Change Tracking 1. GCT and ECT were proposed and discussed as changes to the ODF format for change tracking, not collaboration. In fairness to those proposals and to create a common basis for comparison, the select committee choose to compare GCT, ECT and MCT as change tracking proposals only. A sensible decision, in line with the TC terms of reference for the Subcommittee. 2. Without implying a decision on syntax, the select committee chose the ETC's feature matrix as the basis for features to be supported by the new change tracking features of ODF (Annex A). Speaking as chair of the Subcommittee, there have been strong requests for change tracking in spreadsheets and the terms of reference of the Subcommittee was even wider than this. I note that you have added global operations and that seems very sensible, although useful operations such as text-to-table and vice versa will remain untrackable. 3. GCT, ECT and MCT all chose different paths but with some minor differences all would satisfy the change tracking use cases. Actually that is incorrect: ECT was unable to satisfy the use cases for spreadsheets. MCT to date has shown solutions for only a small set of use cases. 4. Having said that, however, ECT adds detailed markup in an attempt to make change tracking “easier” which it may do in some view of the format. Lack of verbosity is not a goal for XML but as has been seen from practical experience, performance of XML editors can suffer from overly verbose XML. This implies ECT was rejected on grounds of verbosity. I understand from our conference call that this is not the case so perhaps you could clarify this and be a bit more specific in identifying why ECT was not favoured. 5. GCT ... represents a great change to the ODF format. It would require a substantial overhead, both for XML and non-XML implementations of ODF. Particularly when compared to the operations proposal which we discuss below. The select committee cannot recommend GCT as the proposal to “fix” change tracking in ODF. This statement that GCT has a more substantial overhead than MCT seems to be a bold declaration, given that MCT is some considerable way away from being fully defined. Please would you add an explanation of this for the record as you are asking the TC to base the future direction of ODF on this. Also note that there are already two independent implementations of GCT which provide clear evidence that the overhead is not substantial. Have you dismissed this evidence, and if so please explain why? 6. MCT has been distracting with its emphasis on collaboration issues in a change tracking context. It does offer the cleanest proposal for tracking changes in ODF documents. Please explain what you mean by cleanest . 7. The first point to be made is that once operations and addressing are defined, the MCT change tracking proposal only requires an understanding of existing ODF markup. As opposed to specification and parsing of additional, “change tracking” markup. My understanding was that MCT would require a new set of markup (for operations and addressing) that would need to be defined for use in undo.xml. Each operation would have its own specific markup, which would need to be defined, parsed and understood by an application. Moreover, the application would need to understand and be tested against the definition of all the operations. Therefore, if that is correct, I suggest that this statement is somewhat misleading. Please provide a more detailed explanation of what you mean here. Robin

On Thursday 19 July 2012 10:40:57 Robin LaFontaine wrote: > Questions/comments concerning the Select Committee report on Change > Tracking > > 5. "GCT ... represents a great change to the ODF format. It would require > a substantial overhead, both for XML and non-XML implementations of ODF. > Particularly when compared to the operations proposal which we discuss > below. The select committee cannot recommend GCT as the proposal to “fix” > change tracking in ODF." > > This statement that GCT has a more substantial overhead than MCT seems to > be a bold declaration, given that MCT is some considerable way away from > being fully defined. Please would you add an explanation of this for the > record as you are asking the TC to base the future direction of ODF on > this. > Hi Robin As maintainer of one of those two implementations you refer to I can tell you that it indeed requires a substantial amount of overhead. The XML og GCT is so intrusive (can occur everywhere) that it has completely messed up our conversion code (as most applications we convert the XML to an internal model). Messed up in the sense that we find it hard to maintain our conversion code. In fact even if the TC would select GCT we (Calligra) would remove our implementation and so choose not to support change tracking at all. That is how bad this experience has been. We gave it a very fair try by implementing it and trying it out, but as I said, because of it's very nature it's close to impossible to maintain our regular conversion code. Sure you may claim it to be the way our code is, but I say it's due to the fact that we need to handle CT tags everywhere. A GCT like way of storing changes may work very well if you are just dealing with XML. And by just XML I mean not having to convert to an internal model and back, And by just XML I also mean just syntax and not dealing with the semantics of XML. If we didn't have to use XML, but just dealt with any kind of XML then indeed inline change tracking would make a lot of sense, but that is not what ODF is. As I said we gave it a fair try, and my conclusion is quite clear from having tried it. Sorry for being blunt. Camilla Boemann

Am 19.07.2012 10:40, schrieb Robin LaFontaine: > Speaking as chair of the Subcommittee, there have been strong requests > for change tracking in spreadsheets and the terms of reference of the > Subcommittee was even wider than this. I note that you have added global > operations and that seems very sensible, although useful operations such > as text-to-table and vice versa will remain untrackable. Would inversion of MCT operations be lossless in an actual scenario, in particular when editing operations kick in which do not get tracked? Best, André

André, On 07/19/2012 08:05 PM, André Rebentisch wrote: Am 19.07.2012 10:40, schrieb Robin LaFontaine: Speaking as chair of the Subcommittee, there have been strong requests for change tracking in spreadsheets and the terms of reference of the Subcommittee was even wider than this. I note that you have added global operations and that seems very sensible, although useful operations such as text-to-table and vice versa will remain untrackable. Would inversion of MCT operations be lossless in an actual scenario, in particular when editing operations kick in which do not get tracked? To the best of my knowledge, intervening "untracked" changes have the same result for all methods of change tracking. When there is a gap in the tracking of changes you have unpredictable results. Hope you are having a great day! Patrick -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

Am 20.07.2012 15:11, schrieb Patrick Durusau: > André, ... > To the best of my knowledge, intervening "untracked" changes have the > same result for all methods of change tracking. > > When there is a gap in the tracking of changes you have unpredictable > results. With change tracking info ignored by the consuming implementation, does the resulting saved XML document core reflect the state before (A) or after (B) changes were carried out? Obviously the former would result in difficulties when change tracking is not implemented by the consuming implementation. Thus you have to save state B and inversed change tracking (undo, "ODF history"). Under MCT we have Svante's original concept with a notion of "inverse operations", undo.xml and .undo directory storage. The premise is that for each "add" operation you have an equivalent "remove" operation: "Every operation has an inverse operation" In a realtime multi-user collaboration environment (from which MCT too inspiration) you would rather want to follow a merge logic, based on a shared source document ("A") and sharing operations, and the analysis of the select committee largely followed a merge perspective in their examples (assumption that inversion was a simple technicality). How do the different approaches satisfy inversibility needs? Best, André

On Fri, 2012-07-20 at 18:31 -0600, André Rebentisch wrote: > Am 20.07.2012 15:11, schrieb Patrick Durusau: > > André, > ... > > To the best of my knowledge, intervening "untracked" changes have the > > same result for all methods of change tracking. > > > > When there is a gap in the tracking of changes you have unpredictable > > results. > > With change tracking info ignored by the consuming implementation, does > the resulting saved XML document core reflect the state before (A) or > after (B) changes were carried out? Obviously the former would result in > difficulties when change tracking is not implemented by the consuming > implementation. Thus you have to save state B and inversed change > tracking (undo, "ODF history"). > > Under MCT we have Svante's original concept with a notion of "inverse > operations", undo.xml and .undo directory storage. The premise is that > for each "add" operation you have an equivalent "remove" operation: > "Every operation has an inverse operation" > > In a realtime multi-user collaboration environment (from which MCT too > inspiration) you would rather want to follow a merge logic, based on a > shared source document ("A") and sharing operations, and the analysis of > the select committee largely followed a merge perspective in their > examples (assumption that inversion was a simple technicality). > > How do the different approaches satisfy inversibility needs? During the last year it was repeatedly stated that an ODF document with change tracking information when read by a consumer that does not understand the change tracking markup should appear as if all changes had been accepted (your case B above). This seems to imply that the document itself must always contain the final product. Since all user actions are obviously reversible provided sufficient information is kept I don't see how there is any huge difference between recording an action or its inverse. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Am 21.07.2012 03:17, schrieb Andreas J. Guelzow: >> How do the different approaches satisfy inversibility needs? > > During the last year it was repeatedly stated that an ODF document with > change tracking information when read by a consumer that does not > understand the change tracking markup should appear as if all changes > had been accepted (your case B above). This seems to imply that the > document itself must always contain the final product. Indeed, so my observation was we are actually not dealing with Merge-CT but Undo-CT, its inversed twin. > Since all user actions are obviously reversible provided sufficient > information is kept I don't see how there is any huge difference between > recording an action or its inverse. Trivial example: A: "Rock Scissors Paper" op1: apply "bold face" to Rock op2: apply "bold face" to Paper op3: apply "bold face" to whole string OR op2: apply "bold face" to S op3: apply "bold face" to Scissors How to undo op3? In the world of "merge" collaboration the task is very convenient and smooth: Take saved state A and apply op1,op2. In a "merge" view complex "user centric changes" (Patrick) are no issue because you can reproduce them one by one based on the source A. With a need for inversed operations you have to translate a "user centric" op3 into what it actually changes and implement "real undo". Implementation of inversion for more complex editing operations may become a bit messy. You may end up with XML diffs even under MCT (replace X by Y operations). Best, André

On Fri, 2012-07-20 at 20:43 -0600, André Rebentisch wrote: > Am 21.07.2012 03:17, schrieb Andreas J. Guelzow: > >> How do the different approaches satisfy inversibility needs? > > > > During the last year it was repeatedly stated that an ODF document with > > change tracking information when read by a consumer that does not > > understand the change tracking markup should appear as if all changes > > had been accepted (your case B above). This seems to imply that the > > document itself must always contain the final product. > > Indeed, so my observation was we are actually not dealing with Merge-CT > but Undo-CT, its inversed twin. > > > Since all user actions are obviously reversible provided sufficient > > information is kept I don't see how there is any huge difference between > > recording an action or its inverse. > > Trivial example: > A: "Rock Scissors Paper" > op1: apply "bold face" to Rock > op2: apply "bold face" to Paper > op3: apply "bold face" to whole string > OR > op2: apply "bold face" to S > op3: apply "bold face" to Scissors > > How to undo op3? In the world of "merge" collaboration the task is very > convenient and smooth: Take saved state A and apply op1,op2. In a > "merge" view complex "user centric changes" (Patrick) are no issue > because you can reproduce them one by one based on the source A. > > With a need for inversed operations you have to translate a "user > centric" op3 into what it actually changes and implement "real undo". > Implementation of inversion for more complex editing operations may > become a bit messy. You may end up with XML diffs even under MCT > (replace X by Y operations). I would think that every editing application already implements undo/redo, so all this "messiness" is already handled within that application. On load or save one would only translate that into appropriate markup. Using some like GCT on the other hand, during save one would need to figure out how the xml changes through the editing op and then encode the xml changes. For applications whose internal data structures don't match ODf this would be significant work. And on load this would even be more difficult. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

On Saturday 21 July 2012 06:06:04 Andreas J. Guelzow wrote: > On Fri, 2012-07-20 at 20:43 -0600, André Rebentisch wrote: > > Am 21.07.2012 03:17, schrieb Andreas J. Guelzow: > > >> How do the different approaches satisfy inversibility needs? > > > > > > During the last year it was repeatedly stated that an ODF document with > > > change tracking information when read by a consumer that does not > > > understand the change tracking markup should appear as if all changes > > > had been accepted (your case B above). This seems to imply that the > > > document itself must always contain the final product. > > > > Indeed, so my observation was we are actually not dealing with Merge-CT > > but Undo-CT, its inversed twin. > > > > > Since all user actions are obviously reversible provided sufficient > > > information is kept I don't see how there is any huge difference > > > between recording an action or its inverse. > > > > Trivial example: > > A: "Rock Scissors Paper" > > > > op1: apply "bold face" to Rock > > op2: apply "bold face" to Paper > > op3: apply "bold face" to whole string > > > > OR > > > > op2: apply "bold face" to S > > op3: apply "bold face" to Scissors > > > > How to undo op3? In the world of "merge" collaboration the task is very > > convenient and smooth: Take saved state A and apply op1,op2. In a > > "merge" view complex "user centric changes" (Patrick) are no issue > > because you can reproduce them one by one based on the source A. > > > > With a need for inversed operations you have to translate a "user > > centric" op3 into what it actually changes and implement "real undo". > > Implementation of inversion for more complex editing operations may > > become a bit messy. You may end up with XML diffs even under MCT > > (replace X by Y operations). > > I would think that every editing application already implements > undo/redo, so all this "messiness" is already handled within that > application. On load or save one would only translate that into > appropriate markup. > > Using some like GCT on the other hand, during save one would need to > figure out how the xml changes through the editing op and then encode > the xml changes. For applications whose internal data structures don't > match ODf this would be significant work. And on load this would even be > more difficult. > > Andreas I couldn't have said this better myself Camilla

Am 21.07.2012 06:06, schrieb Andreas J. Guelzow: > I would think that every editing application already implements > undo/redo, so all this "messiness" is already handled within that > application. "UCT" means Undo capability after (re-)load, not only at runtime: > On load or save one would only translate that into > appropriate markup. Implementations are tasked to document MCT changes as Undo MCT operations, thus safeguard that inversion would be lossless. A useful side effect of U-MCT would be harmonisation of micro-editing and Undo operations. Would it be feasible to transform MCT markup to equivalent E/GCT markup and vise-versa, as the feature matrix implies? > For applications whose internal data structures don't > match ODf this would be significant work. And on load this would even be > more difficult. In the lights that applications generate different markup for the same user-centric editing, they still have to be capable to interpret "MCT editing operations" cross-implementation. Enables also better cross-application messaging for collaborative editing. Very fruitful as an exercise to foster interoperabilty and deeper standardisation! It is also understood why "mere XML tool" implementer won't appreciate MCT. The TC collab working group also evaluated other shortcomings of non-MCT. The MCT approach seems more "cloud-ready". It is great that implementation experience drags the technical debate from the ivory tower of XML format orthodoxy. Best, André

On 20/07/2012 14:11, Patrick Durusau wrote: ... To the best of my knowledge, intervening "untracked" changes have the same result for all methods of change tracking. When there is a gap in the tracking of changes you have unpredictable results. Hope you are having a great day! Patrick A gap may occur because change tracking is turned off or because a change cannot be represented in the change tracking serialization. Does this imply that a change tracking format that does not track all types of change would produce unpredictable results? Robin

Am 25.07.2012 09:53, schrieb Robin LaFontaine: > A gap may occur because change tracking is turned off or because a > change cannot be represented in the change tracking serialization. The SC document mentioned use cases where no tracking occurs, based on the GCT feature matrix. > Does this imply that a change tracking format that does not track all > types of change would produce unpredictable results? Two questions: 1. Do ODF producers "optimize" the XML syntax output? A recent LibO bug with test cases appears to confirm it for this implementation: https://bugs.freedesktop.org/show_bug.cgi?id=52028 The background here is that ODF is not optimized in LibO >3.6a and "autostyle spam" is added to the odf file which leads to kerning issues. 2. Does "optimization" pose a challenge for "inversed" change tracking ("B to A")? Would XML syntax optimization also be tracked? In short CT boils down to: A to B B to A' A != A'? It is easy to see why A' would possibly be never identical to A, this is the "untracked changes" difference. We can still satisfy it by narrowing down the scope, the "tracked window", ignore CT-irrelevant aspects (e.g. timestamp meta data). ODF implementations produce different ODF syntax compliant output! Thus in a cross-application or cross-version roundtrip environment the CT necessitates further efforts for interoperability plug testing. I would expect issues to emerge from implementation imperfection/differences, not the CT as such. Specifying CT would help to tackle the differences. Best, André

On 25/07/2012 13:16, André Rebentisch wrote: Am 25.07.2012 09:53, schrieb Robin LaFontaine: A gap may occur because change tracking is turned off or because a change cannot be represented in the change tracking serialization. The SC document mentioned use cases where no tracking occurs, based on the GCT feature matrix. Does this imply that a change tracking format that does not track all types of change would produce unpredictable results? Two questions: 1. Do ODF producers optimize the XML syntax output? A recent LibO bug with test cases appears to confirm it for this implementation: https://bugs.freedesktop.org/show_bug.cgi?id=52028 The background here is that ODF is not optimized in LibO >3.6a and autostyle spam is added to the odf file which leads to kerning issues. 2. Does optimization pose a challenge for inversed change tracking ( B to A )? Would XML syntax optimization also be tracked? In short CT boils down to: A to B B to A' A != A'? It is easy to see why A' would possibly be never identical to A, this is the untracked changes difference. We can still satisfy it by narrowing down the scope, the tracked window , ignore CT-irrelevant aspects (e.g. timestamp meta data). This is an important point - Rob has made the point elsewhere that it is important to define what 'equality' means and this is particularly difficult in ODF. Two documents that a user might consider to be 'equal' may not contain the same XML. 'Optimization' is one aspect of this and this is done when changes are made to text formatting for example - and some of the SC examples showed that this can simplify the representation of change tracking, though it may add the complication that one change can actually alter a previous change due to this optimization. A canonical form might help but would not be easy to define, e.g. no two automatic styles that are the same, spans not nested... As you say below, CT may help to flush some of these out. Robin ODF implementations produce different ODF syntax compliant output! Thus in a cross-application or cross-version roundtrip environment the CT necessitates further efforts for interoperability plug testing. I would expect issues to emerge from implementation imperfection/differences, not the CT as such. Specifying CT would help to tackle the differences. Best, André --------------------------------------------------------------------- To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-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

Robin, On behalf of the select committee, some notes and comments: On 07/19/2012 04:40 AM, Robin LaFontaine wrote: Questions/comments concerning the Select Committee report on Change Tracking 1. GCT and ECT were proposed and discussed as changes to the ODF format for change tracking, not collaboration. In fairness to those proposals and to create a common basis for comparison, the select committee choose to compare GCT, ECT and MCT as change tracking proposals only. A sensible decision, in line with the TC terms of reference for the Subcommittee. 2. Without implying a decision on syntax, the select committee chose the ETC's feature matrix as the basis for features to be supported by the new change tracking features of ODF (Annex A). Speaking as chair of the Subcommittee, there have been strong requests for change tracking in spreadsheets and the terms of reference of the Subcommittee was even wider than this. I note that you have added global operations and that seems very sensible, although useful operations such as text-to-table and vice versa will remain untrackable. 3. GCT, ECT and MCT all chose different paths but with some minor differences all would satisfy the change tracking use cases. Actually that is incorrect: ECT was unable to satisfy the use cases for spreadsheets. MCT to date has shown solutions for only a small set of use cases. The question facing the TC isn't use cases, although they are useful illustrations. The question facing the TC is what change tracking mechanisms meets present and future needs, across the widest set of implementation models. ODF is the basis for * interoperable interchange * of documents and * not * a processing model. 4. Having said that, however, ECT adds detailed markup in an attempt to make change tracking “easier” which it may do in some view of the format. Lack of verbosity is not a goal for XML but as has been seen from practical experience, performance of XML editors can suffer from overly verbose XML. This implies ECT was rejected on grounds of verbosity. I understand from our conference call that this is not the case so perhaps you could clarify this and be a bit more specific in identifying why ECT was not favoured. Well ECT suffers from the same as GCT. Maybe not in it's current proposal, but in the future when we extend again and again we will end up with an XML format that is even more verbose than GCT. On the other hand ECT offers over GCT a set of changes more tuned to user actions and not to XML changes. At some point in the future the increasing complexity of EEECT XML (extended extended) will possibly be worse than the problems of not having to deal with user centric changes. We say possibly since user centric changes are a big win. Fortunately we don't have to choose (ECT would win) because MCT offers us both eternally simple XML and user centric changes. 5. GCT ... represents a great change to the ODF format. It would require a substantial overhead, both for XML and non-XML implementations of ODF. Particularly when compared to the operations proposal which we discuss below. The select committee cannot recommend GCT as the proposal to “fix” change tracking in ODF. This statement that GCT has a more substantial overhead than MCT seems to be a bold declaration, given that MCT is some considerable way away from being fully defined. Please would you add an explanation of this for the record as you are asking the TC to base the future direction of ODF on this. Also note that there are already two independent implementations of GCT which provide clear evidence that the overhead is not substantial. Have you dismissed this evidence, and if so please explain why? Camilla addressed this issue in a previous post. 6. MCT has been distracting with its emphasis on collaboration issues in a change tracking context. It does offer the cleanest proposal for tracking changes in ODF documents. Please explain what you mean by cleanest . It doesn't mix with the current content. The change tracking is kept separate. The current content of any document is available to an application that can read ODF. Even content changing unaware ones. 7. The first point to be made is that once operations and addressing are defined, the MCT change tracking proposal only requires an understanding of existing ODF markup. As opposed to specification and parsing of additional, “change tracking” markup. My understanding was that MCT would require a new set of markup (for operations and addressing) that would need to be defined for use in undo.xml. Each operation would have its own specific markup, which would need to be defined, parsed and understood by an application. Moreover, the application would need to understand and be tested against the definition of all the operations. Therefore, if that is correct, I suggest that this statement is somewhat misleading. Please provide a more detailed explanation of what you mean here. I beg to differ. Applications already address the components (to be specified) as they already have editing capabilities. All MCT needs to specify is a set of operations (add/delete in my view) to be performed on the components already addressed by applications. Applications will have their own internal models for how they translate the uniform addressing of MCT into their own addressing. Thus, with a minimum of additional XML syntax, MCT leverages existing addressing capabilities of applications to provide an interchangeable tracking of changes. True, MCT needs further specification but that could have already happened but for the distraction of collaboration issues (already noted) and various procedural and foot fault type issues. The select committee was asked to make a recommendation and my colleagues devoted after work hours and weekends to that task. We were not charged with writing a history of every document, email and comment that has occupied the SC for more than a year without any definitive result. We were asked to make a recommendation/decision. We have done so. Questions are more than welcome. Suggestions that the select committee was unaware of the issues, reported in a misleading fashion, etc., are not. Hope everyone is looking forward to a great weekend! Patrick -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

On 20/07/2012 23:55, Patrick Durusau wrote: The question facing the TC is what change tracking mechanisms meets present and future needs, across the widest set of implementation models. ODF is the basis for * interoperable interchange * of documents and * not * a processing model. This is a key issue and I would ask Rob to include it for a discussion today in our call. My understanding is that the scope of ODF includes the processing of documents outside editing applications. Here is the statement of purpose of ODF: https://www.oasis-open.org/committees/office/charter.php Statement of Purpose The purpose of this TC is to create an open, XML-based file format specification for office applications. The resulting file format must meet the following requirements: it must be suitable for office documents containing text, spreadsheets, charts, and graphical documents, it must be compatible with the W3C Extensible Markup Language (XML) v1.0 and W3C Namespaces in XML v1.0 specifications, it must retain high-level information suitable for editing the document, it must be friendly to transformations using XSLT or similar XML-based languages or tools, it should keep the document's content and layout information separate such that they can be processed independently of each other, and it should 'borrow' from similar, existing standards wherever possible and permitted. Item 4 (my bolding) does seem to be very clear about this, I see nothing that limits it to interchange (3) only. The Anticipated Audience (at the end of the charter) also includes makers of XML or office document processing or editing solutions; which again is clear. A lot of our apparent difficulties relate to this issue - we are very much involved with 4 and most of the rest of the TC members with 3. That is why we have different perspectives and why we need to debate and challenge one another in technical discussion. That can be difficult at times! Robin

I have been using XSLT a lot in the past and I see no conflict, in using XSLT with MCT - quite the opposite. Each MCT operation would be related to an XSLT script, which is being triggered using the operation parameter as XSLT argument. Very modular approach with clear interfaces. - Svante On 23.07.2012 13:27, Robin LaFontaine wrote: On 20/07/2012 23:55, Patrick Durusau wrote: The question facing the TC is what change tracking mechanisms meets present and future needs, across the widest set of implementation models. ODF is the basis for * interoperable interchange * of documents and * not * a processing model. This is a key issue and I would ask Rob to include it for a discussion today in our call. My understanding is that the scope of ODF includes the processing of documents outside editing applications. Here is the statement of purpose of ODF: https://www.oasis-open.org/committees/office/charter.php Statement of Purpose The purpose of this TC is to create an open, XML-based file format specification for office applications. The resulting file format must meet the following requirements: it must be suitable for office documents containing text, spreadsheets, charts, and graphical documents, it must be compatible with the W3C Extensible Markup Language (XML) v1.0 and W3C Namespaces in XML v1.0 specifications, it must retain high-level information suitable for editing the document, it must be friendly to transformations using XSLT or similar XML-based languages or tools, it should keep the document's content and layout information separate such that they can be processed independently of each other, and it should 'borrow' from similar, existing standards wherever possible and permitted. Item 4 (my bolding) does seem to be very clear about this, I see nothing that limits it to interchange (3) only. The Anticipated Audience (at the end of the charter) also includes makers of XML or office document processing or editing solutions; which again is clear. A lot of our apparent difficulties relate to this issue - we are very much involved with 4 and most of the rest of the TC members with 3. That is why we have different perspectives and why we need to debate and challenge one another in technical discussion. That can be difficult at times!

Am 23.07.2012 15:25, schrieb Svante Schubert: > I have been using XSLT a lot in the past and I see no conflict, in using > XSLT with MCT - quite the opposite. > Each MCT operation would be related to an XSLT script, which is being > triggered using the operation parameter as XSLT argument. > Very modular approach with clear interfaces. >>> models. ODF is the basis for *interoperable interchange* of documents >>> and *not* a processing model. >> This is a key issue and I would ask Rob to include it for a discussion >> today in our call. ODF 1.2 does include Open Formula which naturally specifies data processing functionality (formula syntax etc.). I sincerely expect future revisions to address OpenForumala underspecification on the functionality side. More flexibility of the ODF Charter to this end, to remove legacy constraints, is appreciated but should not lead to blocking of ongoing technical work. Best, André