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)


Rob,

 From below:

> I wouldn't be too concerned about app-to-app rendering differences.  That
> is a different problem.

I am not sure if you mean with reference to how (1) changes are 
displayed or (2) in general.

If (1):

With regard to changes, that certainly is app specific and could be an 
area where apps compete to have useful display of changes. I can think 
of several choices that I would like better than current offerings.

If (2):

I think we have an opportunity to more specifically say how ODF 
documents should be rendered. Not *how* they get rendered but how they 
should appear. Users see that as interoperability and to some degree 
rightly so. They intend for the same input (the ODF documents) to have 
the same result when processed by a conforming application with the same 
capabilities. That's really not unreasonable. How far we can go towards 
that goal with every release remains to be seen.

Hopefully applications are going to "stay ahead" of the markup in some 
ways so that user demands are in part driving the XML that we develop to 
encode their needs.

Hope you are having a great day!

Patrick

On 9/6/2011 12:00 PM, robert_weir@us.ibm.com wrote:
> "Dennis E. Hamilton"<dennis.hamilton@acm.org>  wrote on 09/06/2011
> 09:45:16 AM:
>
>> 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.
> We can start with Canonical XML [1].  From there we could easily define
> canonicalization of inter-document references, e.g., styles.  We could
> define canonical ordering of items in ZIP, etc.  So there are some things
> we could define.  But it is not clear how far up the semantic chain we
> would take it.  For example, there is some freedom where we put style
> definitions.  Is that a "real" difference?  It is if we define it to be.
>
> I wouldn't be too concerned about app-to-app rendering differences.  That
> is a different problem.  But if doc 1 has a blue rectangle and doc 2 has a
> green oval, then the docs are different, even if some screwed up app fails
> to render them correctly.  This is true even if the spec doesn't even
> define how they should be rendered.
>
> [1]: http://www.w3.org/TR/xml-c14n
>
>> 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.
>>
>>           >
>>
>>
>>
>>
>> -- 
>> -- -----------------------------------------------------------------
>> 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
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau



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