Re: [office-collab] Groups - Proposal for generic representationof tracked changes for ODF (generic-ct-proposalV5-updates.odt) uploaded

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

On 13/09/2011 15:42, Andreas J. Guelzow wrote:

1315924938.30321.41.camel@kirkman" type="cite">

On Tue, 2011-09-13 at 05:31 -0600, robin.lafontaine@deltaxml.com wrote:

We have updated the GCT to reflect comments made by SC members.
Specifically it has been updated to move deleted text out from the content
area and also to add meta-data so a change transaction can be identified as
a particular type of edit operation.This version also provides an
alternative representation for attribute changes. 

Just some observations regarding these changes:

-------------
In 2 Introduction:
"If conversion between them is part of the standard then a reader or
writer application can choose which is most convenient."

If the writer can choose one of two representations, then the reader
will need to be able to read both since either could appear in the file.
So there would not be a choice for the reader  to choose the more
convenient.

On the other hand, if the reader would have the opportunity to choose
the more convenient, then both representations must be in every file so
the writer has no choice of the more convenient. 

Please clarify this. (The text says something about a "standard XSLT
style sheet will be provided to convert between these" it is not clear
to be how this would help a general editing application.)

The concept is similar to the XML representation for RelaxNG and the compact form, you can convert from one to the other. If there is standard code to move between them (be it XSLT or other) then a reader can convert before it reads in. Of course there is also no reason why for a specific application, e.g. ODF, one form is mandated. Then the writer can run the standard conversion if it needs to. In general alternative, semantically equivalent, representations are useful because some applications will find one easier to process than another. But ODF can choose one, certainly, if that is better!

1315924938.30321.41.camel@kirkman" type="cite">

-------------
In 3 (15):
"An application can elect to cache deleted content in situ, i.e. where
it was deleted, or in another place in the document. They cannot be
mixed, one or other must be chosen.

[Rationale: The alternatives are a choice for a reader or writer for its
convenience. If one or other is mandated in a particular situation then
it is no longer a choice.]"

How does this provide a choice of convenience for the reader? The reader
would need to be able to read either since only one can be used.

This is not very clear, apologies. For 'application' it would be better as 'format' so that, say, ODF could always have its content in another place. The point here is that mixing these would seem unnecessary, though there may be a good use case, this could be discussed.

1315924938.30321.41.camel@kirkman" type="cite">

-------------
A similar question applies to 3(16) but there also appears to be a typo
in that section.

Same comment applies, typo noted.

1315924938.30321.41.camel@kirkman" type="cite">

-------------
If the possible values of delta:edit-operation can be defined "by a
particular editing application" how does this assist in
interoperability. What is the expected behaviour of an implementation
that encounters such a value on reading? With foreign elements/attribute
values there is usually the possibility to ignore them. I don't see how
one can ignore s single unsupported piece of change tracking info.
Please elaborate. 

Again rather a loose use of 'application'. ODF could define these operations, as seems to be the requirement. Some members of the SC seem to have the opinion that there is a finite list of these that can be defined, i.e. the list in ECT spec. IMHO I think the list will grow and some 'extension' mechanism will be needed (what about macros that perform edits, for example). But then this method could be used for 'odf:format-change' or 'msword:text-to-table' or whatever might be needed. Of course as you say a msword:xx could not necessarily be read by other applications. I see no reason why, in general, a specific unsupported change could not be ignored, as is the case now when a Word document is converted to ODF the format changes are ignored. This needs to be specified in detail but it is all tractable.

1315924938.30321.41.camel@kirkman" type="cite">

-------------
While having delta:removed-content allows the deleted content to place
elsewhere, it still allows it to be retained in situ. This does not seem
to resolve the issue that a 1.2 or earlier implementation when
encountering this element needs to understand it to be able to ignore
the element content.  

I am not sure I understand your comment. I would not envisage a 1.2 or earlier implementation could read GCT at all, nor could it read most of ECT either. In the same way 1.1 reader cannot understand all of 1.2.

1315924938.30321.41.camel@kirkman" type="cite">

-------------

My reading of these changes is that these changes move the proposal in
the wrong direction: writers have even more choices so implementing a
reader implementation becomes even more difficult. Note that a writer
implementation always knows what change it tries to record. It is the
reader implementation that has to determine it from the file content.

I hope the above comments clarify this: ODF can tie down the choices as much as it wishes. I agree making life easier for the reader is always the priority. I see GCT (perhaps defined as a module of ODF) as potentially being useful for other XML formats and they may make different choices. It would be interesting to push it further and have a representation where the changes were separate from the document. Svante's work points in that direction and it is a valid choice in some situations.
Robin

1315924938.30321.41.camel@kirkman" type="cite">

Andreas  
 

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK