OpenDocument - Adv Document Collab SC

Hi, prompted by the recent activity around the two alternative change tracking proposals, let me add the perspective of another implementer (LibreOffice) to this discussion. First off, I'd like to say that I find the generic proposal for conditional modifications of xml elegant and concise - but I'm afraid I cannot see a way to implement it, in a way that ensures sufficient interoperability between different producers and consumers. Here's the crux: because the proposal relies solely on generic modifications of the xml info set (both structurally, by changing the tree, and by modifying attributes), and all those operations are considered valid (section 3, items 6 and 7 of the generic-ct-proposal), the set of semantically distinct editing operations *is unbounded*. Which is a fundamental problem, for all applications that need to map the change tracking markup into their internal, optimized-for-editing document models - because what you have here, is a limited set of editing operations, that are closely related to concrete user actions ("insert" an object, "delete" an object, "merge" two objects - with a very application-specific meaning, that may not map 1:1 to the xml representation). Because of its genericity and expressive power, the generic ct approach would be a very leaky abstraction over a producer's internal representation - i.e. it would be very likely that different applications produce different ct markup, for an otherwise semantically identical user action - then in turn putting the onus of interpreting that action correctly on the consuming application. Cheers, -- Thorsten PGP signature

Hi, Just wanted to give my opinion from an implementation view-point of the generic-ct-proposal. I agree that for some use-cases there may be multiple ways of representing the same change. Some use-cases that I can think of that come under this category are - Paragraph splits - Paragraph with Paragraph merges - Paragraph with Header merges - Header with Paragraph merges However, I have found that all the different ways to represent changes for the above use-cases capture the actual change accurately and precisely. i.e It is possible for an implementation to determine the change unambiguously and thereby to represent that change in it's internal model. It would great to remove the redundancy if possible though. Do you have any specific use-cases other than the above mentioned ones that you had in mind to illustrate this problem ? Thanks, Ganesh On Fri, Apr 1, 2011 at 7:07 AM, Thorsten Behrens <tbehrens@novell.com> wrote: > Hi, > > prompted by the recent activity around the two alternative change > tracking proposals, let me add the perspective of another > implementer (LibreOffice) to this discussion. > > First off, I'd like to say that I find the generic proposal for > conditional modifications of xml elegant and concise - but I'm > afraid I cannot see a way to implement it, in a way that ensures > sufficient interoperability between different producers and > consumers. > > Here's the crux: because the proposal relies solely on generic > modifications of the xml info set (both structurally, by changing > the tree, and by modifying attributes), and all those operations are > considered valid (section 3, items 6 and 7 of the > generic-ct-proposal), the set of semantically distinct editing > operations *is unbounded*. > > Which is a fundamental problem, for all applications that need to > map the change tracking markup into their internal, > optimized-for-editing document models - because what you have here, > is a limited set of editing operations, that are closely related to > concrete user actions ("insert" an object, "delete" an object, > "merge" two objects - with a very application-specific meaning, that > may not map 1:1 to the xml representation). > > Because of its genericity and expressive power, the generic ct > approach would be a very leaky abstraction over a producer's > internal representation - i.e. it would be very likely that > different applications produce different ct markup, for an otherwise > semantically identical user action - then in turn putting the onus > of interpreting that action correctly on the consuming application. > > Cheers, > > -- Thorsten >

