Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets

[Simon Calderson <caldersons@yahoo.co.uk>]

marbux <marbux@gmail.com> wrote:
> The foreign elements and attributes parts of the conformance section
> were specifically designed for round-tripping documents between apps
> that support ODF and apps that don't via conversions.

I think you're fundamentally missing the point with this. With conversions, all you're saying is "foreign elements can be used to retain information that would otherwise be lost in a different format": you re-use the foreign information coming back the other way, to get a better fidelity conversion back to the original (whichever format).

What this absolutely *does not help with* is the actual conversion process. In order to successfully convert ODF into anything else, you have to have a full understanding of what ODF means: you have to be a fully-conforming consumer. Storing extraneous data is no panacea or short-cut: you have to fully implement the specification.

What this TC needs to be concerned with is exactly that understanding of ODF which allows an application to manipulate it: either to view it, edit it, or (in your case) convert it to another file format.

If the new TC is able to get ODF to the point where ODF is interoperable with other ODF implementations to a high degree, *then* it is possible to write the transformation application you're talking about which can make use of foreign data in that manner. However, that's nothing to do with interop or conformance with ODF.

> Go back and read the conformance section using the RFC 2119 definition
> of "may" that was in OASIS ODF 1.0.
> <http://www.ietf.org/rfc/rfc2119.txt>. I you do and spend some time
> thinking about it, you'll see a compatibility framework for
> round-tripping documents

This is totally incorrect.  "MUST be prepared to interoperate with another implementation" does not mean "a-priori you must understand all foreign data thrown at you", that is clearly a nonsense. Consider this obvious example:

    <t:p t:style-name="emphasis" a:orig="style:bold">This is a single paragraph</t:p>

This is an ODF paragraph with a style and simple foreign attribute applied to it. If I change the "emphasis" style to "default", as an ODF application, what do I do with the foreign attribute? I claim the following:

* the ODF app cannot know what to do with it;
* if the ODF app leaves it as-is and the conversion app uses it, the document loses fidelity because the emphasis I removed comes back in a font style.
* if the ODF app doesn't leave it, and the conversion app does a decent job, the fidelity is kept because the emphasis is removed.

According to your understanding of the RFC 2119 definition of "may" and how it did apply to ODF, what should it do?

I look forward to someday getting an answer to any point I raise regards the basic problems with your proposals.

Thanks

Simon.



      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html