OpenDocument - Adv Document Collab SC

GCT Issues Wiki page I have put together a wiki page [1] detailing the issues identified with GCT and any actions/responses to these. Please review this and check if there are any that I may have omitted and feel free to add them. Please do raise anything that needs discussion on this email list referencing the issue but the wiki is the main repository to be used in the consensus report. I am working on a similar page for ECT issues though of course anyone else is welcome to do it! Best regards, Robin [1] http://wiki.oasis-open.org/office/GCT%20%28Generic%20CT%29%20Issues%20for%20consensus%20report -- -- ----------------------------------------------------------------- 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

On Wed, 2011-08-24 at 07:19 -0600, Robin LaFontaine wrote: > Please do raise anything that needs discussion on this email list > referencing the issue GCT-Issue-1: I fail to see how the suggestion described in http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00024.html would solve this issue. From a user perspective there is no obvious distinction between conforming ODF documents and extended-conforming ODF documents, nor are there any obvious markers inside the file other than that a consumer will suddenly encounter an element or attribute it does not expect. Typically extended-conforming documents can be sensibly read by ignoring the extension. One cannot sensibly read change tracking information by ignoring some of the change tracking info. GCT-Issue-2: IMHO, amending the proposal to include information on which editing operation is represented essentially changes the character of GCT to something more like ECT. So isn't this response really a statement that ECT in principle cannot work? In the related message http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00049.html asks the question "2) Do we need to differentiate between two actions that have the same effect on the document?" I would like to answer this with a clear yes. Refering to the example that lead to that question, if a user deletes column K, the user may be quite disturbed if the change tracking lists a deletion of column B. GCT-Issue-4: I fail to see why "The notion that an edit operation would be a short form seems attractive but it also needs to be reversible to undo and then a small operation becomes big because of the cacheing needed." would be correct. Referring to the example, the undo of "insert row" is simply a "delete row", so how does it suddenly become big? To undo a delete row one of course need to store the content of that row and a list of changes caused elsewhere. With respect to Rob's comment on this issue, while using R1C1 cell addressing would indeed leave more _relative_ cell addresses unchanged (it has no effect on absolute addresses), recording the editing operations rather than the result on the xml representation of the document would be much shorter. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta

On 24/08/2011 16:13, Andreas J. Guelzow wrote: > > GCT-Issue-1: > > I fail to see how the suggestion described in > http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00024.html would solve this issue. > > From a user perspective there is no obvious distinction between > conforming ODF documents and extended-conforming ODF documents, nor are > there any obvious markers inside the file other than that a consumer > will suddenly encounter an element or attribute it does not expect. It would make sense for there to be an indication in the document as to its status, conforming or non-conforming, to help the reader. A consumer of ODF could specify that it does not read extended-conforming documents, that would be clear and reasonable. I am not sure what you mean by 'user' here. A producer of ODF documents could provide an output that is either conforming or extended-conforming. For example, if we compare two documents we could generate a result that ignored some changes and only listed those that were 'conforming'. Similarly an application that could track non-conforming changes could generate a conforming output. The reason for allowing extended-conforming is to allow development of interoperability within a constrained and defined framework. > Typically extended-conforming documents can be sensibly read by ignoring > the extension. One cannot sensibly read change tracking information by > ignoring some of the change tracking info. I would expect that an application that did not understand formatting changes, for example, could read a change-tracked document and ignore the format changes while at the same time understanding the text changes. Some intelligence in the reader may be needed to do this, but not too much. > ..snip > > Andreas > -- -- ----------------------------------------------------------------- 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

On 24/08/2011 16:13, Andreas J. Guelzow wrote: > GCT-Issue-2: > IMHO, amending the proposal to include information on which editing > operation is represented essentially changes the character of GCT to > something more like ECT. So isn't this response really a statement that > ECT in principle cannot work? (Note: I think you meant to say So isn't this response really a statement that GCT in principle cannot work? ) Please see http://lists.oasis-open.org/archives/office-collab/201106/msg00010.html for a general comment on approach. The principle here is that GCT provides a generic method to represent any change, and by adding meta-data to describe the editing action, and any relevant constraints, it can represent any specific editing operation and thus resolve this objection, while at the same time having the advantage of 'extended-conforming' per GCT-Issue-1. GCT still differs fundamentally from ECT in many ways, and we need to highlight these in the consensus report. I believe a generic method with constraints (like XML with a schema) is fundamentally a better approach than customized solution for each use case. This is especially so for a large schema such as ODF. 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

