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

[monkeyiq <monkeyiq@gmail.com>]

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 
> 
>