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

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

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

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

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

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

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

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

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.

Andreas  
 



-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta

This is a digitally signed message part