On Fri, 2011-08-26 at 11:13 -0600, Robin LaFontaine wrote: > On 24/08/2011 16:13, Andreas J. Guelzow wrote: > > GCT-Issue-2: > > IMHO, amending the proposal to include information on which editing > > operation is represented essentially changes the character of GCT to > > something more like ECT. So isn't this response really a statement that > > ECT in principle cannot work? > > (Note: I think you meant to say > So isn't this response really a statement that > GCT in principle cannot work? > ) Yes of course I meant to say ...GCT... > > Please see > http://lists.oasis-open.org/archives/office-collab/201106/msg00010.html > for a general comment on approach. I had obviously read that message before. Unfortunately we do not even seem to agree on the basic concepts. For me a document has many ODF xml representations and changing between those representations does not represent a document change, so while GCT may be well suited to for recording changes in the representation I fail to see how it can be used successfully to recognize changes to the document itself. > > The principle here is that GCT provides a generic method to represent > any change, and by adding meta-data to describe the editing action, and > any relevant constraints, it can represent any specific editing > operation and thus resolve this objection, while at the same time having > the advantage of 'extended-conforming' per GCT-Issue-1. > > GCT still differs fundamentally from ECT in many ways, and we need to > highlight these in the consensus report. > > I believe a generic method with constraints (like XML with a schema) is > fundamentally a better approach than customized solution for each use > case. This is especially so for a large schema such as ODF. I think there is fundamentally a difference between recording document changes and recording changes in xml-representation. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta This is a digitally signed message part

I am worried by your comment a document has many ODF xml representations because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? Robin On 26/08/2011 19:46, Andreas J. Guelzow wrote: I had obviously read that message before. Unfortunately we do not even seem to agree on the basic concepts. For me a document has many ODF xml representations and changing between those representations does not represent a document change, so while GCT may be well suited to for recording changes in the representation I fail to see how it can be used successfully to recognize changes to the document itself. > -- -- ----------------------------------------------------------------- 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

On Fri, 2011-09-02 at 10:10 -0600, Robin LaFontaine wrote: > I am worried by your comment > "a document has many ODF xml representations" > because if the same document has many representations it is difficult > to say when two documents are 'equal' or the same document. If we do > not know when they are the same we cannot say what has changed. I agree. Isn't that the point of change _tracking_. We know what changes when the change is made. If you compare two files there would be lots of possible differences in the xml representation that do not change the document. For example: -- Changes in the names of any automatic styles. -- Changes to repeated-rows (or columns), ie, any such could be split into rseparate rows -- Various issue related to <text:s> -- some attribute orders and many more. > > I am making the assumption that if the XML representation of two > documents is different then the documents are different. Of course > some differences (e.g. text content) are more important that others > (e.g. automatic styles). If this basic assumption is wrong then > perhaps we need to define a canonical form. Or is there some other way > forward? As I said above we know document changes when they are performed. We should not care (I at least I do not care) about changes in the xml representation. Andreas > -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta

I understand what you say about change _tracking_ but there is a use case of document comparison that also needs to be satisfied (a user expects to be able to compare docs and see the changes). I agree not all changes are significant, Rob lists some different types of change. It seems to me that the spec should say when two documents can be considered the same, otherwise we are all making our own (different!) assumptions about this. Perhaps we should ask the TC to clarify this? It seems important for us in the SC to have an answer. Robin On 02/09/2011 18:24, Andreas J. Guelzow wrote: 1314984298.692.8.camel@kirkman type= cite > On Fri, 2011-09-02 at 10:10 -0600, Robin LaFontaine wrote: I am worried by your comment a document has many ODF xml representations because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. I agree. Isn't that the point of change _tracking_. We know what changes when the change is made. If you compare two files there would be lots of possible differences in the xml representation that do not change the document. For example: -- Changes in the names of any automatic styles. -- Changes to repeated-rows (or columns), ie, any such could be split into rseparate rows -- Various issue related to <text:s> -- some attribute orders and many more. I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? As I said above we know document changes when they are performed. We should not care (I at least I do not care) about changes in the xml representation. Andreas -- -- ----------------------------------------------------------------- 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

I'm startled by this reaction. It is a commonplace that there can be different XML representations of an ODF document that make no perceptible difference for an user. And even perceptible differences may be immaterial. Also, when a document is edited and saved, the representation may change. These might be immaterial for interoperability. Some variations may be more significant but possibly immaterial in a given interoperability setting. Contributing factors include the following: * Compliance requirements for ODF consumers are very loose * Different producers may favor one representation over another among semantically-equivalent representations * There is a wide range of implementation-defined deviations * Users use provisions of producers to achieve the content and appearance that they want, without awareness of how the XML reflects that or how different ways that they accomplish some objective may lead to invisibly-different document representations. * Many processors do not use an internal model by which the XML is retained; it is generated on output from an internal model. That can produce different results on something as simple as a load followed by a save. * There is no specified layout behavior, or presentation of tracked changes in terms of an implementation's layout, so there is deviation simply between what an author did and what a reader, editor, or co-author sees. * How material any of this is depends on the situation. It is one force that leads people to stick to a single product and sometimes a specific release of a single product because of variations that can occur from one release to another. Users also adapt to bugs and then have to deal with the breakage that occurs when the bug is fixed.
Original Message----- From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] Sent: Friday, September 02, 2011 09:10 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) I am worried by your comment "a document has many ODF xml representations" because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? Robin On 26/08/2011 19:46, Andreas J. Guelzow wrote: I had obviously read that message before. Unfortunately we do not even seem to agree on the basic concepts. For me a document has many ODF xml representations and changing between those representations does not represent a document change, so while GCT may be well suited to for recording changes in the representation I fail to see how it can be used successfully to recognize changes to the document itself. > -- -- ----------------------------------------------------------------- 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 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

