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] GCT-Issue-2 (was GCT Issues Wiki page)


Comparing two documents brings up the topic on ODF XML normalization.
The GCT would run into this problem when tracking the dialog between two
ODF users sending back and forth an ODF document, but working on
different ODF applications.
It is likely that those ODF applications switch internal ODF details
(e.g. automatic style names, the start/end of spans, like a text in
"yellow red yellow" might be represented by three spans or or two - one
overall for yellow and a nested for the red, overwriting the color value.)

Is this problem already covered by one of the proposals?

Kind regards,
Svante

Am 06.09.2011 15:45, schrieb Dennis E. Hamilton:
> See Rob's explanation if that makes more sense.
>
> At this point in the life of ODF, there is no way that the ODF TC can undertake define when two ODF representations are for the same documents.
>
> And there are comparison tools that work at the document (not XML level).  OpenOffice.org has one built in.  They've been in all flavors of Microsoft Office for years.  (I imagine they might even compare a .doc and a .docx, who knows?!).  They make it look like one was produced from the other (user choice) by change tracking.  Imagine that!
>
>  - Dennis
>
> -----Original Message-----
> From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
> Sent: Tuesday, September 06, 2011 04:33
> To: office-collab@lists.oasis-open.org
> Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page)
>
> I would be quite content if there was a definition for some of your terms, see below.
>
> On 02/09/2011 20:39, Dennis E. Hamilton wrote: 
>
> 	I'm startled by this reaction.
> 	
> 	It is a commonplace that there can be different XML representations of an ODF document that make no perceptible difference for an user.  And even perceptible differences may be immaterial.
> 	
> 	  Also, when a document is edited and saved, the representation may change.  These might be immaterial for interoperability.  Some variations may be more significant but possibly immaterial in a given interoperability setting.
>
> If we are not all to guess about this, the spec needs to tell us which are material and which are not. YMMV in a  big way here!
>
>
> 	
> 	Contributing factors include the following: 
> 	
> 	 * Compliance requirements for ODF consumers are very loose
> 	 * Different producers may favor one representation over another among semantically-equivalent representations
>
> Where is the definition of 'semantically-equivalent'? 
>
>
> 	 * There is a wide range of implementation-defined deviations
>
> Deviations from the standard? What is permissible and what is not? (Rhetorical questions)
>
>
> 	 * Users use provisions of producers to achieve the content and appearance that they want, without awareness of how the XML reflects that or how different ways that they accomplish some objective may lead to invisibly-different document representations.
> 	 * Many processors do not use an internal model by which the XML is retained; it is generated on output from an internal model.  That can produce different results on something as simple as a load followed by a save.
>
> Yes, I fully agree, but we should define when this is a non-compliance (if the load/save removes a few words that would seem to be a problem, if it changes auto styles this may not be a problem).
>
>
> 	 * There is no specified layout behavior, or presentation of tracked changes in terms of an implementation's layout, so there is deviation simply between what an author did and what a reader, editor, or co-author sees.
>
> Good point!
>
>
> 	 * How material any of this is depends on the situation.  It is one force that leads people to stick to a single product and sometimes a specific release of a single product because of variations that can occur from one release to another.  Users also adapt to bugs and then have to deal with the breakage that occurs when the bug is fixed.
>
> I agree very much with this, and this is holding up adoption of the standard... because there are lots of different but apparently valid interpretations. The ability for a user to move his/her document from one editing application to another is limited at the present time for the reasons you give.
>
>
> 	
> 	
> 	-----Original Message-----
> 	From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
> 	Sent: Friday, September 02, 2011 09:10
> 	To: office-collab@lists.oasis-open.org
> 	Subject: Re: [office-collab] GCT-Issue-2 (was GCT Issues Wiki page)
> 	
> 	I am worried by your comment 
> 	
> 	"a document has many ODF xml representations"
> 	because if the same document has many representations it is difficult to say when two documents are 'equal' or the same document. If we do not know when they are the same we cannot say what has changed.
> 	
> 	I am making the assumption that if the XML representation of two documents is different then the documents are different. Of course some differences (e.g. text content) are more important that others (e.g. automatic styles). If this basic assumption is wrong then perhaps we need to define a canonical form. Or is there some other way forward?
> 	
> 	Robin
> 	
> 	On 26/08/2011 19:46, Andreas J. Guelzow wrote: 
> 	
> 		I had obviously read that message before. Unfortunately we do not even
> 		seem to agree on the basic concepts. For me a document has many ODF xml
> 		representations and changing between those representations does not
> 		represent a document change, so while GCT may be well suited to for
> 		recording changes in the representation I fail to see how it can be used
> 		successfully to recognize changes to the document itself.  
> 	
> 			> 
> 	
> 	
>
>



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