Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, AND SUGGESTIONS No. 1

[marbux <marbux@gmail.com>]

On Tue, Jun 17, 2008 at 6:40 AM, Sander Marechal
<sander.marechal@tribal-im.com> wrote:
> Here's a counter proposal: Your main (sole?) reason for CDRF seems to be
> the requirement that an application that conforms to some profile can
> also handle it's sub profiles (read them, and write back to them,
> allowing the less featureful app to open it again).
>
> Why not take just this rule and put it in the charter as a requirement
> for profiles, instead of using the entire CDRF?

A few example reasons:

1. Avoidance of duplicative but incompatible standards for the same
functionality, as with the objections to OOXML because ODF was already
the standard. There is a global effort under way to harmonize and
converge standards to reduce unnecessary obstacles to international
trade. I support that goal.

2. We can actually achieve high quality interop far sooner if we use
an existing cookbook for the TC's work rather than starting from
scratch.

3. W3C has the lead on  XML and related markup languages. CDRF was
designed for the purpose. There are enormous opportunities if we
maintain compatibility with CDRF; e.g., dramatically improved
transformability, a cookbook for combining ODF with other formats,
avoiding future incompatibilities like the three W3C formats
implemented incorrrectly in ODF with unique OASIS namespaces rather
than the correct W3C namespaces, on and on.

4. Right now, ODF is designed only to serve the needs of traditional
client-side desktop applications and the work to remove OOo
dependencies in it is far from complete. CDRF is designed to converge
support for apps on the desktop, servers, mobile devices, and the Web.
If ODF does not participate in that convergence, ODF will become
obsolete far sooner.

4. W3C is far more strict about vendor neutrality in its work than
OASIS. CDRF constrains the folks inclined toward manipulating this
TC's work for unfair competitive advantage and eliminates a host of
future arguments. It's the difference between having an agreed recipe
and trying to do committee work to create a new recipe that could only
introduce incompatibilities with CDRF were the new recipe any
different from CDRF. Compatibility with CDRF should be the guide.

5. I want specificity in the Charter rather than handing the TC a
check signed in blank. This TC will be dominated by the same 800-pound
gorillas who created the ODF interop mess in the first place and Rob
is pushing hard to get things into the Charter that will undermine
interop, such as two classes of conformance, strict and tag soup
(conformant status for app-specific extensions to the profiles).
Specifyiing CDRF in the charter eliminates such maneuvers. Were I to
attempt to write language as specific as I want, I would just rewrite
CDRF.

> Also an objection to your proposal: What if it turns out to be
> impossible to create an interop profile without adding things to the
> spec? Your requirement would mean that the TC failed and work stops - at
> least until the next version of ODF rolls around that has the issue
> fixed so that you can build the profile by just removing stuff.

To me, your objection supports my objection to doing this work in a
new TC rather than amending the ODF TC charter to encompass the work
contemplated here. Having two TC's working on the same spec is just
asking for problems.

> Personally I'd prefer the TC to still come up with a profile for the
> current ODF and continue working. Possibly with the added requirement to
> recommend changes for the next version of ODF so that the next iteration
> of profiles can be build correctly.

I'm very familiar with the ODF spec from my work on the ODF TC.
Profiling the entire existing spec would shatter compatibility with
existing apps and the existing spec would be obsolete long before the
profile work were completed. E.g., all of those "may" and "should"
clauses and passive voice sentences that establish no requirements
mask hard-coded programming decisions in OOo. Profile work and the
goal of interoperability requires that we remove all of that
discretion and convert all the "may" and "should" clauses into "shall"
and "shall not" requirements. And we must convert all of the passive
voice sentences into active voice sentences that impose "shall" and
"shall" not requirements. Virtually every area of developer discretion
in the ODF spec is an interop breakpoint and ODF was developed as a
blank check for developers to do anything they wish to do so long as
they do it in their own unique namespaces. As I've said before, stick
the XML 1.0 and Office  xml namespace headers in a Zip file and markup
all document content in OOXML and you still have a conformant ODF
document.