I would be quite content if there was a definition for some of your terms, see below. On 02/09/2011 20:39, Dennis E. Hamilton wrote: 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > I'm startled by this reaction. It is a commonplace that there can be different XML representations of an ODF document that make no perceptible difference for an user. And even perceptible differences may be immaterial. Also, when a document is edited and saved, the representation may change. These might be immaterial for interoperability. Some variations may be more significant but possibly immaterial in a given interoperability setting. If we are not all to guess about this, the spec needs to tell us which are material and which are not. YMMV in a   big way here! 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > Contributing factors include the following: * Compliance requirements for ODF consumers are very loose * Different producers may favor one representation over another among semantically-equivalent representations Where is the definition of 'semantically-equivalent'? 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > * There is a wide range of implementation-defined deviations Deviations from the standard? What is permissible and what is not? (Rhetorical questions) 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > * Users use provisions of producers to achieve the content and appearance that they want, without awareness of how the XML reflects that or how different ways that they accomplish some objective may lead to invisibly-different document representations. * Many processors do not use an internal model by which the XML is retained; it is generated on output from an internal model. That can produce different results on something as simple as a load followed by a save. Yes, I fully agree, but we should define when this is a non-compliance (if the load/save removes a few words that would seem to be a problem, if it changes auto styles this may not be a problem). 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > * There is no specified layout behavior, or presentation of tracked changes in terms of an implementation's layout, so there is deviation simply between what an author did and what a reader, editor, or co-author sees. Good point! 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite > * How material any of this is depends on the situation. It is one force that leads people to stick to a single product and sometimes a specific release of a single product because of variations that can occur from one release to another. Users also adapt to bugs and then have to deal with the breakage that occurs when the bug is fixed. I agree very much with this, and this is holding up adoption of the standard... because there are lots of different but apparently valid interpretations. The ability for a user to move his/her document from one editing application to another is limited at the present time for the reasons you give. 00b301cc69a8$07f80a20$17e81e60$@acm.org type= cite >
Original Message----- From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] Sent: Friday, September 02, 2011 09:10 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) I am worried by your comment a document has many ODF xml representations because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? Robin On 26/08/2011 19:46, Andreas J. Guelzow wrote: I had obviously read that message before. Unfortunately we do not even seem to agree on the basic concepts. For me a document has many ODF xml representations and changing between those representations does not represent a document change, so while GCT may be well suited to for recording changes in the representation I fail to see how it can be used successfully to recognize changes to the document itself. > -- -- ----------------------------------------------------------------- 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

