OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [opendocument-users] simple OO.org document goes awry in MS Office 2007 w/SP2 - what went wrong?


On Fri, Jun 19, 2009 at 12:12 AM, <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 06/19/2009 05:51:19 AM:

>> Please point me to all those interop defect reports IBM has filed
>> against the specification, Rob? I'm apparently suffering a huge memory
>> loss. Not. And even though we deal with a hypothetical situation
>> rather than reality, aren't you presupposing that the TC would adopt
>> the same solution for the problem that you've implemented in your app?
>>  I can already hear the cries like KDE's that if the spec doesn't
>> permit a choice between ordered list tuples and ordered list triples
>> they'll have to write a converter for their legacy documents.
>>
>
> For example, the major theme of ODF 1.1 was accessibility, aka
> interoperability with screen readers for blind users.  IBM took a leading
> role in analyzing the specification to find problems in this area and
> proposing fixes.

Score 1 for IBM after a scandal in Massachusetts that couldn't be
ignored. . And the next IBM interop proposal resulting from user
feedback was ...?

> We're certainly aware of interoperability issues in Symphony, but our
> analysis shows that they are either implementation defects or
> specification ambiguities that are already known and fixed in ODF 1.2.

I thought Symphony wrote ODF 1.1, Rob. Where are the corresponding
proposals to fix ODF 1.1 and IS 26300? And if the spec was so clear
and unambiguous, how did IBM manage to get it wrong to begin with? And
why the lack of concern over the spec saying, "There are no rules
regarding the elements and attributes that actually have to be
supported by conforming applications, except that applications should
not use foreign elements and attributes for features defined in the
OpenDocument schema?"

Oh, that's right. "Should not" creates a conformance requirement in
your book, right? Was that why you were accusing Microsoft of
non-conformance?

> I'm looking at this very pragmatically, Paul.

Can't seem to find "pragmatically" in the Agreement on Technical
Barriers to Trade or JTC 1 Directives, Rob. Got a cite?

Let's do what is necessary
> to improve interoperability, without any presumptions of who or what is to
> blame.  I'm not adverse to improving the specification if that is where
> the problem is.

Rob, there's a huge disconnect between your last statement and your
historical conduct. Your deeds speak louder than your words. You have
no work plan to cure the underspecification problems in ODF. You are
not leading the ODF TC to cure such problems, leaving the TC in a
leadership vacuum, hell-bent on pumping out yet another grossly
under-specified version of the spec.

 But in practical terms, only code can exhibit
> interoperability problems, since users only run code.

Sorry, but isn't this the same guy who argued on the Fellowship list
until he was blue in the face that the JTC 1 Directives only required
that interoperability be demonstrable from the provisions of the spec
rather than demonstrated? Do I have to dig for those links to show yet
another instance of Rob Weir reversing positions whenever it's helpful
to his latest  argument against fully specifying the ODF standard?

> So I think an
> approach, like used at the Plugfest, where we concentrate on user-facing
> scenarios and determine the source of the error and address that error.
> This is an engineering-based approach.

No. It's an approach for keeping the specification dark and mysterious
in defiance of the law and market requirements for standard-based
interoperability, propped up with "trust the big vendors to do the
right thing" excuses. Like I've said on other occasions, IBM has had
53 years to lead us out of the word processor vendor lock-in
wilderness and it still steadfastly resists even the creation of an
open, fully-specified standard.

Let the vendors work it out app to app? No sir. I want my standard
fully specified and out on the table where anyone can use the spec to
compete. The big vendors have had decades to show that
application-level interop work can produce interoperable word
processors.

In my book, when plain text XML came along, the big vendors couldn't
rely anymore on trade secret, moving target, binary formats to
maintain their vendor lock-in / lock-out games. The successor tactic
is grossly underspecified XML standards, accompanied by loud and false
claims that they are "open standards." But they are standards in name
only. Standards are about uniformity, about the substitutability of
products in a market defined by a standard.

