OpenDocument - Adv Document Collab SC

I notice that there is a tendency to view whatever already happens using the ODF 1.x change tracking as part of ECT and that GCT escapes it. I think we need to look at the choices in front of us where a. ODF? is what there is in major circulation now, more-or-less related to what is in the ODF 1.0-ODF 1.2 specifications (the ? related to the uncertainty around bugs and limitations in implementations and the specification too. b. GCT is the general proposal that uses the DeltaXML approach as a basis c. ECT is the approach to extending change tracking using ODF? as a starting point. That means we have these to wonder about: 0. ODF? as it is or maybe tidied up a tiny bit (I number this 0 because I don't think we can get away with this) 1. GCT 2. ODF? + GCT (unless we believe we'll ever get away with abandoning ODF? without a way forward, even if it means a protracted deprecation period, sort of like OOXML part 4.) 3. ODF? + ECT (the only place where ECT applies) - Dennis

On Sun, 2011-04-24 at 15:34 -0600, Dennis E. Hamilton wrote: > I notice that there is a tendency to view whatever already happens using the ODF 1.x change tracking as part of ECT and that GCT escapes it. > > I think we need to look at the choices in front of us where > > a. ODF? is what there is in major circulation now, more-or-less related to what is in the ODF 1.0-ODF 1.2 specifications (the ? related to the uncertainty around bugs and limitations in implementations and the specification too. > The way read ODF1.0 to 1.2, there are really 2 change tracking mechanisms defined. One for text documents and one for spreadsheet documents. Which one are you referring to? > b. GCT is the general proposal that uses the DeltaXML approach as a basis > > c. ECT is the approach to extending change tracking using ODF? as a starting point. > > That means we have these to wonder about: > > 0. ODF? as it is or maybe tidied up a tiny bit (I number this 0 because I don't think we can get away with this) > > 1. GCT > > 2. ODF? + GCT (unless we believe we'll ever get away with abandoning ODF? without a way forward, even if it means a protracted deprecation period, sort of like OOXML part 4.) > > 3. ODF? + ECT (the only place where ECT applies) Since ODF? really consists of 2 parts, one could argue that there are many more possibilities. Andreas This is a digitally signed message part

I include everything in "ODF?" that is in the ODF 1.0-1.2 specifications. I include the provisions of for <text:tracked-changes> and the special ones under the spreadsheet content.xml (I can't look at the spec right now because I am doing server maintenance). It might be reasonable to maintain the segregation or do a better unification. I think that applies in all of the cases in which ODF? occurs. Even though the details I personally focus on are related to <text:tracked-changes>, that is because anything we do is a show-stopper if we don't get this case right. That may be true for the spreadsheet row-column manipulations too, but I don't feel comfortable with them, at this point, to offer any appraisal. I'm trusting you to drag our attention to those. Also, I can see a case where a spreadsheet cell, the content of which is a <text:p> or other text-content pattern, is subject to text-level change-tracking along with spreadsheet row-column manipulations, so I don't see these things staying completely separate. - Dennis
Original Message----- From: Andreas J. Guelzow [ mailto:andreas.guelzow@concordia.ab.ca ] Sent: Sunday, April 24, 2011 15:52 To: dennis.hamilton@acm.org Cc: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Let's Keep the Cases Straight On Sun, 2011-04-24 at 15:34 -0600, Dennis E. Hamilton wrote: > I notice that there is a tendency to view whatever already happens using the ODF 1.x change tracking as part of ECT and that GCT escapes it. > > I think we need to look at the choices in front of us where > > a. ODF? is what there is in major circulation now, more-or-less related to what is in the ODF 1.0-ODF 1.2 specifications (the ? related to the uncertainty around bugs and limitations in implementations and the specification too. > The way read ODF1.0 to 1.2, there are really 2 change tracking mechanisms defined. One for text documents and one for spreadsheet documents. Which one are you referring to? > b. GCT is the general proposal that uses the DeltaXML approach as > a basis > > c. ECT is the approach to extending change tracking using ODF? as a starting point. > > That means we have these to wonder about: > > 0. ODF? as it is or maybe tidied up a tiny bit (I number this 0 > because I don't think we can get away with this) > > 1. GCT > > 2. ODF? + GCT (unless we believe we'll ever get away with abandoning > ODF? without a way forward, even if it means a protracted deprecation > period, sort of like OOXML part 4.) > > 3. ODF? + ECT (the only place where ECT applies) Since ODF? really consists of 2 parts, one could argue that there are many more possibilities. Andreas

Hi, On page 17 of the extended proposal the example shows the entire draw:frame replaced for any change. On the other hand, reading the GCT proposal as it stands one would implement atomic changes such as 6.3.2 for style modifications to a caption: <text:span delta:insertion-type='insert-around-content' ...> So the view in this particular example is founded on the proposals themselves. Stepping back from the ECT/GCT comparison, I think the larger trap is to force context dependant processing on common elements such as text:p. In abiword, and I'd imagine in many other applications, the load path for ODF uses the same code to turn text:p elements and their children into the internal objects that the application uses to represent the document. Frank Meies has commented that OOo uses this same scheme where all text:p use the same codepath. The context dependant processing of text:p means that such code paths would have to be duplicated; one for text:p elements at top level, and another for text:p elements buried inside a bucket. On Sun, 2011-04-24 at 14:34 -0700, Dennis E. Hamilton wrote: > I notice that there is a tendency to view whatever already happens > using the ODF 1.x change tracking as part of ECT and that GCT escapes > it. ... >
Original Message----- > From: monkeyiq [ mailto:monkeyiq@gmail.com ] > Sent: Sunday, April 24, 2011 01:30 > To: Frank Meies > Cc: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Suggestions for moving forward to resolve issues > > On Fri, 2011-04-22 at 12:55 +0200, Frank Meies wrote: > > That's what OOo currently does. There is no difference (neither in the > > generated xml nor in the internal structures) if you change the > > caption text:p or any other paragraph in the document. > > So in this particular case, the ECT as it stands is actually a fair bit harder to implement than the GCT. The ECT requiring two very different IO paths depending on context. > > [ ... ] > > > --------------------------------------------------------------------- > 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 >

On Sun, 2011-04-24 at 18:16 -0600, monkeyiq wrote: > The context dependant processing of text:p means that such code paths > would have to be duplicated; one for text:p elements at top level, and > another for text:p elements buried inside a bucket. I would disagree. There are other ways to keep context than to duplicate code paths. In fact text:p elements can already occur in various distinct contexts, so I would assume that you are aleady preserving the context for those situations without duplicating the code paths. Andreas This is a digitally signed message part

On Sun, 2011-04-24 at 19:56 -0600, Andreas J. Guelzow wrote: > On Sun, 2011-04-24 at 18:16 -0600, monkeyiq wrote: > > > The context dependant processing of text:p means that such code paths > > would have to be duplicated; one for text:p elements at top level, and > > another for text:p elements buried inside a bucket. > > I would disagree. There are other ways to keep context than to duplicate > code paths. In fact text:p elements can already occur in various > distinct contexts, so I would assume that you are aleady preserving the > context for those situations without duplicating the code paths. > > Andreas > The duplication is to handle loading and assembling the changes from the text:p inside all the buckets for the old versions. Page 9 of the ECT proposal shows how "normal" text:p would have calls out to change tracking to describe style changes inline, however page 17 uses en masse retiring & versioning of text:p objects each time a draw:frame is changed. Thus to load each text:p instance (page 9 vs inside bucket on page 17) the code itself would have to be quite different. And again, to generate these serializations, one would need quite different code.

On Sun, 2011-04-24 at 20:12 -0600, monkeyiq wrote: > On Sun, 2011-04-24 at 19:56 -0600, Andreas J. Guelzow wrote: > > On Sun, 2011-04-24 at 18:16 -0600, monkeyiq wrote: > > > > > The context dependant processing of text:p means that such code paths > > > would have to be duplicated; one for text:p elements at top level, and > > > another for text:p elements buried inside a bucket. > > > > I would disagree. There are other ways to keep context than to duplicate > > code paths. In fact text:p elements can already occur in various > > distinct contexts, so I would assume that you are aleady preserving the > > context for those situations without duplicating the code paths. > > > The duplication is to handle loading and assembling the changes from the > text:p inside all the buckets for the old versions. > > Page 9 of the ECT proposal shows how "normal" text:p would have calls > out to change tracking to describe style changes inline, however page 17 > uses en masse retiring & versioning of text:p objects each time a > draw:frame is changed. Thus to load each text:p instance (page 9 vs > inside bucket on page 17) the code itself would have to be quite > different. And again, to generate these serializations, one would need > quite different code. I don't see any occurrence of text:p on page 17 (of course since the odt documents do not have any fixed pagination I may be looking at a completely different page than you). On the other hand the only occurrences of draw:frame are on my pages 3, 17 and 18 so the pagination can't be that different. Andreas > > This is a digitally signed message part

On Sun, 2011-04-24 at 20:57 -0600, Andreas J. Guelzow wrote: > On Sun, 2011-04-24 at 20:12 -0600, monkeyiq wrote: > > On Sun, 2011-04-24 at 19:56 -0600, Andreas J. Guelzow wrote: > > > On Sun, 2011-04-24 at 18:16 -0600, monkeyiq wrote: > > > > > > > The context dependant processing of text:p means that such code paths > > > > would have to be duplicated; one for text:p elements at top level, and > > > > another for text:p elements buried inside a bucket. > > > > > > I would disagree. There are other ways to keep context than to duplicate > > > code paths. In fact text:p elements can already occur in various > > > distinct contexts, so I would assume that you are aleady preserving the > > > context for those situations without duplicating the code paths. > > > > > The duplication is to handle loading and assembling the changes from the > > text:p inside all the buckets for the old versions. > > > > Page 9 of the ECT proposal shows how "normal" text:p would have calls > > out to change tracking to describe style changes inline, however page 17 > > uses en masse retiring & versioning of text:p objects each time a > > draw:frame is changed. Thus to load each text:p instance (page 9 vs > > inside bucket on page 17) the code itself would have to be quite > > different. And again, to generate these serializations, one would need > > quite different code. > > I don't see any occurrence of text:p on page 17 (of course since the odt > documents do not have any fixed pagination I may be looking at a > completely different page than you). On the other hand the only > occurrences of draw:frame are on my pages 3, 17 and 18 so the pagination > can't be that different. > > Andreas I'm using the version that was uploaded and which had a URL sent to the list. Unfortunately there is no version information in the document preamble, the document properties shows a modification of 03/15/2011, 23:41:00, John Haug FWIW $ md5sum extended-ct-proposal.odt b4b94e6717742dc29efa8459dd4e04d8 extended-ct-proposal.odt On the page 17 you should see an example which covers how the modification of content inside a draw:frame is to be handled. The example itself in the proposal does not include the string "text:p" although that is a legal child XML element of draw:frame. IIRC it was mentioned on the second conference call that the intent of handling of draw:frame is to retire the old version en masse and replace it entirely when a change is made to any child element/attribute, in order to make implementation simpler. I suspect perhaps the text:p child is an unforeseen interaction. Though it does raise the question of how many such cases are available if the granularity of these "buckets" remains the same. The below is a fragment from the odt file with a captioned image that I sent to the list recently. Notice that the draw:frame includes a text:p child which, according to the ECT proposal, in particular on page 17, will be versioned en masse with the draw:frame. <draw:frame draw:style-name="fr1" draw:name="Frame1" text:anchor-type="paragraph" svg:x="4.74cm" svg:y="-0.589cm" svg:width="6.576cm" draw:z-index="0"> <draw:text-box fo:min-height="5.392cm"> <text:p text:style-name="Illustration"><draw:frame draw:style-name="fr2" draw:name="graphics1" text:anchor-type="paragraph" svg:x="0.004cm" svg:y="0.002cm" svg:width="1.231cm" style:rel-width="100%" svg:height="1.231cm" style:rel-height="scale" draw:z-index="1"><draw:image xlink:href="Pictures/10000201000000300000003080BBF035.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>Illustration <text:sequence text:ref-name="refIllustration0" text:name="Illustration" text:formula="ooow:Illustration+1" style:num-format="1">1</text:sequence>: This is a fun little logo, see if you can guess what application it will run :-p</text:p> </draw:text-box> </draw:frame> One might stipulate that the text:p inside the draw:frame should be handled like the normal text:p changes on page 9. Though this still leaves the situation where the user changes the caption, creates a new revision, and then applies a "filter" as the example on page 17 does. In this case, the document would include one or more buckets for the draw:frame, each of which might include more than one revision to its text:p. This also doesn't consider what happens if the caption and filter are both changed in the same revision... would the text:p changes be handled and then the whole draw:frame bucket retired en masse as on page 17 in order to record the filter change. Or perhaps the revisions must be kept forcibly small such that both operations can not possibly occur in the same revision.

Hi all, On 25.04.2011 14:17, monkeyiq wrote: 1303733856.7555.97.camel@alkid.localdomain type= cite > One might stipulate that the text:p inside the draw:frame should be handled like the normal text:p changes on page 9. Though this still leaves the situation where the user changes the caption, creates a new revision, and then applies a filter as the example on page 17 does. In this case, the document would include one or more buckets for the draw:frame, each of which might include more than one revision to its text:p. In this example, we have a frame containing and image and a caption:   <draw:frame svg:width= 3cm >       <draw:text-box>         <text:p>         <draw:frame>                   <draw:image xlink:href= Pictures/pic.jpg />             </draw:frame>               Caption           </text:p>       </draw:text-box>   </draw:frame> if you first change the caption text, this will be tracked like any other regular text change, because the caption is nothing but a regular paragraph inside a text box. If you then change the image, only the *inner* draw:frame element will be replaced according to the ECT Proposal. But if you change e.g., the width of the *outer* frame, the complete outer draw:frame has to be replaced because ECT lacks the ability to track attribute changes. I also consider this problematic and prefer the way GCT handles this case. 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. Hertogswetering 163/167, 3543 AS Utrecht, 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

Perhaps I can clarify some of the confusion.
 
The examples under the
Images, Shapes, Charts section of the ECT proposal were intended to show that for areas that are slippery slopes with lots of potential granular changes to track that may have lower end user value to track on such a granular level, they can be easily
treated at the level of the whole object.  Text that exists on these objects can be treated the same way as any other text.
 
I think Ben was pointing to the first subsection, Edit Image/Shape/Chart when he referred to ??page 17 ?.  In this case, the question of how to handle text:p
is irrelevant since draw:frame does not allow text:p as a child element.  The Edit Shape Text subsection below that demonstrates that text change tracking can be handled for drawing objects that are allowed to take text.  If there was confusion about the Edit
Image/Shape/Chart (as in, edit the core object itself) using an image as the example and seeming to preclude tracking text changes, if the image is specified using draw:image rather than draw:frame, then it can have a text:p child element and can be change
tracked the same as demonstrated in the Edit Shape Text example.
 
Frank ??s comments below are correct.  Though of course the ECT proposal as initially proposed could be expanded to track changes to higher-value properties of
drawing objects.  (Top of my head, this could be addressed similarly to changing which style is applied to text, which is also an attribute value.)
 


From: Frank Meies [mailto:frank.meies@oracle.com]

Sent: Tuesday, April 26, 2011 7:06 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Let's Keep the Cases Straight


 
Hi all,

On 25.04.2011 14:17, monkeyiq wrote:


One might stipulate that the text:p inside the draw:frame should be
handled like the normal text:p changes on page 9. Though this still
leaves the situation where the user changes the caption, creates a new
revision, and then applies a "filter" as the example on page 17 does. In
this case, the document would include one or more buckets for the
draw:frame, each of which might include more than one revision to its
text:p.
In this example, we have a frame containing and image and a caption:

  <draw:frame svg:width="3cm" >
    <draw:text-box>
      <text:p>
        <draw:frame>
          <draw:image xlink:href= "Pictures/pic.jpg"/>
        </draw:frame>
        Caption
      </text:p>
    </draw:text-box>
  </draw:frame>

if you first change the caption text, this will be tracked like any other regular text change, because the caption is nothing but a regular paragraph inside a text box. If you then change the image, only the *inner* draw:frame element will be replaced according
to the ECT Proposal. But if you change e.g., the width of the *outer* frame, the complete outer draw:frame has to be replaced because ECT lacks the ability to track attribute changes. I also consider this problematic and prefer the way GCT handles this case.

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.
Hertogswetering 163/167, 3543 AS Utrecht, 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

On Wed, 2011-04-27 at 00:25 +0000, John Haug wrote: > Perhaps I can clarify some of the confusion. > > > > The examples under the Images, Shapes, Charts section of the ECT > proposal were intended to show that for areas that are slippery slopes > with lots of potential granular changes to track that may have lower > end user value to track on such a granular level, they can be easily > treated at the level of the whole object. Text that exists on these > objects can be treated the same way as any other text. > > > > I think Ben was pointing to the first subsection, Edit > Image/Shape/Chart when he referred to €œpage 17 €. In this case, the > question of how to handle text:p is irrelevant since draw:frame does > not allow text:p as a child element. Transitively draw:frame does allow text:p as a child element. And buckets containing the entire tree at an XML node are thus transitive with respect to containment. Open Document Format for Office Applications (OpenDocument) v1.2 Part 1: Introduction and OpenDocument Schema 03, 30 July 2009 (9.4.2) draw:frame allows as a child element draw:text-box (9.4.3). In turn draw:text-box (9.4.3) allows as child element text:p (4.1.2). So it is completely relevant as it is specified. > The Edit Shape Text subsection below that demonstrates that text > change tracking can be handled for drawing objects that are allowed to > take text. If there was confusion about the Edit Image/Shape/Chart > (as in, edit the core object itself) using an image as the example and > seeming to preclude tracking text changes, if the image is specified > using draw:image rather than draw:frame, then it can have a text:p > child element and can be change tracked the same as demonstrated in > the Edit Shape Text example. > > > > Frank €™s comments below are correct. Though of course the ECT proposal > as initially proposed could be expanded to track changes to > higher-value properties of drawing objects. (Top of my head, this > could be addressed similarly to changing which style is applied to > text, which is also an attribute value.) > > > > From: Frank Meies [ mailto:frank.meies@oracle.com ] > Sent: Tuesday, April 26, 2011 7:06 AM > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Let's Keep the Cases Straight > > > > > Hi all, > > On 25.04.2011 14:17, monkeyiq wrote: > > > > One might stipulate that the text:p inside the draw:frame should be > handled like the normal text:p changes on page 9. Though this still > leaves the situation where the user changes the caption, creates a new > revision, and then applies a "filter" as the example on page 17 does. In > this case, the document would include one or more buckets for the > draw:frame, each of which might include more than one revision to its > text:p. > > In this example, we have a frame containing and image and a caption: > > <draw:frame svg:width="3cm" > > <draw:text-box> > <text:p> > <draw:frame> > <draw:image xlink:href="Pictures/pic.jpg"/> > </draw:frame> > Caption > </text:p> > </draw:text-box> > </draw:frame> > > if you first change the caption text, this will be tracked like any > other regular text change, because the caption is nothing but a > regular paragraph inside a text box. If you then change the image, > only the *inner* draw:frame element will be replaced according to the > ECT Proposal. But if you change e.g., the width of the *outer* frame, > the complete outer draw:frame has to be replaced because ECT lacks the > ability to track attribute changes. I also consider this problematic > and prefer the way GCT handles this case. > > Regards, > > Frank > > -- > Oracle > 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. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der > Ven > > Green OracleOracle is committed to developing practices and products > that help protect the environment > >

Well, let's be careful about transitivity. It may simply be the case that John's use of <draw:frame> was the right idea with the wrong example. (<draw:frame> is the wrong example for all manner of things.) I think of John's example was raising a principle (like negotiating from the 1967 borders of Israel) not making a rigid proposal about what should be done with <draw:frame>. Why do we keep coming back to this? The paragraph-/text-content runs within <draw:*> elements ARE ALREADY COVERED by the existing ODF 1.2 change tracking provisions and they can already have change marks too. I think a better question is what happens when other more-significant material not covered by the current system are to be tracked in ways in which there is currently no tracking. For example, in an <office:binary-data> element. (This is a trick question.) Perhaps the interesting cases for any <draw:*> elements are what happens when a whole child is replaced or when the only change is in attributes and not to the element content. We are always going to have cases where we won't want change-tracking to cross over the start or end tags or even be supported in the interior of an element. For example, it seems strange to change-track within the text of a field such as <text:sheet-name> or <text:author-name> or <text:author-initials>. These are fields, they have XML text content (that is, PCDATA) but not paragraph-/text-content runs. If some of these change, it is because the change happened somewhere else; the text values are not entered by the user directly into the field. The fields don't even have styles. One field might be included in a deletion from the paragraph content in which it occurs, one field might be part of an insertion, but I doubt we worry about anything finer-grained than that. - Dennis GROUND TRUTH ABOUT TEXT CONTENT IN DRAW ELEMENTS First, two <draw:frame> elements that I ran into yesterday as part of doing some document forensics work. Notice that there are no paragraph-/text-content runs anywhere in these, at any level of transitivity. Make of that what you will: <text:p text:style-name="P6"> <draw:frame draw:style-name="fr1" draw:name="Object1" text:anchor-type="char" svg:x="0.0728in" svg:y="0.2083in" svg:width="6.198in" svg:height="1.5835in" draw:z-index="4"> <draw:object-ole xlink:href="./Object 1" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> <draw:image xlink:href="./ObjectReplacements/Object 1" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> <text:p text:style-name="P5"> <draw:frame text:anchor-type="paragraph" draw:z-index="5" draw:style-name="gr2" draw:text-style-name="P12" svg:width="6.2913in" svg:height="2.2087in" svg:x="0in" svg:y="0.1528in"> <draw:image xlink:href="Pictures/200008DD000CE3A500081942616D7389.svm" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"> <text:p/> </draw:image> </draw:frame> </text:p> (All of the xlink:href attributes in the above point to nondescript binary blobs.) (Clearly, one can also have some sort of additional change-tracking provision that covers changes to attributes at the <draw:frame> start-tag level. Whether one should do that in this case or simply allow it to be treated as a deletion and replacement is an open question for any proposed extension or replacement of ODF 1.2 change-tracking. In all cases, what an user can control and how the change and its tracking is made apparent to an user is all to be considered. It will depend on whether it is really worth it and how acceptance and rejection of such a change is to be expected to be possible as an user-driven determination.) It is true that <draw:text-box>s are allowed as children of <draw:frame>. And the markup of <draw:text-box> content is ALREADY amenable to the existing change-tracking support. In fact, a <draw:text-box> allows one or more of any text-content elements, including <text:p>s, more <draw:frame>s, change marks, etc. So everything in <draw:text-box> is subject to the existing change tracking for runs of text-content elements. HOWEVER, this is not transitively below the context of the <draw:text-box>'s parent in the sense that its text is considered part of the text flow in which the parent is anchored in some manner. In fact, the specification makes it clear that such text may be completely outside of the superior text flow. That is, the rules about paragraph (or text-content) text flow above the <draw:text-box>'s parent <draw:frame> don't descend into the <draw:text-box>. Style inheritance evidently doesn't come down into the <draw:text-box> (nor into any <draw:frame> nested in it, etc.) and text flow needn't push upwards. (There may be an edge case around the styles/attributes on the parent <draw:frame>, but it doesn't matter for change-tracking as well as I can tell.) It is also the case that <draw:image> element allows <text:p> and <text:list> children. Many other <draw:*> elements permit <text:p> children. All of these are ALREADY subject to ODF 1.2 change tracking. Nevertheless, it is not clear what these are for and what relationship they have to the text flow of the parent <draw:frame> (and what the user would see if there were any paragraph-/text-content present). I agree that there is transitivity in the sense that text-content and paragraph-content elements can be found in the descendants within <draw:*> elements, and that change-tracking covers them so long as they occur within the scope of a <text:tracked-changes> element (in the current ODF 1.2 change-tracking). However, I do not see such transitivity in any sort of continuity in the text flow and the selections that can be made for deletions and insertions. Furthermore, these cases are already handled in the ODF 1.2 provisions. And just for fun, here's an element that I ran into the other day. There is paragraph-content here. The actual shape (which happens to be superimposed atop one of the preceding draw frames), was not produced this way. It is attached to this post as an attachment. It was produced by manipulating a shape on the text-document presentation surface. But this is what is in the ODF content.xml. What would be change-tracking for this puppy? <text:p text:style-name="P3"> <draw:custom-shape text:anchor-type="char" draw:z-index="2" draw:style-name="gr1" draw:text-style-name="P11" svg:width="1.2398in" svg:height="0.215in" svg:x="-0.2917in" svg:y="0.0398in"> <text:p text:style-name="P11"> <text:span text:style-name="T4">Check weighing</text:span> </text:p> <draw:enhanced-geometry svg:viewBox="0 0 21600 21600" draw:text-areas="800 800 20800 20800" draw:type="round-rectangular-callout" draw:modifiers="10141 -98563" draw:enhanced-path="M 3590 0 X 0 3590 L ?f2 ?f3 0 8970 0 12630 ?f4 ?f5 0 18010 Y 3590 21600 L ?f6 ?f7 8970 21600 12630 21600 ?f8 ?f9 18010 21600 X 21600 18010 L ?f10 ?f11 21600 12630 21600 8970 ?f12 ?f13 21600 3590 Y 18010 0 L ?f14 ?f15 12630 0 8970 0 ?f16 ?f17 Z N"> <draw:equation draw:name="f0" draw:formula="$0 -10800"/> <draw:equation draw:name="f1" draw:formula="$1 -10800"/> <draw:equation draw:name="f2" draw:formula="if(?f18 ,$0 ,0)"/> <draw:equation draw:name="f3" draw:formula="if(?f18 ,$1 ,6280)"/> <draw:equation draw:name="f4" draw:formula="if(?f23 ,$0 ,0)"/> <draw:equation draw:name="f5" draw:formula="if(?f23 ,$1 ,15320)"/> <draw:equation draw:name="f6" draw:formula="if(?f26 ,$0 ,6280)"/> <draw:equation draw:name="f7" draw:formula="if(?f26 ,$1 ,21600)"/> <draw:equation draw:name="f8" draw:formula="if(?f29 ,$0 ,15320)"/> <draw:equation draw:name="f9" draw:formula="if(?f29 ,$1 ,21600)"/> <draw:equation draw:name="f10" draw:formula="if(?f32 ,$0 ,21600)"/> <draw:equation draw:name="f11" draw:formula="if(?f32 ,$1 ,15320)"/> <draw:equation draw:name="f12" draw:formula="if(?f34 ,$0 ,21600)"/> <draw:equation draw:name="f13" draw:formula="if(?f34 ,$1 ,6280)"/> <draw:equation draw:name="f14" draw:formula="if(?f36 ,$0 ,15320)"/> <draw:equation draw:name="f15" draw:formula="if(?f36 ,$1 ,0)"/> <draw:equation draw:name="f16" draw:formula="if(?f38 ,$0 ,6280)"/> <draw:equation draw:name="f17" draw:formula="if(?f38 ,$1 ,0)"/> <draw:equation draw:name="f18" draw:formula="if($0 ,-1,?f19 )"/> <draw:equation draw:name="f19" draw:formula="if(?f1 ,-1,?f22 )"/> <draw:equation draw:name="f20" draw:formula="abs(?f0 )"/> <draw:equation draw:name="f21" draw:formula="abs(?f1 )"/> <draw:equation draw:name="f22" draw:formula="?f20 -?f21 "/> <draw:equation draw:name="f23" draw:formula="if($0 ,-1,?f24 )"/> <draw:equation draw:name="f24" draw:formula="if(?f1 ,?f22 ,-1)"/> <draw:equation draw:name="f25" draw:formula="$1 -21600"/> <draw:equation draw:name="f26" draw:formula="if(?f25 ,?f27 ,-1)"/> <draw:equation draw:name="f27" draw:formula="if(?f0 ,-1,?f28 )"/> <draw:equation draw:name="f28" draw:formula="?f21 -?f20 "/> <draw:equation draw:name="f29" draw:formula="if(?f25 ,?f30 ,-1)"/> <draw:equation draw:name="f30" draw:formula="if(?f0 ,?f28 ,-1)"/> <draw:equation draw:name="f31" draw:formula="$0 -21600"/> <draw:equation draw:name="f32" draw:formula="if(?f31 ,?f33 ,-1)"/> <draw:equation draw:name="f33" draw:formula="if(?f1 ,?f22 ,-1)"/> <draw:equation draw:name="f34" draw:formula="if(?f31 ,?f35 ,-1)"/> <draw:equation draw:name="f35" draw:formula="if(?f1 ,-1,?f22 )"/> <draw:equation draw:name="f36" draw:formula="if($1 ,-1,?f37 )"/> <draw:equation draw:name="f37" draw:formula="if(?f0 ,?f28 ,-1)"/> <draw:equation draw:name="f38" draw:formula="if($1 ,-1,?f39 )"/> <draw:equation draw:name="f39" draw:formula="if(?f0 ,-1,?f28 )"/> <draw:equation draw:name="f40" draw:formula="$0 "/> <draw:equation draw:name="f41" draw:formula="$1 "/> <draw:handle draw:handle-position="$0 $1"/> </draw:enhanced-geometry> </draw:custom-shape> </text:p>
Original Message----- From: monkeyiq [ mailto:monkeyiq@gmail.com ] Sent: Friday, May 20, 2011 20:07 To: John Haug Cc: office-collab@lists.oasis-open.org Subject: RE: [office-collab] Let's Keep the Cases Straight On Wed, 2011-04-27 at 00:25 +0000, John Haug wrote: > Perhaps I can clarify some of the confusion. > > > > The examples under the Images, Shapes, Charts section of the ECT > proposal were intended to show that for areas that are slippery slopes > with lots of potential granular changes to track that may have lower > end user value to track on such a granular level, they can be easily > treated at the level of the whole object. Text that exists on these > objects can be treated the same way as any other text. > > > > I think Ben was pointing to the first subsection, Edit > Image/Shape/Chart when he referred to €œpage 17 €. In this case, the > question of how to handle text:p is irrelevant since draw:frame does > not allow text:p as a child element. Transitively draw:frame does allow text:p as a child element. And buckets containing the entire tree at an XML node are thus transitive with respect to containment. Open Document Format for Office Applications (OpenDocument) v1.2 Part 1: Introduction and OpenDocument Schema 03, 30 July 2009 (9.4.2) draw:frame allows as a child element draw:text-box (9.4.3). In turn draw:text-box (9.4.3) allows as child element text:p (4.1.2). So it is completely relevant as it is specified. > The Edit Shape Text subsection below that demonstrates that text > change tracking can be handled for drawing objects that are allowed to > take text. If there was confusion about the Edit Image/Shape/Chart > (as in, edit the core object itself) using an image as the example and > seeming to preclude tracking text changes, if the image is specified > using draw:image rather than draw:frame, then it can have a text:p > child element and can be change tracked the same as demonstrated in > the Edit Shape Text example. > > > > Frank €™s comments below are correct. Though of course the ECT proposal > as initially proposed could be expanded to track changes to > higher-value properties of drawing objects. (Top of my head, this > could be addressed similarly to changing which style is applied to > text, which is also an attribute value.) > > > > From: Frank Meies [ mailto:frank.meies@oracle.com ] > Sent: Tuesday, April 26, 2011 7:06 AM > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Let's Keep the Cases Straight > > > > > Hi all, > > On 25.04.2011 14:17, monkeyiq wrote: > > > > One might stipulate that the text:p inside the draw:frame should be > handled like the normal text:p changes on page 9. Though this still > leaves the situation where the user changes the caption, creates a new > revision, and then applies a "filter" as the example on page 17 does. > In this case, the document would include one or more buckets for the > draw:frame, each of which might include more than one revision to its > text:p. > > In this example, we have a frame containing and image and a caption: > > <draw:frame svg:width="3cm" > > <draw:text-box> > <text:p> > <draw:frame> > <draw:image xlink:href="Pictures/pic.jpg"/> > </draw:frame> > Caption > </text:p> > </draw:text-box> > </draw:frame> > > if you first change the caption text, this will be tracked like any > other regular text change, because the caption is nothing but a > regular paragraph inside a text box. If you then change the image, > only the *inner* draw:frame element will be replaced according to the > ECT Proposal. But if you change e.g., the width of the *outer* frame, > the complete outer draw:frame has to be replaced because ECT lacks the > ability to track attribute changes. I also consider this problematic > and prefer the way GCT handles this case. > > Regards, > > Frank > > -- > Oracle > 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. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister > der Handelskammer Midden-Niederlande, Nr. 30143697 > Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der > Ven > > Green OracleOracle is committed to developing practices and products > that help protect the environment > > --------------------------------------------------------------------- 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 Cropping-2011-05-20-2215-OverlayedCallout.png