See Rob's explanation if that makes more sense. At this point in the life of ODF, there is no way that the ODF TC can undertake define when two ODF representations are for the same documents. And there are comparison tools that work at the document (not XML level). OpenOffice.org has one built in. They've been in all flavors of Microsoft Office for years. (I imagine they might even compare a .doc and a .docx, who knows?!). They make it look like one was produced from the other (user choice) by change tracking. Imagine that! - Dennis
Original Message----- From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] Sent: Tuesday, September 06, 2011 04:33 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) I would be quite content if there was a definition for some of your terms, see below. On 02/09/2011 20:39, Dennis E. Hamilton wrote: I'm startled by this reaction. It is a commonplace that there can be different XML representations of an ODF document that make no perceptible difference for an user. And even perceptible differences may be immaterial. Also, when a document is edited and saved, the representation may change. These might be immaterial for interoperability. Some variations may be more significant but possibly immaterial in a given interoperability setting. If we are not all to guess about this, the spec needs to tell us which are material and which are not. YMMV in a big way here! Contributing factors include the following: * Compliance requirements for ODF consumers are very loose * Different producers may favor one representation over another among semantically-equivalent representations Where is the definition of 'semantically-equivalent'? * There is a wide range of implementation-defined deviations Deviations from the standard? What is permissible and what is not? (Rhetorical questions) * Users use provisions of producers to achieve the content and appearance that they want, without awareness of how the XML reflects that or how different ways that they accomplish some objective may lead to invisibly-different document representations. * Many processors do not use an internal model by which the XML is retained; it is generated on output from an internal model. That can produce different results on something as simple as a load followed by a save. Yes, I fully agree, but we should define when this is a non-compliance (if the load/save removes a few words that would seem to be a problem, if it changes auto styles this may not be a problem). * There is no specified layout behavior, or presentation of tracked changes in terms of an implementation's layout, so there is deviation simply between what an author did and what a reader, editor, or co-author sees. Good point! * How material any of this is depends on the situation. It is one force that leads people to stick to a single product and sometimes a specific release of a single product because of variations that can occur from one release to another. Users also adapt to bugs and then have to deal with the breakage that occurs when the bug is fixed. I agree very much with this, and this is holding up adoption of the standard... because there are lots of different but apparently valid interpretations. The ability for a user to move his/her document from one editing application to another is limited at the present time for the reasons you give.
Original Message----- From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] Sent: Friday, September 02, 2011 09:10 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) I am worried by your comment "a document has many ODF xml representations" because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? Robin On 26/08/2011 19:46, Andreas J. Guelzow wrote: I had obviously read that message before. Unfortunately we do not even seem to agree on the basic concepts. For me a document has many ODF xml representations and changing between those representations does not represent a document change, so while GCT may be well suited to for recording changes in the representation I fail to see how it can be used successfully to recognize changes to the document itself. > -- -- ----------------------------------------------------------------- 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 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

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 09/06/2011 09:45:16 AM: > > See Rob's explanation if that makes more sense. > > At this point in the life of ODF, there is no way that the ODF TC > can undertake define when two ODF representations are for the same documents. > We can start with Canonical XML [1]. From there we could easily define canonicalization of inter-document references, e.g., styles. We could define canonical ordering of items in ZIP, etc. So there are some things we could define. But it is not clear how far up the semantic chain we would take it. For example, there is some freedom where we put style definitions. Is that a "real" difference? It is if we define it to be. I wouldn't be too concerned about app-to-app rendering differences. That is a different problem. But if doc 1 has a blue rectangle and doc 2 has a green oval, then the docs are different, even if some screwed up app fails to render them correctly. This is true even if the spec doesn't even define how they should be rendered. [1]: http://www.w3.org/TR/xml-c14n > And there are comparison tools that work at the document (not XML > level). OpenOffice.org has one built in. They've been in all > flavors of Microsoft Office for years. (I imagine they might even > compare a .doc and a .docx, who knows?!). They make it look like > one was produced from the other (user choice) by change tracking. > Imagine that! > > - Dennis > >
Original Message----- > From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > Sent: Tuesday, September 06, 2011 04:33 > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > > I would be quite content if there was a definition for some of your > terms, see below. > > On 02/09/2011 20:39, Dennis E. Hamilton wrote: > > I'm startled by this reaction. > > It is a commonplace that there can be different XML > representations of an ODF document that make no perceptible > difference for an user. And even perceptible differences may be immaterial. > > Also, when a document is edited and saved, the representation > may change. These might be immaterial for interoperability. Some > variations may be more significant but possibly immaterial in a > given interoperability setting. > > If we are not all to guess about this, the spec needs to tell us > which are material and which are not. YMMV in a big way here! > > > > Contributing factors include the following: > > * Compliance requirements for ODF consumers are very loose > * Different producers may favor one representation over another > among semantically-equivalent representations > > Where is the definition of 'semantically-equivalent'? > > > * There is a wide range of implementation-defined deviations > > Deviations from the standard? What is permissible and what is not? > (Rhetorical questions) > > > * Users use provisions of producers to achieve the content and > appearance that they want, without awareness of how the XML reflects > that or how different ways that they accomplish some objective may > lead to invisibly-different document representations. > * Many processors do not use an internal model by which the XML > is retained; it is generated on output from an internal model. That > can produce different results on something as simple as a load > followed by a save. > > Yes, I fully agree, but we should define when this is a non- > compliance (if the load/save removes a few words that would seem to > be a problem, if it changes auto styles this may not be a problem). > > > * There is no specified layout behavior, or presentation of > tracked changes in terms of an implementation's layout, so there is > deviation simply between what an author did and what a reader, > editor, or co-author sees. > > Good point! > > > * How material any of this is depends on the situation. It is > one force that leads people to stick to a single product and > sometimes a specific release of a single product because of > variations that can occur from one release to another. Users also > adapt to bugs and then have to deal with the breakage that occurs > when the bug is fixed. > > I agree very much with this, and this is holding up adoption of the > standard... because there are lots of different but apparently valid > interpretations. The ability for a user to move his/her document > from one editing application to another is limited at the present > time for the reasons you give. > > > > >
Original Message----- > From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > Sent: Friday, September 02, 2011 09:10 > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > > I am worried by your comment > > "a document has many ODF xml representations" > because if the same document has many representations it is > difficult to say when two documents are 'equal' or the same > document. If we do not know when they are the same we cannot say > what has changed. > > I am making the assumption that if the XML representation of two > documents is different then the documents are different. Of course > some differences (e.g. text content) are more important that others > (e.g. automatic styles). If this basic assumption is wrong then > perhaps we need to define a canonical form. Or is there some other > way forward? > > Robin > > On 26/08/2011 19:46, Andreas J. Guelzow wrote: > > I had obviously read that message before. Unfortunately we do not even > seem to agree on the basic concepts. For me a document has many ODF xml > representations and changing between those representations does not > represent a document change, so while GCT may be well suited to for > recording changes in the representation I fail to see how it can be used > successfully to recognize changes to the document itself. > > > > > > > > -- > -- ----------------------------------------------------------------- > 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 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 > > > --------------------------------------------------------------------- > 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 > S/MIME Cryptographic Signature

