[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 Wed, Jun 17, 2009 at 10:33 AM, <email@example.com> wrote: > marbux <firstname.lastname@example.org> 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>