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

[marbux <marbux@gmail.com>]

On Mon, Jun 15, 2009 at 1:45 PM, Cody, John (OFT)<John.Cody@cio.ny.gov> wrote:
> Paul:
>
> "Did you set OOWriter to save as ODF 1.1?"
>
>        Yes, I did that when I started the document, hoping for good interoperability.
>
> "I'd suggest reporting the experience to the ODF TC along with a request that they indentify [sic] the relevant portions of the ODF 1.1 and IS 26300 specifications that are ambiguous..."
>
>        Whoa!  Huge conclusory leap, there.  Who said anything is ambiguous in the spec?  Maybe there are other reasons for the failure         here.

Doubtful. Just about everything in the ODF 1.1 spec is ambiguous at
best other than the requirement of validation against the schema after
all foreign elements and attributes are removed and even that
requirement is worded so loosely that one could make a good faith
argument that there is no means of compliance specified in mandatory
terms. (I've got a defect report in progress in that regard.)

ODF 1.1 has 224 occurrences of terms indicative of mandatory
requirements, although 184 of them are "must" and "must not" terms not
defined as mandatory in the specificiation and prohibited for use as
imperatives in ISO/IEC international standards other than for
expressing legal requirements ("shall" and "shall not" are required
for technical imperatives). That is as opposed to 3,891 occurrences of
terms indicative of recommendations or options.  Of those, 3,201 use
the term "option" which is not defined as expressing permission in ODF
1.1. ISO/IEC requires that "may" and "need not" be used to express
permission. Authorities: ODF 1.1 section 1.2 (Notation): ISO/IEC
Directives Part 2 Annex H,
http://www.iec.ch/tiss/iec/Directives-Part2-Ed5.pdf>; word count
statistics I personally generated using OOo 3.x

To boot, nearly all mandatory requirements are nullified by the
provision in ODF 1.1 section 1.5 (Document Processing and Conformance)
reading:

"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."

"Should not" establishes no requirement; it is only a recommendation.
Moreover, according to WordPerfect's Grammatik, a full 25 percent
(nice round number), of verb clauses in ODF 1.1 are stated in the
passive voice; i.e., are mere informative statements as opposed to
normative language.

All of the above may be contrasted with what the law requires for
international standards. A technical regulation (or international
standard) must specify [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),
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds231_e.htm>, pp.
41-51.

Omitting the analysis that gets you there, one may also arrive at the
same duty for for OASIS standards from the Agreement on Technical
Barriers to Trade's ("ATBT") Annnex 3(E) prohibition:

"The standardizing body shall ensure that standards are not prepared,
adopted or applied with a view to, or with the effect of, creating
unnecessary obstacles to international trade."

See also ATBT Article 4(1) as to the applicability to OASIS. Mirroring
language for international standards is found in Article 2(2).
Authority: <ATBT,
http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm>.

ISO/IEC lawyers translated the "no unnecessary obstacles" prohibition
into the IT context as the JTC 1 Directives requirement

"Standards designed to facilitate interoperability need to specify
clearly and unambiguously the conformity requirements that are
essential to achieve the interoperability. Complexity and the number
of options should be kept to a minimum[.]"

ISO/IEC JTC 1 Directives, (5th Ed., v. 3.0, 5 April 2007) pg. 145,
<http://www.jtc1sc34.org/repository/0856rev.pdf>. See also ibid., pg.
11 ("no deviations can be made without the consent of the
Secretaries-General").

The optional features, the recommendations, the "no rules" conformance
exception, and the passive voice clauses in ODF 1.1 mask hard-coded
"shall" and "shall not" programming decisions in the most featureful
implementations (OOo and clones) and represent a failure to "specify
clearly and unambiguously the conformity requirements that are
essential to achieve the interoperability," a failure to "ensure that
standards are not prepared, adopted or applied with a view to, or with
the effect of, creating unnecessary obstacles to international trade."

We are discussing what is in reality a standard in name only, a
partial specification of a de facto (OOo) standard wearing the
disguise of a de jure standard.  All of the big vendors test tons of
documents for validity against the schema, John. Unless you're running
corrupt software, the odds are vanishingly small that you're looking
at anything but the result of ambiguity in the ODF 1.1 standard.

The ODF TC is the correct TC to which to submit reports of the type I
suggested. It is the only TC that has the jurisdiction to generate
repairs to ODF 1.1 or to any other adopted version of ODF. It has
several members who are intimately familiar with the specification and
it is not a significant burden for them to compare your results to the
specification to pinpoint the relevant ambiguities. I think it too
much to expect users to become experts in the specification and its
implementing code in order to generate an ODF bug report to the ODF
TC, particularly when the specification is largely a blank canvas.

I suggest that when you can disclose the document, you send it to the
mailing list I mentioned along with screen grabs of the rendering in
the two apps.

>        Is there an ODF TC for Interoperability Failures?  The last thing I want to do is bother the TC with comments not related to their      activities, and not demonstrably an ODF problem.

Yes, there is such a TC. It's the ODF TC. Both vendors whose products
you are having interoperability issues with are represented there. It
is expected that not all bug reports will prove to be bugs in the
specification. Some may at least in theory prove to be the result of
an implementation's non-conformance. But we're a long way from the
point where an appreciable fraction of interop bugs are not due to
ambiguities in the specification. All comments received on the
office-comment mailing list are transposed to and managed from an
issue tracking system.
<http://tools.oasis-open.org/issues/secure/ManageFilters.jspa>.

The important thing in my opinion is that the ODF TC not be deprived
of the information that could help identify bugs in the specification.
There are a multitude of them and interop feedback from users is
critically important.

>
> "... using OOo as a de facto reference implementation is problematic because it is a moving target not under the control of the ODF TC."
>
>        I don't see the problem.  It's open source, so in a sense it is under their and everybody's control.

That sense is in reality no more than hypothetical. The reality is
that Sun Microsystems holds the only key to the lock on the OOo code
base. See e.g., Sun Contributors Agreement,
<http://www.openoffice.org/licenses/sca.pdf> and its predecessor OOo
Joint Copyright Assignment,
<http://bn.openoffice.org/files/documents/182/2198/jca.pdf>. Sun's
continued refusal to share keys to that lock has been controversial
because it had publicly promised when it open sourced what became OOo
that it would transfer OOo governance to a non-profit foundation in
which it would hold only a minority stake.
<http://www.openoffice.org/press/sun_release.html> and
<http://www.linuxtoday.com/news_story.php3?ltsn=2000-07-19-016-04-PS-DT-SW>.
As to the controversy, see e.g.,
<http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9037499>
(quoting Novell and IBM representatives).

The likelihood that anyone would make the heavy investment necessary
to create a true fork of OOo is about zero.  That's doubly so because
Sun signed over to Microsoft the right to sue any OOo user or
developer downstream from Sun for patent infringement without Sun's
interference. See section IV of their 2004 Patent Covenant,
<http://www.sec.gov/Archives/edgar/data/709519/000119312504155723/dex10109.htm>.
Microsoft has claimed to hold 45 patents that read on OOo. Roger
Parloff, Microsoft Takes On the Free World, Fortune (14 May 2007),
<http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/>
("The Open Office suite of programs, which is analogous to Microsoft
Office, infringes 45 more").  It's hard to imagine anyone investing
the big bucks to maintain a true fork from Sun's version with the
Microsoft patent sword hanging over its head.

So far, I haven't seen anyone who has a glimmer of just how much
investment it would require arguing that the fact that OOo is open
source means there is no  OOo vendor lock-in effect. See e.g.,
<http://www.computerworlduk.com/community/blogs/index.cfm?entryid=2243&blogid=14>
(last paragraph). There plainly is such a lock-in because ODF is so
grossly under-specified that the interoperability of any
implementations has not yet been demonstrated, at least in published
form. And from the published information available, the
interoperability of ODF implementations is very poor. See e.g., the
sources collected in my comment on this blog post.
<http://www.nwprogressive.org/weblog/2009/01/review-free-openofficeorg-writer.html?ext-ref=comm-sub-email>.
See also reports being generated today at the ODF Plugfest in The
Netherlands, <http://plugtest.opendocsociety.org/doku.php?>,
"Scenarios" link in the left sidebar.

 > And reference implementations     are typically not under standards
bodies' > control, are they?

If there are any reference implementations that have been officially
designated by a de jure standards body as a reference implementation
but are not controlled by the standards body, I have not encountered
one yet. To do so would be highly problematic, as is the case with the
current buzz around using OpenOffice.org as the ODF reference
implementation in lieu of fixing the specification.

One problem is that a single vendor thereby controls what the standard
means. A single vendor's "implementation" tail would be allowed to wag
the "standard" dog, as is currently being advocated for designating
OOo to fill in the numerous data gaps in ODF.

But particularly with industry standard setting consortia like OASIS,
the law is quite clear that standards must be arrived at by consensus
procedures among vendors that ensure standards are not
anti-competitive. See e.g., Allied Tube & Conduit v. Indian Head, Inc.
486 U.S. 492, 500-508 (1988),
<http://laws.findlaw.com/us/486/492.html>, especially ibid. at 509-510
("we hold that at least where, as here, *an economically interested
party exercises decisionmaking authority in formulating a product
standard for a private association that comprises market
participants,* that party enjoys no Noerr immunity from any antitrust
liability flowing from the effect the standard has *of its own force*
in the marketplace").

> Thanks for the thoughts, Paul, but only the version 1.1. comment is on point.

Might we agree to disagree on that?

Best regards,

Paul

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