But if we are to profile the entire standard as our beginning point,
we simply unearth and document Sun's hard-coded programming decisions
in OOo and make the standard even more dependent on the OOo code base,
or we break compatibility with OOo.

The only feasible way I can conceive of to work out of that mess is to
start with a core profile that specifies a minimum feature set and
application behavior that must be fully supported by a conformant
implementation of any of the profiles. If you look at the ODF TC
charter, you'll see that this work was to have been completed in Phase
1 of developing ODF 1.0. The fact that Sun kept making excuses for
postponing that work is why all other big vendors dropped out at the
end of Phase 1.

Even the core of ODF is not application neutral and the work to
transform Sun's XML formats into application-neutral formats has yet
to begin. That is why just about everyone working on featureful
editors is cloning the OOo code base rather than writing new apps. And
unsurprisingly, the worst interop in the ODF market is that between
the OOo code base apps and KOffice, the only other major apps
implementing ODF.

This TC's only legitimate task is a salvage operation, not a profiling
of the existing ODF standard. Starting from a core profile and working
your way outward to progressively more featureful profiles is the only
rational way to begin the work of remodeling ODF into a set of
application-neutral formats that different apps can use to
interoperate. That approach (which CDRF imposes) presents a workable
method for implementations to get the fundamentals of ODF interop
right (including interop between profiles) and to implement
progressively more featureful profiles in do-able increments.

Were the ODF standard application-neutral, it might be feasible to
profile the entire standard and work your way inward to the least
featureful profile. But ODF has miles to go in becoming application
neutral. It's grossly under-specified to boot.

The principle justification in my mind for doing this work in a
separate TC is that if you want to do interop, you have to drop any
goal of maintaining compatibiity with or of keeping up with the ODF
TC's work and create instead a new set of standard profiles. One can
work from the ODF spec as a rough guide, but the app-dependencies have
to be removed and the under-specification has to be dealt with as you
go.

In other words, one must finally begin the process that was originally
established in the ODF TC charter for remodeling the Sun XML formats
into application-neutral and interoperable profiles. Six years have
been wasted on the interop front through's Sun's persistent and very
successful efforts on the ODF  TC to ensure that its apps remain the
dominant ODF apps through maintenance and creation of new interop
barriers and through under-specification of the standard.

ODF is a standard in name only. The real ODF standard is the OOo code
base. That is the problem this TC must solve. At each progressively
more featureful profile, the OOo code base is going to have to be
rewritten to accommodate app-neutrality and interoperability with
other apps. Otherwise, it would be more efficient to repeal the ODF
standard and simply establish the OOo code base as the real standard.
 The problem with that is that Sun has exclusive control of the OOo
code base through the various OOo contributors' joint copyright
assignment agreements.

FOSS has real problems because of that exclusive control. Microsoft
claims that it has 45 patents that read on the OOo code base and Sun
signed an agreement in 2004 with Microsoft agreed not to assert its
patents against StarOffice users and Sun agreed not to interfere if
Microsoft sues any other OOo licensee.
<http://www.sec.gov/Archives/edgar/data/709519/000119312504155723/dex10109.htm>.

Any of those patents that read on implementation of the ODF spec
itself need to be worked around in this TC's work. International law
and competition law in both Europe and the U.S., as well as ISO/IEC
policy, require that patents be worked around in standards work unless
their infringement is unavoidable. OASIS IPR policy doesn't deal with
that subject.

And because Sun had patent protection itself while the work on ODF was
being done, no attention was paid to whether the TC's work required
infringe of Microsoft patents to implement. IBM realized this problem
and that is why Lotus Symphony wrote a new GUI for the OOo code base.
But IBM has enough patents on Microsoft's work to prevent Microsoft
from suing IBM for infringement. The rest of the world does not.

We have an incredible mess to clean up, my friend. If we do not
approach the work of this TC in a systematic and organized way,   the
800-pound gorillas will get their needs fulfilled but the rest of the
world's needs will be ignored. CDRF is only part of the structure we
need in this TC's charter.

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