Rob, From below: > I wouldn't be too concerned about app-to-app rendering differences. That > is a different problem. I am not sure if you mean with reference to how (1) changes are displayed or (2) in general. If (1): With regard to changes, that certainly is app specific and could be an area where apps compete to have useful display of changes. I can think of several choices that I would like better than current offerings. If (2): I think we have an opportunity to more specifically say how ODF documents should be rendered. Not *how* they get rendered but how they should appear. Users see that as interoperability and to some degree rightly so. They intend for the same input (the ODF documents) to have the same result when processed by a conforming application with the same capabilities. That's really not unreasonable. How far we can go towards that goal with every release remains to be seen. Hopefully applications are going to "stay ahead" of the markup in some ways so that user demands are in part driving the XML that we develop to encode their needs. Hope you are having a great day! Patrick On 9/6/2011 12:00 PM, robert_weir@us.ibm.com wrote: > "Dennis E. Hamilton"<dennis.hamilton@acm.org> wrote on 09/06/2011 > 09:45:16 AM: > >> See Rob's explanation if that makes more sense. >> >> At this point in the life of ODF, there is no way that the ODF TC >> can undertake define when two ODF representations are for the same > documents. > We can start with Canonical XML [1]. From there we could easily define > canonicalization of inter-document references, e.g., styles. We could > define canonical ordering of items in ZIP, etc. So there are some things > we could define. But it is not clear how far up the semantic chain we > would take it. For example, there is some freedom where we put style > definitions. Is that a "real" difference? It is if we define it to be. > > I wouldn't be too concerned about app-to-app rendering differences. That > is a different problem. But if doc 1 has a blue rectangle and doc 2 has a > green oval, then the docs are different, even if some screwed up app fails > to render them correctly. This is true even if the spec doesn't even > define how they should be rendered. > > [1]: http://www.w3.org/TR/xml-c14n > >> And there are comparison tools that work at the document (not XML >> level). OpenOffice.org has one built in. They've been in all >> flavors of Microsoft Office for years. (I imagine they might even >> compare a .doc and a .docx, who knows?!). They make it look like >> one was produced from the other (user choice) by change tracking. >> Imagine that! >> >> - Dennis >> >>
Original Message----- >> From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] >> Sent: Tuesday, September 06, 2011 04:33 >> To: office-collab@lists.oasis-open.org >> Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) >> >> I would be quite content if there was a definition for some of your >> terms, see below. >> >> On 02/09/2011 20:39, Dennis E. Hamilton wrote: >> >> I'm startled by this reaction. >> >> It is a commonplace that there can be different XML >> representations of an ODF document that make no perceptible >> difference for an user. And even perceptible differences may be > immaterial. >> Also, when a document is edited and saved, the representation >> may change. These might be immaterial for interoperability. Some >> variations may be more significant but possibly immaterial in a >> given interoperability setting. >> >> If we are not all to guess about this, the spec needs to tell us >> which are material and which are not. YMMV in a big way here! >> >> >> >> Contributing factors include the following: >> >> * Compliance requirements for ODF consumers are very loose >> * Different producers may favor one representation over another >> among semantically-equivalent representations >> >> Where is the definition of 'semantically-equivalent'? >> >> >> * There is a wide range of implementation-defined deviations >> >> Deviations from the standard? What is permissible and what is not? >> (Rhetorical questions) >> >> >> * Users use provisions of producers to achieve the content and >> appearance that they want, without awareness of how the XML reflects >> that or how different ways that they accomplish some objective may >> lead to invisibly-different document representations. >> * Many processors do not use an internal model by which the XML >> is retained; it is generated on output from an internal model. That >> can produce different results on something as simple as a load >> followed by a save. >> >> Yes, I fully agree, but we should define when this is a non- >> compliance (if the load/save removes a few words that would seem to >> be a problem, if it changes auto styles this may not be a problem). >> >> >> * There is no specified layout behavior, or presentation of >> tracked changes in terms of an implementation's layout, so there is >> deviation simply between what an author did and what a reader, >> editor, or co-author sees. >> >> Good point! >> >> >> * How material any of this is depends on the situation. It is >> one force that leads people to stick to a single product and >> sometimes a specific release of a single product because of >> variations that can occur from one release to another. Users also >> adapt to bugs and then have to deal with the breakage that occurs >> when the bug is fixed. >> >> I agree very much with this, and this is holding up adoption of the >> standard... because there are lots of different but apparently valid >> interpretations. The ability for a user to move his/her document >> from one editing application to another is limited at the present >> time for the reasons you give. >> >> >> >> >>
Original Message----- >> From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] >> Sent: Friday, September 02, 2011 09:10 >> To: office-collab@lists.oasis-open.org >> Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) >> >> I am worried by your comment >> >> "a document has many ODF xml representations" >> because if the same document has many representations it is >> difficult to say when two documents are 'equal' or the same >> document. If we do not know when they are the same we cannot say >> what has changed. >> >> I am making the assumption that if the XML representation of two >> documents is different then the documents are different. Of course >> some differences (e.g. text content) are more important that others >> (e.g. automatic styles). If this basic assumption is wrong then >> perhaps we need to define a canonical form. Or is there some other >> way forward? >> >> Robin >> >> On 26/08/2011 19:46, Andreas J. Guelzow wrote: >> >> I had obviously read that message before. Unfortunately we do not > even >> seem to agree on the basic concepts. For me a document has many > ODF xml >> representations and changing between those representations does > not >> represent a document change, so while GCT may be well suited to > for >> recording changes in the representation I fail to see how it can > be used >> successfully to recognize changes to the document itself. >> >> > >> >> >> >> >> -- >> -- ----------------------------------------------------------------- >> 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 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 >> >> >> --------------------------------------------------------------------- >> 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 >> -- Patrick Durusau patrick@durusau.net 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

