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

[marbux <marbux@gmail.com>]

On Thu, Jun 19, 2008 at 4:20 PM, Sander Marechal
<sander.marechal@tribal-im.com> wrote:
> robert_weir@us.ibm.com wrote:
>>
>> But I think it is premature, not having done completed the research, to
>> put specific technical limitations regarding profiles into the charter.
>
> Not sure about this one. Perhaps we could still set some baseline
> requirements that we all agree on are necessary for good interop, then leave
> all the details and techspeak to the TC.

You will not achieve lack of sustained opposition to trusting the big
vendors who will control the TC before I die without them first
earning that trust. We are only here because the same big vendors
postponed ODF interop since the TC was formed.in 2002 and have in fact
deliberately added new interop breakpoints in ODF 1.2, as well as
broken compatibility with all earlier versions of ODF in regard to
ordered lists.

ODF v. 1.2 breaks compatibility with the earlier versions because KDE
and Sun had not implemented ordered lists the same way, because of
under-specification in the standard. ODF 1.2 makes it optional whether
to write ordered lists using list tuples or triples, an absolute
round-tripping barrier.

E.g., you can convert list tuples to list triples by leaving one of
the triples blank. But ponder the interop barrier in converting list
triples to list tuples. Short story here: in ODF, the application tail
wags the standard dog. Virtually every of the multitude of "may" and
"should" clauses in the spec masks hard-coded programming decisions in
implementations. Those are all application dependencies. Major
portions of the spec are simply unspecified, e.g., the presentation
layer. The presentation layer is a massive application dependency
defined only by existing implementations' source code.

If you ask me to trust the big vendors who created this mess in any
way, you have only my sustained opposition until the day I die or they
earn that trust. I blooded my head far too many times on the ODF TC
trying to persuade them that the interop issues must be addressed. I
do not trust them to exercise any discretion given them in a way that
is not simply yet another vendor-lock-in game. There is no standard in
the ODF specification. It is only a check signed in blank for
developers to do whatever they want that slipped through the
international standard process. The pretense that it is an open
standard is belied by the application dependencies masked only by
under-specification.

We have a huge mess to clean up my friend. If you trust the folks who
created the mess to do the right thing, there are six years of TC and
SC email archives you need to read. I have read them all and they tell
a sordid tale.

Dave Pawson and I are agreed that no further conformance tests for ODF
can be developed for elements and attributes without assuming the
existence of conformance requirements that do not exist. Virtually all
conformance requirements as to elements and attributes are tested by
validation against the schema after all foreign elements and
attributes are stripped. The only other conformance tests in regard to
elements and attributes that could be developed is a minor section
dealing with the processing of foreign elements and attributes, which
themselves are not defined by the specification. Dave is an expert in
the development of conformance tests. I have yet to see any
disagreement with our conclusion so there appears to be consensus thus
far that development of conformance tests must await the adoption of
conformance requirements by the ODF TC.

Intending no disrespect, but if you trust the big ODF vendors to do
the right thing you act only on an assumption that they will, an
assumption falsified by their actual behavior. ODF is not such an
interop mess because the big vendors did the right thing in the six
years since the ODF TC was formed.

> Can use-cases be included in the charter or does it need to be formal
> standards language? I think it would be useful if we could draw up a few use
> cases and ask the TC to deliver formal ODF profile requirements that satisfy
> those use cases. I.e. we just tell the TC "what" we want and leave the "how"
> to the TC.

The problem to be solved is not technical. The big ODF vendors offer
no solution to the ODF interop problem in response to the CDRF
proposal because their ODF interop policies  *are* the ODF interop
problem.

There is only one feasible workplan on the table to clean up the ODF
interop mess, CDRF, and that belongs in the charter unless someone can
up with an equivalent or better workplan to put in the charter. .

The word processing software industry has had four decades to deliver
interoperability and it has yet to take the first step. The big ODF
vendors are very good at talking the ODF interop talk. They have
widely disseminated the myth  that ODF already provides the means of
iinteroperability. But they do not walk the ODF interop walk.  One
need only study the ODF specification to identify irrefutable proof.

CDRF or better in the charter. Tie the big ODF vendors' hands to ODF interop.

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