[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 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]