OpenDocument - Adv Document Collab SC

Hi, In the Generic CT, should text:tracked-changes exist as the first child of office:text or as a sibling of office:automatic-styles. ie, in the later perhaps after the automatic styles but before the office:body. FWIW the relaxng schema odt-delta.rng 6836 2010-07-30 14:15:03Z nigelw validates the first case location and not as the second. As an aside, I started with using the second placement as it seemed the ct element related to content inside the office:body. In KOffice gct it is expected to be inside the office:text (ie, koffice validates placement ok with the rng schema). Although I now have abiword able to place in either/both location and read from either I thought it best to clarify where exactly it is desired to have this element appear: inside office:text or at a sibling level with automatic-styles, or somewhere else?

There's a scope issue. Moving where the <text:tracked-changes> element is permitted has scope consequences with regard to where change-marks may appear as descendants and there may also be complications related to how the <text:changed-region> elements are identified and referenced from within the scope of the <text:tracked-changes> material. There are a number of consequences that must be dealt with before simply changing the schema to locate <text:tracked-changes> higher in the hierarchy of <office:body> element descendants. - Dennis PS: This does not address where generic ct would put its equivalent of <text:tracked-changes>. This observation applies to the ODF 1.2 schema as it is. Perhaps, to keep things straight among ourselves, we should refer to <gct:tracked-changes> rather than <text:tracked-changes> until we know what the alignment is (or is not). DETAILS 1. Note that, according to ODF 1.2 Part 1 section 5.5.1, and the RNG Schema, <text:tracked-changes> can appear in an <office:text> element or in a <style:header[-left]> or <style:footer[-left]> element. 2. The appearance of change-marks as descendants of a header-footer-content pattern are, one must presume, in the scope of the <text:tracked-changes> element of the parent <style:header[-left]> or <style:footer[-left]>. If there is no such <text:tracked-changes> element, the change-marks are to be ignored. 2.1 Note that those particular <text:tracked-changes> are under a <style:master-page> element that is under an <office:master-styles> element. 2.2 The <office:master-styles> element may appear in a <office:document-styles> element (and hence in a styles.xml package part) or in an <office:document> element representing a single ODF (sub-)document. Because of the use of xml:id and attributes of type IDREF to tie change marks and <text:changed-region> elements together, the resolution of the scope is particularly important, along with the requirement that all xml:id attribute values (and all other attribute values of type ID) in a single XML document be mutually distinct. 2.3 The appearance of change-marks in a paragraph-content or text-content pattern within the scope of an <office:master-styles> are disjoint from those that are within the scope of an <office:text> element. 3. An <office:text> element is always the single element child of an <office:body> element. The optional children of <office:body> are mutually exclusive. 3.1 When the <office:body> element is a child of an <office:document-content> element, it is near the root of a content.xml file (generally) and the <office:text> has as its scope all children of the <office:text> except for any interior occurrences of an <office:text> element. There can be multiple <office:text> elements subordinate to an <office:text>, either by in-line occurrence of an <office:document> (e.g., in a <draw:object>) or indirectly via inclusion of a subdocument by reference (in which case the scopes are disjoint). 3.2 When the <office:body> element is a child of an <office:document>, its <office:text> element, if any, introduces a new scope for a <text:tracked-changes> element. The rules for omission of a <text:tracked-changes> element suggest that the interior <office:text> cannot have change-mark occurrences that are interpreted in any scope at all. 3.3 There's a possible edge case where an internal <office:body> element has a child other than <office:text> might have change-marks that are resolved to an outer <office:text> in the same XML document (in a package or not). I haven't worked through that prospect.
Original Message----- From: monkeyiq [ mailto:monkeyiq@gmail.com ] < http://lists.oasis-open.org/archives/office-collab/201104/msg00051.html > Sent: Tuesday, April 12, 2011 17:33 To: office-collab@lists.oasis-open.org Subject: [office-collab] Location of text:tracked-changes element Hi, In the Generic CT, should text:tracked-changes exist as the first child of office:text or as a sibling of office:automatic-styles. ie, in the later perhaps after the automatic styles but before the office:body. FWIW the relaxng schema odt-delta.rng 6836 2010-07-30 14:15:03Z nigelw validates the first case location and not as the second. As an aside, I started with using the second placement as it seemed the ct element related to content inside the office:body. In KOffice gct it is expected to be inside the office:text (ie, koffice validates placement ok with the rng schema). Although I now have abiword able to place in either/both location and read from either I thought it best to clarify where exactly it is desired to have this element appear: inside office:text or at a sibling level with automatic-styles, or somewhere else? --------------------------------------------------------------------- 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