On Fri, 2011-04-01 at 12:52 +0530, Ganesh Paramasivam wrote: > Hi, > > Just wanted to give my opinion from an implementation view-point of > the generic-ct-proposal. > > I agree that for some use-cases there may be multiple ways of > representing the same change. Some use-cases that I can think of that > come under this category are > > - Paragraph splits > - Paragraph with Paragraph merges > - Paragraph with Header merges > - Header with Paragraph merges > > However, I have found that all the different ways to represent changes > for the above use-cases capture the actual change accurately and > precisely. i.e It is possible for an implementation to determine the > change unambiguously and thereby to represent that change in it's > internal model. It would great to remove the redundancy if possible > though. I also don't find that the generic proposal being "generic" precludes it from being implemented. It would be nice in some cases to have a canonical, or "preferred" way to express the XML when two or more things are interacting in the generic proposal. > > Do you have any specific use-cases other than the above mentioned ones > that you had in mind to illustrate this problem ? > > Thanks, > Ganesh > > On Fri, Apr 1, 2011 at 7:07 AM, Thorsten Behrens <tbehrens@novell.com> wrote: > > Hi, > > > > prompted by the recent activity around the two alternative change > > tracking proposals, let me add the perspective of another > > implementer (LibreOffice) to this discussion. > > > > First off, I'd like to say that I find the generic proposal for > > conditional modifications of xml elegant and concise - but I'm > > afraid I cannot see a way to implement it, in a way that ensures > > sufficient interoperability between different producers and > > consumers. > > > > Here's the crux: because the proposal relies solely on generic > > modifications of the xml info set (both structurally, by changing > > the tree, and by modifying attributes), and all those operations are > > considered valid (section 3, items 6 and 7 of the > > generic-ct-proposal), the set of semantically distinct editing > > operations *is unbounded*. > > > > Which is a fundamental problem, for all applications that need to > > map the change tracking markup into their internal, > > optimized-for-editing document models - because what you have here, > > is a limited set of editing operations, that are closely related to > > concrete user actions ("insert" an object, "delete" an object, > > "merge" two objects - with a very application-specific meaning, that > > may not map 1:1 to the xml representation). > > > > Because of its genericity and expressive power, the generic ct > > approach would be a very leaky abstraction over a producer's > > internal representation - i.e. it would be very likely that > > different applications produce different ct markup, for an otherwise > > semantically identical user action - then in turn putting the onus > > of interpreting that action correctly on the consuming application. > > > > Cheers, > > > > -- Thorsten > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

monkeyiq wrote: > > However, I have found that all the different ways to represent changes > > for the above use-cases capture the actual change accurately and > > precisely. i.e It is possible for an implementation to determine the > > change unambiguously and thereby to represent that change in it's > > internal model. It would great to remove the redundancy if possible > > though. > > I also don't find that the generic proposal being "generic" precludes it > from being implemented. It would be nice in some cases to have a > canonical, or "preferred" way to express the XML when two or more things > are interacting in the generic proposal. > Hi Ben, well, Ganesh mentions in his implementer's notes that * Paragraph or Header merge with list-items * List-item merges with paragraphs or headers * List-item splits * List-item merges * List merge with another list * Table cell splits * Table cell merges are challenging, and suggests extra mechanisms to handle those - which, to me, seems to support my argument that implementations have a hard time to cope with genericity. I agree that the simple cases, like insertions and deletions of text or paragraphs don't pose problems - but that is not surprising. At any rate, we need to make the hard cases work, and interoperate - otherwise, what's the point in having ct revamped. Cheers, -- Thorsten PGP signature

