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

[jose lorenzo <hozelda@yahoo.com>]

--- On Sat, 6/28/08, Simon Calderson <caldersons@yahoo.co.uk> wrote:

> From: Simon Calderson <caldersons@yahoo.co.uk>
> Subject: Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Saturday, June 28, 2008, 5:04 PM
> 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.

I basically agree with you. The OP may be correct in that the spec should demand "something" of applications or else the applications can do anything, but you are correct that this is not such an obvious problem to solve. The spec would have to go further by analyzing all possible cases (which may be impossible to do in general) to come up with precise rules that would apply to the particulars (eg, ODF within the context of foreign tags). You gave one example (bold/emphasis tags) to help highlight the difficulties that would have to be anticipated by the rules.

The only real solution here is not to allow foreign tags.. at least among for those wanting maximal interop. I clearly agree with the position of just filtering out foreign tags. Under the current spec wording, that is about the best one can do.

If you do allow for foreign tags in the spec (in future versions), it would have to be under very precise conditions and narrow the possible semantics somewhat, but that would defeat some of the point of having foreign tags as a way to "innovate." [If whoever introduces the foreign tags explains the circumstances for its use, gives source code, provides rules/transformations/etc, then it can work.]

The OP (marbux) once used the example of Microsoft technologies allowing round-tripping, but this disregards that Microsoft is a single company. Varying products from the same company does not fall into the inter-vendor inter-app interop, which is what this TC is about I think. Also very important to note is that third parties that use Microsoft libraries and development tools also have an easier time with interop because of all the code sharing in the background. My beef with this last scenario is that this would constitute illegal leveraging of a monopoly under the current market conditions.