[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] Let's Keep the Cases Straight
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]