Thorsten, I think that the point that you make is very interesting, and I think that it is true that implementation of the generic CT proposal would require a different approach within an application. Although the set of semantically distinct editing operations is unbounded as you say, the generic proposal unambiguously represents the state of a document before and after an edit operation. Therefore it supports all types of editing operation. If you take the approach that you are suggesting, whereby the change tracking format supports specific known editing operations such as insert an object or delete an object, then it will be necessary to get agreement amongst all the applications as to what these editing operations are. They will certainly not be the same in all editors, and indeed as each editor is enhanced it may well add editing operations. There is a danger therefore that this approach will always be trying to hit a moving target. With either approach, it will always be the case that a particular application needs to read in a change that it is not able to recognise or is not supported. In this case, it will need to be able to ignore that change in an intelligent way. But this seems to be a fundamental problem, which is present in either approach. This problem may be fundamental, but it can certainly be solved. Regards, Robin On 01/04/2011 02:37, Thorsten Behrens wrote: Hi, prompted by the recent activity around the two alternative change tracking proposals, let me add the perspective of another implementer (LibreOffice) to this discussion. First off, I'd like to say that I find the generic proposal for conditional modifications of xml elegant and concise - but I'm afraid I cannot see a way to implement it, in a way that ensures sufficient interoperability between different producers and consumers. Here's the crux: because the proposal relies solely on generic modifications of the xml info set (both structurally, by changing the tree, and by modifying attributes), and all those operations are considered valid (section 3, items 6 and 7 of the generic-ct-proposal), the set of semantically distinct editing operations *is unbounded*. Which is a fundamental problem, for all applications that need to map the change tracking markup into their internal, optimized-for-editing document models - because what you have here, is a limited set of editing operations, that are closely related to concrete user actions ( insert an object, delete an object, merge two objects - with a very application-specific meaning, that may not map 1:1 to the xml representation). Because of its genericity and expressive power, the generic ct approach would be a very leaky abstraction over a producer's internal representation - i.e. it would be very likely that different applications produce different ct markup, for an otherwise semantically identical user action - then in turn putting the onus of interpreting that action correctly on the consuming application. Cheers, -- Thorsten -- -- ----------------------------------------------------------------- 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 LaFontaine wrote: > Although the set of semantically distinct editing operations is unbounded as > you say, the generic proposal unambiguously represents the state of a document > before and after an edit operation. Therefore it supports all types of editing > operation. > Hi Robin, yeah, I'm not disputing that. :) > If you take the approach that you are suggesting, whereby the change tracking > format supports specific known editing operations such as insert an object or > delete an object, then it will be necessary to get agreement amongst all the > applications as to what these editing operations are. They will certainly not > be the same in all editors, and indeed as each editor is enhanced it may well > add editing operations. There is a danger therefore that this approach will > always be trying to hit a moving target. > True, that would be a drawback - but potentially we could come up with a set of _basic_ ops, that apps could then use to compose more complex changes of - quite similar to the generic ct's atomic changes, but with a (much) lower impedance towards app's editing semantics? > With either approach, it will always be the case that a particular application > needs to read in a change that it is not able to recognise or is not supported. > Hm. With the generic proposal, apps would never be provably able to handle all cases (unless processing is very close, or on, the xml info set). Whereas for a bounded set of ops, one would at least be able to state "we don't support X, Y, Z yet" - and eventually get there. Cheers, -- Thorsten PGP signature

On Sun, 2011-04-03 at 00:00 +0200, Thorsten Behrens wrote: > Hm. With the generic proposal, apps would never be provably able to > handle all cases (unless processing is very close, or on, the xml > info set). Whereas for a bounded set of ops, one would at least be > able to state "we don't support X, Y, Z yet" - and eventually get > there. Perhaps having one or more "levels of compliance" for the generic proposal. Each level listing explicitly what of the generic change tracking must be supported for use cases. Something like "light" being * text insert, update, delete. * para split/merge * text style tracking And "Basic" being light plus * delta:merge for table and figures, including cases of whole table deletion. * ac:change recording of ODF attributes (insert-list-here). And "Document Computing" level including a bunch more explicit use cases which would be desired for serious document modifications. But I'm likely not the one to define these classes. This would give a concrete, bounded target, an app would need to support generic change tracking (GCT) on certain attributes and elements which are explicitly listed in a compliance level. This gives an explicit bound on what is needed and apps of a compliance level should interoperate as they know what each should support. Of course, if an app uses GCT for more attributes or document modifications then that's great too. I would imagine that other apps would add support to match that support as time goes by. > > Cheers, > > -- Thorsten

Hi Thorsten On 01.04.2011 03:37, Thorsten Behrens wrote: Here's the crux: because the proposal relies solely on generic modifications of the xml info set (both structurally, by changing the tree, and by modifying attributes), and all those operations are considered valid (section 3, items 6 and 7 of the generic-ct-proposal), the set of semantically distinct editing operations *is unbounded*. Which is a fundamental problem, for all applications that need to map the change tracking markup into their internal, optimized-for-editing document models - because what you have here, is a limited set of editing operations, that are closely related to concrete user actions ( insert an object, delete an object, merge two objects - with a very application-specific meaning, that may not map 1:1 to the xml representation). I'm not sure if I got you correctly. You consider it problematic that there might be change transactions in the document that do not match basic user actions. So you are basically referring to a) the ability of grouping arbitrary changes because this most like does not match any basic user action and b) the ability to add/delete/change attributes of an element, right? Because all the other cases seem to represent concrete office productivity user actions. Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment

