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] Groups - Event "Discuss draft02 consensus report (Conference Call)" added


Hi Andreas,

On 2 Nov 2011, at 16:06, Andreas J. Guelzow wrote:
> 
> Example 1:
> 
> Suppose I have in content.xml:
> 
> <draw:frame svg:x="48.00pt" svg:y="12.75pt" table:end-x="30.00pt" table:end-y="1.50pt" svg:width="270.00pt" svg:height="167.25pt" table:end-cell-address="$'XY'.Q16">
>              <draw:image xlink:href="Pictures/Image3.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
> </draw:frame>
> 
> the user changes the image and the content.xml becomes:
> <draw:frame svg:x="48.00pt" svg:y="12.75pt" table:end-x="30.00pt" table:end-y="1.50pt" svg:width="270.00pt" svg:height="167.25pt" table:end-cell-address="$'XY'.Q16">
>              <draw:image xlink:href="Pictures/Image3.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
> </draw:frame>
> 
> Note that there is no difference between these two snippets. I have no
> idea how GCT would even mark that the user has performed a change.
> 

This example is not just an issue in GCT, it also applies to ECT as it is a general problem. As was mentioned in the call on Tuesday, this only applies to the package version of ODF; the flat file encodes the images into the XML and so a change there can be marked in the XML. 

As far as I can see it, at present only images used by the current version of the document are stored in the zip package. If we are to be able to roll back image changes, we would need to store the old image in the package as well. In the example above, the ODF producer knows that there has been an image change and also knows how the XML will be serialized. We could either specify that an image change should always change the xlink:href, or leave it up to the producer to store a copy of the original image file with a different name. The old image could be stored as Pictures/Image3-old.svg and the change could be stored as a change to the xlink:href attribute (in GCT) or deleted/inserted buckets with the alternative xlink:href attributes (in ECT).

Note that this doesn't apply if the xlink:href points to an external file. If the xlink:href remains the same but the external file itself changes, that is something we have no control over and so cannot mark the change.

> Example 2:
> Suppose I have in content.xml:
> 
> <draw:frame svg:x="48.00pt" svg:y="12.75pt" table:end-x="30.00pt" table:end-y="1.50pt" svg:width="270.00pt" svg:height="167.25pt" table:end-cell-address="$'XY'.Q16">
>              <draw:image xlink:href="Pictures/Image3.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
> </draw:frame>
> 
> the user changes the image and the content.xml becomes:
> <draw:frame svg:x="48.00pt" svg:y="12.75pt" table:end-x="30.00pt" table:end-y="1.50pt" svg:width="270.00pt" svg:height="167.25pt" table:end-cell-address="$'XY'.Q16">
>              <draw:image xlink:href="Pictures/Image4.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
> </draw:frame>
> 
> I assume that GCT may flag the change in the xlink:href attribute value.
> Is a consumer guaranteed that this change will only be flagged if the
> Pictures/Image4.svg is in fact different from Pictures/Image3.svg?
> 

Yes, in GCT this change would be marked as a change to the xlink:href attribute. As far as guaranteeing that the images really are different, that is not the job of the spec as I see it. It is up to the producer to ensure that it only marks up actual changes. This is no different for images than it is for any other kind of change. For example, there is nothing in the spec to stop a producer from removing and inserting the same word other than that it makes no sense.

Tristan


> Please note that I still don't really understand GCT and every time I
> read it I stumble over terms that I apparently do not understand
> correctly (such as "application").
> Andreas
> 
> -- 
> Andreas J. Guelzow, PhD, FTICA
> Concordia University College of Alberta

--
Tristan Mitchell, DeltaXML Ltd "Change control for XML"
T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK








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