(Sorry to be slow in replying to this.) In terms of how the GCT proposal works, these are the assumptions: 1. The ODF document is semantically considered to be a single XML file (the single file format) and dividing it into separate parts in a zip is not semantically important as far as change tracking is concerned. The scope of the changes is the whole document. 2. Where the delta:tracked-changes goes is not important, but there must be only one of them (see 7.2.2 Rule 1) because order of the changes is important (see 3 list item number 5). The Use case samples are only samples - the subcommittee can decide where to put the delta:tracked-changes element. Dennis points out there are scope issues for the current text:tracked-changes and where it appears, but there should not be these issues for the GCT proposal. Hope this helps. Robin On 13/04/2011 01:33, monkeyiq wrote: 1302654783.1516.95.camel@alkid.localdomain type= cite > Hi, In the Generic CT, should text:tracked-changes exist as the first child of office:text or as a sibling of office:automatic-styles. ie, in the later perhaps after the automatic styles but before the office:body. FWIW the relaxng schema odt-delta.rng 6836 2010-07-30 14:15:03Z nigelw validates the first case location and not as the second. As an aside, I started with using the second placement as it seemed the ct element related to content inside the office:body. In KOffice gct it is expected to be inside the office:text (ie, koffice validates placement ok with the rng schema). Although I now have abiword able to place in either/both location and read from either I thought it best to clarify where exactly it is desired to have this element appear: inside office:text or at a sibling level with automatic-styles, or somewhere else? --------------------------------------------------------------------- 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

Although I don't think these are compelling matters, I want to be clear about the scope issues: ODF allows for sub-documents embedded in the main document. In some implementations, the package form is also embedded in another package (i.e., it is a Zip). In other cases, the parts of the sub-document are organized by using a shared path prefix on the names of the parts. The latter "nested" parts are in the manifest of the overall document, and the shared path prefix will also appear in the manifest for the purpose of identifying it as the prefix of a subdocument. There is only one manifest for all of the parts of the main document (but an embedded package occurs as a single file, so nothing within it can be viewed as under the XML of the overall document). [This is material with regard to digital signature of the overall document and also to encryption in the ODF 1.2 provisions.] If a "nested" subdocument had change-tracking before it was introduced into the current overall document, there becomes the question, why mess with its change-tracking to accomplish that? Also the nested subdocument might be of a different kind than the overall document (e.g., a spreadsheet embedded in a text document). It might even be a different version of ODF since there is no restriction about that in the ODF specification. This is something to be careful about. Finally, a single, somewhere-global collection of the counterpart of <text:tracked-changes> will likely introduce a global-to-the-document non-ID identification scheme by which the out-of-line change-tracking information can be referenced from the in-line change marks, wherever they are. I'm not sure this eliminates scope issues and I wonder if it is a good technical trade-off even if it does. I think my principle concern, apart from these nits, is that we not hand-wave away the scoping that applies in ODF 1.2 change-tracking until we are clear why it is that way and what its value is. - Dennis SIDE NOTE There are technical differences between the single-XML document model and the package model where the portions are contributed by separate XML documents in the package. The most fundamental difference has to do with how cross-references may occur. XML provides no mechanism (in the XML specification itself) for cross references from one XML document to another. Put more simply, an attribute value of IDREF type can only refer to the one element in the same XML document that has an attribute of type ID with matching value. There are many cases (e.g., reference to styles) where the ODF document has, in effect, its own domains of references and of targets that match on names. These domains work across the document, not just within a single XML document of the package. The ODF 1.2 Change Tracking relies on ID and IDREF valued attributes to connect the change-marks in the text stream with the <text:changed-region> elements in the <text:tracked-changes> element of some scope. There are ways to continue to use ID and IDREF when the source and target are in the same XML document, and to use URIs to cross-reference to an ID (now a fragment identifier) of an element in a separate XML document. It would take some massaging to do, but it might be workable. This is a hybrid way of getting the global-to-the-document ID-based identification scheme.
Original Message----- From: Robin LaFontaine [ mailto:robin.lafontaine@deltaxml.com ] Sent: Thursday, April 21, 2011 04:38 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Location of text:tracked-changes element (Sorry to be slow in replying to this.) In terms of how the GCT proposal works, these are the assumptions: 1. The ODF document is semantically considered to be a single XML file (the single file format) and dividing it into separate parts in a zip is not semantically important as far as change tracking is concerned. The scope of the changes is the whole document. 2. Where the delta:tracked-changes goes is not important, but there must be only one of them (see 7.2.2 Rule 1) because order of the changes is important (see 3 list item number 5). The Use case samples are only samples - the subcommittee can decide where to put the delta:tracked-changes element. Dennis points out there are scope issues for the current text:tracked-changes and where it appears, but there should not be these issues for the GCT proposal. Hope this helps. Robin On 13/04/2011 01:33, monkeyiq wrote: Hi, In the Generic CT, should text:tracked-changes exist as the first child of office:text or as a sibling of office:automatic-styles. ie, in the later perhaps after the automatic styles but before the office:body. FWIW the relaxng schema odt-delta.rng 6836 2010-07-30 14:15:03Z nigelw validates the first case location and not as the second. As an aside, I started with using the second placement as it seemed the ct element related to content inside the office:body. In KOffice gct it is expected to be inside the office:text (ie, koffice validates placement ok with the rng schema). Although I now have abiword able to place in either/both location and read from either I thought it best to clarify where exactly it is desired to have this element appear: inside office:text or at a sibling level with automatic-styles, or somewhere else? --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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