Hi Frank, you wrote: > I'm not sure if I got you correctly. You consider it problematic > that there might be change transactions in the document that do not > match basic user actions. > No. I consider it problematic that there's no limit to the creativity in producing *atomic* changes - an application would be perfectly allowed to delete ~all content of a huge document at once, with only one delta:remove-leaving-content-*, and even more arcane stuff - and you and me would end up trying to break that down to something Writer understands. ;) Cheers, -- Thorsten PGP signature

Hi Thorsten, On 04.04.2011 22:50, Thorsten Behrens wrote: 20110404205016.GC16085@thinkpad.thebehrens.net type= cite > No. I consider it problematic that there's no limit to the creativity in producing *atomic* changes - an application would be perfectly allowed to delete ~all content of a huge document at once, with only one delta:remove-leaving-content-*, and even more arcane stuff - and you and me would end up trying to break that down to something Writer understands. ;) You mean delta:removed-content: <office:body>   <office:text>       <delta:removed-content ...>               <text:p>...</text:p>               ....       </delta:removed-content ...>   </office:text> </office:body> Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment

Hi Frank, you wrote: > You mean delta:removed-content: > > <office:body> > <office:text> > <delta:removed-content ...> > <text:p>...</text:p> > .... > </delta:removed-content ...> > </office:text> > </office:body> > No, the thing I had in mind was more like <office:body> <office:text> <delta:remove-leaving-content-start ...> <...> <...> <...> .... </...> </...> <...> .... </...> . . . </delta:remove-leaving-content-start ...> <...> .... </...> <delta:remove-leaving-content-end .../> </office:text> </office:body> For making ct transactions individually acceptable and rejectable, of course also the inverse, modulo nested added / removed content inside the delta:remove-leaving-content-start block, action needs to be possible inside the application core - i.e. you *will* need to transform that xml into actionable editing instructions on the internal document model, i.e. be able to glean the semantics of that markup on your doc ... So I maintain that, for being implementable with reasonable effort, via a non-xml-based representation, the generic ct is heavily under-constrained. :) Cheers, -- Thorsten PGP signature

Hi Thorsten, On 06.04.2011 11:03, Thorsten Behrens wrote: 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > No, the thing I had in mind was more like <office:body> <office:text> <delta:remove-leaving-content-start ...> <...> <...> <...> .... </...> </...> <...> .... </...> . . . </delta:remove-leaving-content-start ...> <...> .... </...> <delta:remove-leaving-content-end .../> </office:text> </office:body> but as far as I understood delta:remove-leaving-content, it is intended to remove *only one* element without touching the content (this of course needs to be specified precisely, see below), and if you actually remove the element, the resulting ODF must be valid. So the only possible use cases that I can imagine for this is removing a span and removing a plain section but leaving the content as is (and I'd drop the second one because it is not very common). 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > For making ct transactions individually acceptable and rejectable, of course also the inverse, modulo nested added / removed content inside the delta:remove-leaving-content-start block, action needs to be possible inside the application core - i.e. you *will* need to transform that xml into actionable editing instructions on the internal document model, i.e. be able to glean the semantics of that markup on your doc ... Yes, sure. 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > So I maintain that, for being implementable with reasonable effort, via a non-xml-based representation, the generic ct is heavily under-constrained. :) Well, yes, that's what I also asked for in one of my first mails (see http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00002.html ). Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment

Frank Meies wrote: > >So I maintain that, for being implementable with reasonable effort, > >via a non-xml-based representation, the generic ct is heavily > >under-constrained. :) > > Well, yes, that's what I also asked for in one of my first mails > (see http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00002.html ). > Hi Frank, well yeah, indirectly - of course, the need of constraining the generic ct so much could kill most of the elegance of that proposal, so I wonder if it's the right tool for this job. I.e. it seems likely we would end up with something like the extended ct, but expressed by means of the generic ct markup. ;) Cheers, -- Thorsten PGP signature

