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

[marbux <marbux@gmail.com>]

On Wed, Jun 17, 2009 at 10:33 AM, <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 06/17/2009 04:30:49 PM:
>
>> I would have no issues with having plugfests if any mechanisms had
>> been established for ensuring that the knowledge gained from the
>> plugfests made its way into spec improvements and the  ODF TC had work
>> items on its agenda for specifying the conformity requirements that
>> are essential to achieve interoperability in ODF 1.2, ODF 1.1.and IS
>> 26300. But we have no such mechanisms and those work items don't
>> exist.
>
> Again, you are presuming that the problems found stemmed from ambiguities
> in the standard. I stated up front that I was there ready and willing to
> enter a  defect report against ODF for any defect found, instantly on the
> spot at the plugfest.  But the only two issues that came up related to the
> standard were ones that we already knew about and already had a proposal
> for ODF 1.2 on.

Forgive me for my suspicion that implementers wouldn't implement
things differently if the conformity requirements that are essential
to achieve the interoperably were clearly and unambiguously specified
in ODF. You talk as though you had no clue as to just how grossly
under-specified ODF is. Is that the problem?

I've already given you an interop defect report re conforming markup
being trashed by OOWriter and MS Word 2007 SP 2. If that IBM eagerness
to report spec defect reports you claim really exists, let's see the
corresponding IBM defect report to the TC along with IBM's proposal to
cure it. There's your chance to prove me wrong, Rob. Pump out that
report and proposal.

And I'll note that a proposal for ODF 1.2 does nothing to fix OASIS
ODF 1.0, OASIS ODF 1.0 Second Edition, IS 26300, or ODF 1.1. Do I need
to report this on office-comment or will the stalwart IBM champion of
submitting defect reports against the specs take care of that without
my intervention?

 I know you wish that reality would be more supportive of
> your argument, but it does not seem to oblige you in this matter.  Maybe
> next time.

Hey, Rob, for some reason the Plugfest wiki doesn't seem to provide
any pointers to the the relevant specification requirements. In fact
it doesn't even disclose what version(s) of ODF were being tested.
Makes it seem as though what was being checked was app < > app
sameness in test results, rather than conformance with the spec and
whether the spec might be ambiguous in relevant regard.

That's necessary information for a test suite if it has any tie with a
standard at all. Dave Pawson explains:
<http://www.dpawson.co.uk/nodesets/entries/090612.html>.

>> OASIS ODF 1.0 has 7,415 mandatory requirements, nearly all of them
>> interoperability requirements. IS 26300 has 207 and all mention of
>> interoperability was stripped from it. ODF 1.1 has 224 requirements,
>> and ODF 1.2 committee draft 1 has 272. (Stats I developed.)  If you
>> check the OIC TC Charter that Rob drafted, he's so desperate for
>> something to base conformance on that one deliverable is "A conformity
>> assessment methodology specification, detailing how each provision
>> *and recommendation* in the ODF standard may be tested for
>> conformance." <http://www.oasis-open.org/committees/oic/charter.php>.
>> But recommendations have nothing whatsoever to do with conformance.
>>
>
> Of course we should design tests for the should's as well as the shall's.
> Most standards have recommendations and they are worth testing,

Not as part of "conformance" testing, the word you chose for the OIC
TC Charter. Recommendations can be safely ignored without affecting
the validity of a claim of conformance.

Remember, in a voluntary standards system, a "shall" is a
> matter of conformance, not compliance.  It is merely definitional.

Exactly right except that "definitional" did nothing in context to
deserve the adjective "merely." Recommendations have nothing to do
with conformance.


  The
> only difference between your 7,415 and 207 numbers is the difference
> between the ISO and IETF definitions of "should".

Nope. It's mainly the difference between the ISO/IEC definition of
"may" and the IETF definitions of "may" and "optional." Their
definitions of "should" are roughly equivalent, although IETF has a
somewhat longer definition.


 This is counting angels
