Re: [oiic-formation-discuss] The importance to users of documents looking the same

[marbux <marbux@gmail.com>]

One of the advantages of CDRF as an interop framework is that you can
have multiple branches of progressively more featurerful profiles and
the branch can begin at any profile.

E.g., one branch for the pixel perfect folk, another for those whose
concern is for automated parsing, extraction, transformation, and
reformatting. Because CDRF species RFC 2119 as the reqirements
keywords definitions, the modal definition of "may" requires that the
pixel perfect implementations retain the ability to write to the
unextended profiles. <http://www.ietf.org/rfc/rfc2119.txt>.

That's the problem that the ODF TC and Rob have been ducking ever
since I raised it on the TC. JTC 1 switched ODF from RFC 2119
definitions to ISO/IEC Guideline definitions but didn't even look at
the consequences. Every interop requirement in ODF got toggled off by
the switch of a couple of words.

E.g., the sentence in the conformance section that says
implementations "may" write foreign elements and attributes
(app-specific extensions to ODF) lost the requirement that
implementations retain any ability to write to unextended ODF. So now
we have no major ODF apps that can still write to unextended ODF.

It's this kind of messiness and laxity in the ODF spec that will make
the profile work of this TC so difficult and why we can't maintain
compatibility with current ODF implementations as presently
implemented in the profile work. It's the apps that are going to have
to change, not the profiles if we want to achieve interop and
application-neutrality.

I suspect thatis why Rob rejected out of hand my proposal that this TC
be required to use RFC 2119 definitions rather than ISO/IEC Guideline
definitions and why he is pushing for two classes of conformance for
the profiles, strict conformance and tag soup conformance. IBM does
not want all those folks who have built their ODF software businesses
on OOo and its clones to have to strictly conform to the profiles.
That would force the reprogramming of OOo and its clones to actually
achieve interop. IBM wants ODF to continue to be defined by OOo, for
the OOo implementation tail to wag the ODF standard dog.

IBM and Sun don't walk the ODF interop walk; they just talk the ODF
interop talk. I've experienced that time and again and that is why I
am insistent on specifying CDRF in the TC charter.

I've heard far more enough of the ODF interop talk. I want to see that
first step on the ODF interop walk. CDRF forces the ODF interop walk.
That's why IBM doesn't want CDRF specified as the interop framework
for the profile work. IBM just wants to talk about ODF interop. IBM
does not want to allow it to happen.

I note again that this is not a personal attack on Rob. I have genuine
affection for Rob and fully comprehend that he is not the guy who has
the power to change IBM's anti-ODF-interop policy. Rob can't disobey
without putting his job and retirement benefits on the chopping
block.I shoot at the reprehensible company policy, not at Rob.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>