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