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

[monkeyiq <monkeyiq@gmail.com>]

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.