[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OOXML-ODF Use Cases (was RE: [office-collab] Re: Counting in Access Paths)
I don't believe that is the use case that either John or I were discussing. I know I was speaking of processing of ODF as ODF, including direct manipulation of XML parts. I think import-export involving a different document model not based on ODF is a different issue. It is also a different issue for ODF Conforming Consumers that do not support change-tracking of any ODF flavor. There is no requirement that unsupported features be preserved in output of ODF Conforming Producers. - Dennis DETAILS I've not observed any Microsoft Office support for change tracking in ODF documents. It is no surprise that you will lose the change-tracking completely by passing a change-tracked ODF document through Microsoft Office and back out as an ODF document. Microsoft Office does not operate on the ODF document at the XML level in the way that ODF-native and custom applications that generate or manipulate ODF documents would. It is well-known that the document models are different. It is no surprise that features of the ODF document that are not currently imported as comparable Microsoft Office features will disappear in any ODF round-trip scenario. (Recall how that worked until OpenFormula and the ODF 1.2 support in Excel.) Even if you create a change-tracked document in Microsoft Office and then save it in ODF format, none of the change-tracking will carry over. If you save it as an Office binary or as OOXML, you might be able to see some of the Office change-tracking preserved on (non-ODF) import into an OpenOffice-family implementation. I'm not clear how any of those cases, involving import-export capability of different software products, can be addressed by the ODF TC. I think the way to see ODF change-tracking supportable in Microsoft Office is to ensure a thoroughly-specified mechanism that can be practically mapped into equivalent OOXML, and vice versa. That would assure feasibility of Office support for ODF change-tracking, whether by Microsoft or an extension provider. And, as far as that goes, it would matter for import export of OOXML by ODF-centric software too. There are existence proofs with import-export cases of various degrees of fidelity for current Office and ODF change-tracking. While highly implementation-dependent, I suppose those do provide some level of benchmark against which a MCT definition can be calibrated. It may also be useful that there are implemented cases under licenses that permit collaborative improvement among implementers of both open-source and closed-source products. - Dennis -----Original Message----- From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert Sent: Sunday, October 21, 2012 04:33 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Re: Counting in Access Paths Hi John, I am glad to hear that you share the concerns of the important use case of "a document with tracked changes being edited by an implementation not supporting CT seems to completely break the referencing model. " Especially as my current pre-release of MS Office 2013 with ODF 1.2 support simply throws away all my change-tracking information. I am glad to hear that Microsoft takes this use case serious and looking forward to work with the full MS Office 2013 version supporting the important change-tracking use case. Enjoy your week-end, Svante On 19.10.2012 13:12, John Haug wrote: I have similar concerns, because I haven’t seen yet how they are avoided. The case of a document with tracked changes being edited by an implementation not supporting CT seems to completely break the referencing model. See my previous mails from October 1, “Counting issues, etc”. John From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Robin LaFontaine Sent: Thursday, October 18, 2012 2:05 AM To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Re: Counting in Access Paths I agree with your concerns, Dennis, and am surprised implementors do not seem to worry about this issue. OT has, we are told, been proved to work in a forwards direction when by definition all the 'edits' will be tracked and executed. Working backwards (from existing to previous version, i.e. tracked change) when not all the changes will be tracked, and not all accepted, is a different problem, IMHO. However, it is simple enough (though it will need a good bit of effort) to demonstrate whether or not this is a real concern - we need a specification of how it works and some implementations! Robin On 17/10/2012 21:38, Dennis E. Hamilton wrote: I'm having a terminology problem here. As far as I'm concerned, s="/2/10" and e="/3/18" are absolute addresses. Hierarchical, but absolute, not unlike in absolute URLs. It's more brittle than in a URL because it is based on counted position, not on labeled hierarchy nodes. That means insertion and deletion of siblings at every level requires these references to be repaired. That's scary. On the other hand, to use an existing example, xml:id="ct270478544" establishes a *fixed* identifier, but it does not rely on fixed locations. So wherever a text:change-id="ct270478544" happens to refer to it, the connection is maintained no matter what kind of movement happens on the paths between the two. It is true that in the specific case of the ODF 1.2 use of this device, the <text:changed-region> element is referenced from the content where it is applicable, not the reverse. That seems like a good choice to me, considering that it is the reference from the content that makes examination of the <text:changed-region> of any concern. This also allows the <text:changed-region> material to be output in front of the content, so it can all be indexed before the in-text references occur in the datastream. Does not the MCT use of these rigid absolute paths require that the document be serialized before the tracking information can be serialized? And for a consumer presenting the content, is it necessary to find the relevant change-tracking information by some synchronization method? My concern is that it is impossible to detect when synchronization has been broken. Everything has to be absolutely perfect and there is no way to touch a change-tracked document without having to adjust all of the tracking locations. That's a considerable burden. I am only addressing the cross-identification approach here. It appears that ODF CT does this in a more robust way; I don't see why MCT can't be made at least as resilient. I think there does need to be a stretchy way to connect between tracked details and the point of change. An xml:id ID value and a corresponding IDREF attribute value do this perfectly for XML-modeled persistent document formats. And this kind of support already has to exist in ODF-based processors simply because of the many ways that cross-referencing is handled by identifiers of some type, including IRIs that refer into package parts by fragment identifiers. - Dennis ..snip -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change" T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]