Patrick Durusau <patrick@durusau.net> wrote on 09/06/2011 03:50:47 PM: > > Rob, > > From below: > > > I wouldn't be too concerned about app-to-app rendering differences. That > > is a different problem. > > I am not sure if you mean with reference to how (1) changes are > displayed or (2) in general. > > If (1): > > With regard to changes, that certainly is app specific and could be an > area where apps compete to have useful display of changes. I can think > of several choices that I would like better than current offerings. > > If (2): > > I think we have an opportunity to more specifically say how ODF > documents should be rendered. Not *how* they get rendered but how they > should appear. Users see that as interoperability and to some degree > rightly so. They intend for the same input (the ODF documents) to have > the same result when processed by a conforming application with the same > capabilities. That's really not unreasonable. How far we can go towards > that goal with every release remains to be seen. > > Hopefully applications are going to "stay ahead" of the markup in some > ways so that user demands are in part driving the XML that we develop to > encode their needs. > I meant #2. I'm not saying that #2 is not important or that we should do it. I just mean that that is an orthogonal question to change tracking. For example I could have a document with line-style="exquisite" and then another app edits the document and has the user change the doc so it now is saved as: line-style="refined" This can be change tracked even if the spec is deficient in saying how "refined" and "exquisite" should be rendered. In other words, we cannot assume that undefined things are identical. But it is possible for some things, including undefined things, to be defined to be equivalent. If that make sense. -Rob > Hope you are having a great day! > > Patrick > > On 9/6/2011 12:00 PM, robert_weir@us.ibm.com wrote: > > "Dennis E. Hamilton"<dennis.hamilton@acm.org> wrote on 09/06/2011 > > 09:45:16 AM: > > > >> See Rob's explanation if that makes more sense. > >> > >> At this point in the life of ODF, there is no way that the ODF TC > >> can undertake define when two ODF representations are for the same > > documents. > > We can start with Canonical XML [1]. From there we could easily define > > canonicalization of inter-document references, e.g., styles. We could > > define canonical ordering of items in ZIP, etc. So there are some things > > we could define. But it is not clear how far up the semantic chain we > > would take it. For example, there is some freedom where we put style > > definitions. Is that a "real" difference? It is if we define it to be. > > > > I wouldn't be too concerned about app-to-app rendering differences. That > > is a different problem. But if doc 1 has a blue rectangle and doc 2 has a > > green oval, then the docs are different, even if some screwed up app fails > > to render them correctly. This is true even if the spec doesn't even > > define how they should be rendered. > > > > [1]: http://www.w3.org/TR/xml-c14n > > > >> And there are comparison tools that work at the document (not XML > >> level). OpenOffice.org has one built in. They've been in all > >> flavors of Microsoft Office for years. (I imagine they might even > >> compare a .doc and a .docx, who knows?!). They make it look like > >> one was produced from the other (user choice) by change tracking. > >> Imagine that! > >> > >> - Dennis > >> > >>
Original Message----- > >> From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > >> Sent: Tuesday, September 06, 2011 04:33 > >> To: office-collab@lists.oasis-open.org > >> Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > >> > >> I would be quite content if there was a definition for some of your > >> terms, see below. > >> > >> On 02/09/2011 20:39, Dennis E. Hamilton wrote: > >> > >> I'm startled by this reaction. > >> > >> It is a commonplace that there can be different XML > >> representations of an ODF document that make no perceptible > >> difference for an user. And even perceptible differences may be > > immaterial. > >> Also, when a document is edited and saved, the representation > >> may change. These might be immaterial for interoperability. Some > >> variations may be more significant but possibly immaterial in a > >> given interoperability setting. > >> > >> If we are not all to guess about this, the spec needs to tell us > >> which are material and which are not. YMMV in a big way here! > >> > >> > >> > >> Contributing factors include the following: > >> > >> * Compliance requirements for ODF consumers are very loose > >> * Different producers may favor one representation over another > >> among semantically-equivalent representations > >> > >> Where is the definition of 'semantically-equivalent'? > >> > >> > >> * There is a wide range of implementation-defined deviations > >> > >> Deviations from the standard? What is permissible and what is not? > >> (Rhetorical questions) > >> > >> > >> * Users use provisions of producers to achieve the content and > >> appearance that they want, without awareness of how the XML reflects > >> that or how different ways that they accomplish some objective may > >> lead to invisibly-different document representations. > >> * Many processors do not use an internal model by which the XML > >> is retained; it is generated on output from an internal model. That > >> can produce different results on something as simple as a load > >> followed by a save. > >> > >> Yes, I fully agree, but we should define when this is a non- > >> compliance (if the load/save removes a few words that would seem to > >> be a problem, if it changes auto styles this may not be a problem). > >> > >> > >> * There is no specified layout behavior, or presentation of > >> tracked changes in terms of an implementation's layout, so there is > >> deviation simply between what an author did and what a reader, > >> editor, or co-author sees. > >> > >> Good point! > >> > >> > >> * How material any of this is depends on the situation. It is > >> one force that leads people to stick to a single product and > >> sometimes a specific release of a single product because of > >> variations that can occur from one release to another. Users also > >> adapt to bugs and then have to deal with the breakage that occurs > >> when the bug is fixed. > >> > >> I agree very much with this, and this is holding up adoption of the > >> standard... because there are lots of different but apparently valid > >> interpretations. The ability for a user to move his/her document > >> from one editing application to another is limited at the present > >> time for the reasons you give. > >> > >> > >> > >> > >>
Original Message----- > >> From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > >> Sent: Friday, September 02, 2011 09:10 > >> To: office-collab@lists.oasis-open.org > >> Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > >> > >> I am worried by your comment > >> > >> "a document has many ODF xml representations" > >> because if the same document has many representations it is > >> difficult to say when two documents are 'equal' or the same > >> document. If we do not know when they are the same we cannot say > >> what has changed. > >> > >> I am making the assumption that if the XML representation of two > >> documents is different then the documents are different. Of course > >> some differences (e.g. text content) are more important that others > >> (e.g. automatic styles). If this basic assumption is wrong then > >> perhaps we need to define a canonical form. Or is there some other > >> way forward? > >> > >> Robin > >> > >> On 26/08/2011 19:46, Andreas J. Guelzow wrote: > >> > >> I had obviously read that message before. Unfortunately we do not > > even > >> seem to agree on the basic concepts. For me a document has many > > ODF xml > >> representations and changing between those representations does > > not > >> represent a document change, so while GCT may be well suited to > > for > >> recording changes in the representation I fail to see how it can > > be used > >> successfully to recognize changes to the document itself. > >> > >> > > >> > >> > >> > >> > >> -- > >> -- ----------------------------------------------------------------- > >> 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 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 > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >> > > -- > Patrick Durusau > patrick@durusau.net > 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 > S/MIME Cryptographic Signature