Frank is correct: the element delta:remove-leaving-content-start contains ONLY the start tag (as an empty element) of an element that has been removed leaving its content. So Thorsten's example should be more like: <office:body> <office:text> <delta:remove-leaving-content-start ...> <foo/> </delta:remove-leaving-content-start ...>  <...> [all this original content of <foo> must be allowed not only in foo but also in office:text, as Frank notes]     ....  </...> <delta:remove-leaving-content-end .../> </office:text> </office:body> Note also section 7.2.1 to 7.2.3 of the generic-ct-proposal contains details of some constraints that will always be applicable, so the generic proposal is not a 'free for all'. Of course, as has been suggested, there could be more constraints for ODF. We did make some modifications to the relaxng schema to cover the use case samples, and this would need to be extended to the rest of the schema. There is a choice about how this is done of course, and specific delta elements could be disallowed in specific places as deemed necessary to constrain it. Another constraint method would be to identify the edit operation types as meta data in the change-transaction, e.g. 'global word replacement', and then constrain this to contain only text additions and deletions (that would need schematron I think, it could not be done by relaxng). Regards, Robin On 06/04/2011 10:38, Frank Meies wrote: 4D9C34A0.9080701@oracle.com type= cite > Hi Thorsten, On 06.04.2011 11:03, Thorsten Behrens wrote: 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > No, the thing I had in mind was more like <office:body> <office:text> <delta:remove-leaving-content-start ...> <...> <...> <...> .... </...> </...> <...> .... </...> . . . </delta:remove-leaving-content-start ...> <...> .... </...> <delta:remove-leaving-content-end .../> </office:text> </office:body> but as far as I understood delta:remove-leaving-content, it is intended to remove *only one* element without touching the content (this of course needs to be specified precisely, see below), and if you actually remove the element, the resulting ODF must be valid. So the only possible use cases that I can imagine for this is removing a span and removing a plain section but leaving the content as is (and I'd drop the second one because it is not very common). 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > For making ct transactions individually acceptable and rejectable, of course also the inverse, modulo nested added / removed content inside the delta:remove-leaving-content-start block, action needs to be possible inside the application core - i.e. you *will* need to transform that xml into actionable editing instructions on the internal document model, i.e. be able to glean the semantics of that markup on your doc ... Yes, sure. 20110406090330.GD31629@thinkpad.thebehrens.net type= cite > So I maintain that, for being implementable with reasonable effort, via a non-xml-based representation, the generic ct is heavily under-constrained. :) Well, yes, that's what I also asked for in one of my first mails (see http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00002.html ). Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment -- -- ----------------------------------------------------------------- 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

Would something like this give us the benefits of both approaches: 1) Specify the complete DeltaXML generic proposal, but in its own separate "part" of the standard. 2) Then in the conformance clause for ODF, reference a subset of these capabilities for use in conforming ODF documents. For example, we could enumerate the specific places in ODF where the change tracking is allowed. Maybe schema annotations could be used for this. 3) In "extended ODF documents" allow the unconstrainted general use of the change tracking features. This matches how we treat extensibility in ODF 1.2. We have an unlimited extensibility mechanism (foreign elements) that is difficult for any processor to handle in a generic way. But this is only allowed in extended documents. For non-extended documents we allow only specific kinds of extensions, e.g., RDF metadata, application settings, etc. -Rob Thorsten Behrens <tbehrens@novell.com> wrote on 04/04/2011 04:50:16 PM: > > you wrote: > > I'm not sure if I got you correctly. You consider it problematic > > that there might be change transactions in the document that do not > > match basic user actions. > > > No. I consider it problematic that there's no limit to the > creativity in producing *atomic* changes - an application would be > perfectly allowed to delete ~all content of a huge document at once, > with only one delta:remove-leaving-content-*, and even more arcane > stuff - and you and me would end up trying to break that down to > something Writer understands. ;) >