> on a pinhead if you ask me.  This is all a paper fiction, since not a
> single line of code in any application that supported OASIS ODF 1.0
> changed when ISO/IEC 26300 was approved.  If no line of code changed, then
> there was zero user impact on interoperability.

Logical fallacy. Zero interop-before the change. Zero interop after
the change.  Difference? Before the change, non-interoperable
implementations could not validly claim conformance. After the change,
non-interoperable implementations could validly claim conformance. The
problem is that there was no code changed after the stripping of the
spec of thousands of mandatory interoperability requirements to create
interoperable implementations. To claim conformance, ODF
implementations would have been required to become interoperable,
which does not equate to "zero user impact on interoperability."

Things bothersome about your argument include:

1. You've used it before and I pointed out its fallacy then but you
now insist that I debunk it again.

2. The stripping of the interoperability requirements was never
authorized by the JTC 1 national standardization body members.

3. There have been precisely zero relevant work items added to the TC
agenda since I pointed out these problems, let alone IBM proposals to
cure them.

>> Against the 272 mandatory requirements in ODF 1.2 CD 1, we have ~
>> 3,915 options and recommendations, each masking a hard-coded "shall"
>> or "shall not" programming decision in the full featured
>> implementations. One might as well say that we have ~ 3.915 interop
>> breakpoints
>>
>
> What you fail to note is that conformance with the Relax NG schema is a
> single "shall" in the text of the standard, but itself comprises over 1000
> specific requirements, expressed in a formal notation.  For an XML-based
> document format, I'd expect that most constraints would be expressed this
> way. In fact some constraints that were expressed in the specification
> text in ODF 1.1 are now expressed as schema type constraints in the ODF
> 1.2 draft.  This is a good thing, but by your distorted calculus would be
> reported as a lessening of interoperability.

That's syntactic conformance that totally ignores the semantics. But
the RFC 2119 definition bounded every option with two mandatory
interoperability requirements whereas the ISO definition gives "may"
its common and ordinary meaning of "permission" without any
interoperabily boundaries.

What British Standards Institute had requested was, "Edit all
provisions to conform to Annex H of the ISO Directives.". But rather
than editing "all provisions" as BSI requested,  the spec was simply
flipped in a single sentence to incorporate by reference the ISO/IEC
definitions in place of the RFC 2119 definitions. I covered all that
and more on the office-comment list, reprinted at
<http://www.universal-interop-council.org/node/41>.

~ 7,192 mandatory interoperability requirements blinked out of
existence and the co-chair of the ODF TC sees no problems because we
still have syntactic conformity requirements (which is debatable
because of sloppy wording as to what is and is not a requirement, but
that's a topic for another day). Rather than fix the spec because of
the disappearance of ~7,192 mandatory interoperability requirements,
the co-chair instead advocates ODF plugfests and simply pretends that
there is no specification under-specification elephant in the room,
all the while pretending that implementers can be counted on to submit
interop fixes to the spec and the TC to adopt such proposals.

Might work on folks who haven't studied the spec, studied the
governing law,  and spent far too much time exploring the TC mail
archives, Rob. But it doesn't work on me. To me, your behavior speaks
far more forcefully than your words. Put specifying "clearly and
unambiguously the conformity requirements essential to achieve the
interoperability" on the TC's agenda as a work item for all adopted
versions and ODF 1.2, then you'll have some moral high ground to speak
from.

Whether you want to instigate plugfests or not, you are the co-chair
of the ODF TC and that TC's responsibility is to fully specify the
standard, not to convene plugfests. If your plugfest fever leaves you
without time to ensure that ODF specifies the conformity requirements
that are essential to achieve the interoperability, then I
respectfully suggest that it's time for you to stand down from the
co-chairmanship and a new chair be found who's willing to commit to
repair of the specification rather than plugfests.

Your repeated suggestions here that application-level interop work
should be given a higher priority than repair of the spec cannot be
reconciled with your legal responsibilities as the co-chair of the ODF
TC.

Best regards,

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

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