Comparing two documents brings up the topic on ODF XML normalization. The GCT would run into this problem when tracking the dialog between two ODF users sending back and forth an ODF document, but working on different ODF applications. It is likely that those ODF applications switch internal ODF details (e.g. automatic style names, the start/end of spans, like a text in "yellow red yellow" might be represented by three spans or or two - one overall for yellow and a nested for the red, overwriting the color value.) Is this problem already covered by one of the proposals? Kind regards, Svante Am 06.09.2011 15:45, schrieb Dennis E. Hamilton: > See Rob's explanation if that makes more sense. > > At this point in the life of ODF, there is no way that the ODF TC can undertake define when two ODF representations are for the same documents. > > And there are comparison tools that work at the document (not XML level). OpenOffice.org has one built in. They've been in all flavors of Microsoft Office for years. (I imagine they might even compare a .doc and a .docx, who knows?!). They make it look like one was produced from the other (user choice) by change tracking. Imagine that! > > - Dennis > >
Original Message----- > From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > Sent: Tuesday, September 06, 2011 04:33 > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > > I would be quite content if there was a definition for some of your terms, see below. > > On 02/09/2011 20:39, Dennis E. Hamilton wrote: > > I'm startled by this reaction. > > It is a commonplace that there can be different XML representations of an ODF document that make no perceptible difference for an user. And even perceptible differences may be immaterial. > > Also, when a document is edited and saved, the representation may change. These might be immaterial for interoperability. Some variations may be more significant but possibly immaterial in a given interoperability setting. > > If we are not all to guess about this, the spec needs to tell us which are material and which are not. YMMV in a big way here! > > > > Contributing factors include the following: > > * Compliance requirements for ODF consumers are very loose > * Different producers may favor one representation over another among semantically-equivalent representations > > Where is the definition of 'semantically-equivalent'? > > > * There is a wide range of implementation-defined deviations > > Deviations from the standard? What is permissible and what is not? (Rhetorical questions) > > > * Users use provisions of producers to achieve the content and appearance that they want, without awareness of how the XML reflects that or how different ways that they accomplish some objective may lead to invisibly-different document representations. > * Many processors do not use an internal model by which the XML is retained; it is generated on output from an internal model. That can produce different results on something as simple as a load followed by a save. > > Yes, I fully agree, but we should define when this is a non-compliance (if the load/save removes a few words that would seem to be a problem, if it changes auto styles this may not be a problem). > > > * There is no specified layout behavior, or presentation of tracked changes in terms of an implementation's layout, so there is deviation simply between what an author did and what a reader, editor, or co-author sees. > > Good point! > > > * How material any of this is depends on the situation. It is one force that leads people to stick to a single product and sometimes a specific release of a single product because of variations that can occur from one release to another. Users also adapt to bugs and then have to deal with the breakage that occurs when the bug is fixed. > > I agree very much with this, and this is holding up adoption of the standard... because there are lots of different but apparently valid interpretations. The ability for a user to move his/her document from one editing application to another is limited at the present time for the reasons you give. > > > > >
Original Message----- > From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] > Sent: Friday, September 02, 2011 09:10 > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page) > > I am worried by your comment > > "a document has many ODF xml representations" > because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed. > > I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward? > > Robin > > On 26/08/2011 19:46, Andreas J. Guelzow wrote: > > I had obviously read that message before. Unfortunately we do not even > seem to agree on the basic concepts. For me a document has many ODF xml > representations and changing between those representations does not > represent a document change, so while GCT may be well suited to for > recording changes in the representation I fail to see how it can be used > successfully to recognize changes to the document itself. > > > > > > >