Hi Rob, yes, this would be an option. For example, there might be a use case for tracking the insertion of an unused automatic style in a document, but most likely not in the scope of collaborative document editing. Regards, Frank On 05.04.2011 15:10, robert_weir@us.ibm.com wrote: OF13B244CC.4E15FADA-ON85257869.00477D8E-85257869.0047F7CB@lotus.com type= cite > Would something like this give us the benefits of both approaches: 1) Specify the complete DeltaXML generic proposal, but in its own separate part of the standard. 2) Then in the conformance clause for ODF, reference a subset of these capabilities for use in conforming ODF documents. For example, we could enumerate the specific places in ODF where the change tracking is allowed. Maybe schema annotations could be used for this. 3) In extended ODF documents allow the unconstrainted general use of the change tracking features. This matches how we treat extensibility in ODF 1.2. We have an unlimited extensibility mechanism (foreign elements) that is difficult for any processor to handle in a generic way. But this is only allowed in extended documents. For non-extended documents we allow only specific kinds of extensions, e.g., RDF metadata, application settings, etc. -Rob Thorsten Behrens <tbehrens@novell.com> wrote on 04/04/2011 04:50:16 PM: you wrote: I'm not sure if I got you correctly. You consider it problematic that there might be change transactions in the document that do not match basic user actions. No. I consider it problematic that there's no limit to the creativity in producing *atomic* changes - an application would be perfectly allowed to delete ~all content of a huge document at once, with only one delta:remove-leaving-content-*, and even more arcane stuff - and you and me would end up trying to break that down to something Writer understands. ;) -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment

Yes, Rob, I think your suggestion, or something along those lines, would be a good solution, and does seem to capture the strengths of the two approaches. 1. If the generic proposal is a separate part of the standard then it is available for use in the ODF standard and elsewhere. In theory any other XML standard could adopt the generic ct proposal for change tracking, and that would seem to be a useful contribution to the XML standards world. Note that although Level 2 is directed specifically at documents, Level 1 is well suited to XML data. 2. A conformance clause, restricting where it can be used, could be implemented in the RelaxNG schema quite well, there is no need to allow a free-for-all use of the syntax everywhere. Constraining a general mechanism gives a well-defined extension route - just reduce the constraints, which seems to be easier than inventing new syntax for each new change tracking requirement. 3. There are use cases that could use this certainly - when two documents are compared it would be good to be able to represent ALL changes, for example for verification and testing, or audit control. Converting this back to a conforming document, i.e. more restricted use of the change tracking, could be done with a standard XSLT script I believe. Robin On 05/04/2011 14:10, robert_weir@us.ibm.com wrote: OF13B244CC.4E15FADA-ON85257869.00477D8E-85257869.0047F7CB@lotus.com type= cite > Would something like this give us the benefits of both approaches: 1) Specify the complete DeltaXML generic proposal, but in its own separate part of the standard. 2) Then in the conformance clause for ODF, reference a subset of these capabilities for use in conforming ODF documents. For example, we could enumerate the specific places in ODF where the change tracking is allowed. Maybe schema annotations could be used for this. 3) In extended ODF documents allow the unconstrainted general use of the change tracking features. This matches how we treat extensibility in ODF 1.2. We have an unlimited extensibility mechanism (foreign elements) that is difficult for any processor to handle in a generic way. But this is only allowed in extended documents. For non-extended documents we allow only specific kinds of extensions, e.g., RDF metadata, application settings, etc. -Rob Thorsten Behrens <tbehrens@novell.com> wrote on 04/04/2011 04:50:16 PM: you wrote: I'm not sure if I got you correctly. You consider it problematic that there might be change transactions in the document that do not match basic user actions. No. I consider it problematic that there's no limit to the creativity in producing *atomic* changes - an application would be perfectly allowed to delete ~all content of a huge document at once, with only one delta:remove-leaving-content-*, and even more arcane stuff - and you and me would end up trying to break that down to something Writer understands. ;) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- -- ----------------------------------------------------------------- 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