OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office-collab] Let's Keep the Cases Straight


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]