Robin LaFontaine <robin.lafontaine@deltaxml.com> wrote on 09/02/2011 12:10:03 PM: > > I am worried by your comment > "a document has many ODF xml representations" > because if the same document has many representations it is > difficult to say when two documents are 'equal' or the same > document. If we do not know when they are the same we cannot say > what has changed. > There are different ways to define equivalence: 1) Byte-level equivalence 2) Unicode level equivalence (after decoding) 3) Lexical equivalence at the XML level, accounting for ignorable whitespace 4) Lexical equivalence at the XML parsed model, so <foo/> and <foo></foo> are equivalent, order of attributes is arbitrary, etc. 5) Equivalence via a a canonicalization transformation, e.g., id="foo" and id=bar" are equivalent so long as the graph of references is the same. 6) And then you get into the semantic level with possible ways that the "same" document could have more than one XML representation. For example, when you write out a spreadsheet that has a single value in A1, how many blank rows and columns do you also write out? > I am making the assumption that if the XML representation of two > documents is different then the documents are different. Of course > some differences (e.g. text content) are more important that others > (e.g. automatic styles). If this basic assumption is wrong then > perhaps we need to define a canonical form. Or is there some other > way forward? > This would be a problem in a diff application, and application of a canonicalization transformation could help. But I'm not sure this is a problem with change tracking. For example, if document is edited in app A, and then app B loads the same document, and introduces some user-directed changes plus some transformations that are insignificant (more blank rows in the spreadsheet, for example) then app B should know what changes were real and which ones were artifacts and only write out change tracking for the changes that it wants to be tracked. > Robin > > On 26/08/2011 19:46, Andreas J. Guelzow wrote: > I had obviously read that message before. Unfortunately we do not even > seem to agree on the basic concepts. For me a document has many ODF xml > representations and changing between those representations does not > represent a document change, so while GCT may be well suited to for > recording changes in the representation I fail to see how it can be used > successfully to recognize changes to the document itself. > > > > -- > -- ----------------------------------------------------------------- > 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 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 S/MIME Cryptographic Signature