Standards are about leveling the competitive playing field by
specifying [i] "any objectively definable 'features', 'qualities',
'attributes', or other 'distinguishing mark'" [ii] of an identifiable
product or group of products [iii] only in mandatory "must" or "must
not" terms. WTDS 135 EC - Asbestos, (World Trade Organization
Appellate Body; 12 March 2001; HTML version), para. 66-70,
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm>
reaffirmed, WTDS 231 EC - Sardines, (World Trade Organization
Appellate Body; 26 September 2002), pp. 41-51,
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds231_e.htm>.

All IBM has come up with these many years has been: [i] excuses that
are beyond lame for keeping ODF under-specified; [ii] personal attacks
usually with a "Microsoft shill" paint brush on people who dare
suggest that ODF is in desperate need of repair so that it can become
a universal standard; and [iii] excuses for keeping OpenOffice.org at
the center of the ODF universe rather than the standard.

In the latter regard, it has not escaped my notice that IBM uses the
OOo code base in its own products and acquired the rights to use the
OOo 3.x code base in its proprietary apps notwithstanding that others
are limited to the LGPL. Whereas IBM earlier worked with the OOo 1.4
code base that was dual-licensed to allow use in proprietary apps, IBM
now tells us that it is implementing OOo 3.x code.
<http://www-03.ibm.com/press/us/en/pressrelease/25912.wss>, with the
transition to that code base scheduled for release in the second half
of 2010.<http://www.ferris.com/2009/01/20/lotus-symphony-hard-to-see-why-it-will-succeed/>.

So I see a rather huge conflict of interest in you as an OASIS agent
cloaked with that organization's authority working to keep the ODF
spec dark and mysterious whilst simultaneously pushing to use OOo as
the ODF reference implementation in lieu of fully specifying the
standard.

>
> You, on the other hand, seem to be advocating an approach that merely
> mandates interoperability and then assumes that the problem goes away. But
> it doesn't work that way.

Straw man argumentation. I've never said anything of the sort.

 Whether interoperability is mandatory or
> voluntary, the engineering effort required to achieve interoperability is
> exactly the same.  Changing 1,000 should's to shall's accomplishes exactly
> nothing for the user.

Oh really? Let's see, "shoulds" can be safely ignored without
affecting the vendor's right to claim conformance. Changing "shoulds"
to "shall" means those vendors can no longer validly claim conformance
unless they obey the "shall." So "shall" puts all implementers doing
the same whilst "should" invites deviation. Deviation being the enemy
of interoperability, I find you in error, Rob.

 In fact it is far easier to get vendors to agree to
> change a should to a shall after they have changed their code (or at least
> committed to changing their code) than to make a change in the standard
> that will automatically leave every implementation non-conformant.  So
> again, the emphasis on finding the practical interoperability problems via
> user-facing scenarios, finding the source of the interoperability problem,
> agreeing on a solution, and implementing the solution.

Implementations wagging the standard at best, Rob. At worst --- what
we've got --- is vendors making excuses for not getting started on
fixing a badly broken spec. What you always ignore is the fact that
specifying the conformity requirements that are essential to achieve
interoperability is a minimum legal requirement for IT standards, a
non-optional feature if you will, that must be in place before the
standard is adopted. You pretend it can be put off in perpetuity,
justifying it by what other people have gotten away with.

But all the while your company is there before DG Competition seeking
an order that Microsoft disclose Office/Sharepoint data formats and
communications protocols with sufficient specificity to place
competitors on an equal footing with Microsoft's own apps. Not
plugfests; specifications. Not someday; ASAP. Not whiney excuses,
disclosure.

No matter how you cut it, it's a double standard, Rob. What would your
lawyers say if Microsoft's lawyers said, "we'll just designate Office
and Sharepoint as reference implementations and convene some
plugfests. Now go away and stop bothering us."

 I think your problem is that Sun and IBM have got a whole bunch of
users locked into the OOo code base and want to keep things that way
by keeping the ODF spec dark and mysterious.

That diagnosis is based on deeds, Rob, not on your words. It's how it
looks from here.

 Best regards,

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]