[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oic-comment] State of ODF Interoperability ? Draft Rev 0.2 -- Discussion of interoperability
On Tue, Jun 9, 2009 at 8:07 AM, <robert_weir@us.ibm.com> wrote: > marbux <marbux@gmail.com> wrote on 06/09/2009 12:13:33 AM: > ISO/IEC 2382 is the International Standard for IT Vocabulary. So to say > that its use is inapplicable to international standards is absurd. That's a straw man argument. I said its definition of interoperability was "inapplicable to international IT standards," not to all international standards. > Not > only is it permissible, the use of this vocabulary standard is > specifically recommended in ISO Directives Part 2 "Rules for the structure > and drafting of International Standards". ISO/IEC JTC 1 Directives provide in section 1.1: "Where differences between this document and the ISO/IEC Directives exist, the provisions of this document shall govern." <http://www.jtc1sc34.org/repository/0856rev.pdf>, pg. 11. A relevant difference exists between ISO/IEC Directives Part 2's incorporation by reference of ISO/IEC:2382 (generally applicable to international standards of all types) and JTC 1 Directives; the latter's Annex I provides the definition of "interoperability" specific to information technology international standards. The ISO/IEC decision that the JTC 1 Directives take precedence when there is a conflict between that volume and ISO/IEC Directives does no more than restate the common rule of interpretation that more specific requirements take precedence over the more general. See e.g., Simpson v. United States, 435 U.S. 6, 15 (1978), <http://supreme.justia.com/us/435/6/case.html> ("Finally, our result is supported by the principle that gives precedence to the terms of the more specific statute where a general statute and a specific statute speak to the same concern, even if the general provision was enacted later.") JTC 1 Directives are specific to IT international standards. ISO/IEC Directives are the more general, applying by default to all international standards of a technical nature. Because there is a conflict, the more specific JTC 1 Directives definition governs, as is straightforwardly stated at page 11 and quoted above. > This is a policy document, not a standard for IT vocabulary. The section > you quote is in annex to that policy document. You have conveniently > omitted that the sentence you quote begins "For the purpose of this policy > statement, interoperability is understood..." which makes it clear that > the definition is scoped to that specific policy statement, and is not > being set out as a general definition. May I suggest that you spend some time pondering the definition of "annex" and reconcile that meaning with the statement on JTC 1 Directives pg. 11 that: "These Directives shall be complied with *in all respects* and no deviations can be made without the consent of the Secretaries-General." The distinction you perceive does not exist if one consults the dictionary and heeds the last-quoted sentence. > HTML is from authoring tool to reading tool. Although the connection is > mediated by emailing the HTML or posting to a web server rather than > direct tool-to-tool communications, the exact same thing is true of word > processors. My word processor does not communicate directly with yours. I > need to save the document, send it via email, save it in a document > repository, post it on the web, etc. So this is directly analogous to > HTML. Remember, there are word processors that save their documents in > HTML format and there are WYSIWYG HTML authoring environments that are > indistinguishable from word processors. So I don't think you can make an > argument that interoperability of HTML and documents are entirely > different things. That is irrelevant to the paragraph of the draft document under discussion, which discusses HTML in the context of web browsers as its only example of "interoperability." Moreover, the general inability of HTML authoring agents to interoperate is well beyond legendary. The most popular work-around I'm aware of is the XML/RPC protocol, which is ordinarily used only to exchange data between different instances of the same application, not between different IT systems. One need look no further than the W3C Compound Document by Reference Framework to see several types of interoperability conformity requirements missing from HTML (and ODF). <http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>. > JTC1 covers everything from network protocols to optical disc formats to > programming languages to character sets. I think you are stretching > things too far to read JTC1's policy statement on interoperability in such > a narrow sense that it applies only for document formats and not for the > other 99.9% of ISO/IEC standards. That's your straw man, not what I said. What I did say is that JTC 1 Directives apply to "IT international standards." I suppose I might have qualified that further to limit it to IT international standards that are processed by JTC 1. But however you cut it, JTC 1 Directives apply to ISO/IEC:26300 OpenDocument Formats. Indeed, I recall occasions where you cited them yourself in regard to discussion of OOXML's adoption. Remember, when the JTC1 policy > statement was written, there were no ISO standards for office document > formats. You need to read it in a way that it would have make sense at > the time it was written. I need to read it in a way that it would make sense when last adopted, on 5 April 2007. There is no persuasive argument that the Annex containing the interoperability provisions does not apply to ISO/IEC:26300. Shortly before the current version of JTC 1 Directives was adopted, SC 34 sought an exemption from JTC 1 SWG Directives for ODF: "There are no mechanisms by which National Bodies can validate that organizations claiming conformance to the JTC1 standards are actually conforming. SC34 feels that it should be a requirement for all PAS and fast-track submitters to provide National Bodies with conformance procedures. Where standards, such as DIS 26300 [OpenDocument], only require conformance to parts of the standard, there should be clearly documented boundaries, at a high level in the document structure, to which conformance can be claimed. "Response: They felt that there was no way to accomodate [sic] this proposal." Keld Jørn Simonsen, Delegate report from JTC 1 SWG directives meeting - March 7-9, 2007, ISO/IEC JTC 1/SC 34 N0835 (March 22, 2007), section 7, <http://www1.y12.doe.gov/capabilities/sgml/SC34/document/0835.htm>. Less than a month later JTC 1 Directives v. 3.0 was issued with the definition of "interoperability" intact along with the requirement that: "Standards designed to facilitate interoperability need to specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." SWG Directives --- the JTC 1 working group responsible for drafting and maintaining JTC 1 Directives --- was specifically asked to create an exception to that rule in JTC 1 Directives for ODF and just as specifically declined to do so. It was a legally sound decision. Under the Agreement on Technical Barriers to Trade, <http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm#articleII>: "2.2 Members shall ensure that technical regulations [and hence international standards] are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade. For this purpose, technical regulations shall not be more trade-restrictive than necessary to fulfil a legitimate objective, taking account of the risks non-fulfilment would create. Such legitimate objectives are, inter alia: national security requirements; the prevention of deceptive practices; protection of human health or safety, animal or plant life or health, or the environment. ..." This is no more than a restatement of antitrust law governing standards work in industry consortia such as OASIS, but projected to encompass the work of national standards body representatives working in bodies such as JTC 1. So it should come as no surprise that the same requirement extends to all technical standarization activities, whether private or goverrnmental, throughout the territories of member nations. Agreement, supra, Annex 3: "E. 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 Agreement, Article IV: 4.1 Members ... shall take such reasonable measures as may be available to them to ensure that local government and *non-governmental* standardizing bodies within their territories, as well as regional standardizing bodies of which they or one or more bodies within their territories are members, accept and comply with this Code of Good Practice. ... The obligations of Members with respect to compliance of standardizing bodies with the provisions of the Code of Good Practice shall apply irrespective of whether or not a standardizing body has accepted the Code of Good Practice." One must therefore ask whether the ODF lack of specification of conformity requirements that are essential to achieve interoperability has "the effect of, creating unnecessary obstacles to international trade." In this case, we have the word of Rob Weir that *not* specifying interoperability conformity requirements in a standard that are essential to achieve interoperability is *not* the most efficient way to achieve interoperability: "[I]nteroperability is most efficiently achieved by conformance to an open standard where the standard clearly states those requirements which must be met to achieve interoperability." Rob Weir, A Follow-up on Excel 2007 SP2's ODF Support, An Antic Disposition (7 May 2009), <http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html>. I agree with what you said in the passage just quoted. The only mystery is why you believe that ODF should not contain such a specification, a topic you did not address in your quoted article or anywhere else that I know of. There is a good reason that this is a minimum requirement for all JTC 1 international standards: the relevant lack of specificity creates unnecessary obstacles to market entry by competitors, i,e., "unnecessary obstacles to international trade" in the parlance of the Agreement on Technical Barriers to Trade. So why is it necessary to leave blank in ODF the conformity requirements that are essential to achieve the interoperability? Try as I might, I cannot fit ODF into the Agreement's listed exceptions for "national security requirements; the prevention of deceptive practices; protection of human health or safety, animal or plant life or health, or the environment." What is *your* justification for keeping the spec dark and mysterious to implement? What TC agenda item do you believe to be more important than specifying the ODF conformity requirements that are essential to achieve interoperability? Cf., European Committee for Interoperable Systems, "Open Document Formats As An Enabler of Interoperability: Comparison of the Oasis Opendocument Format and Microsoft Office Open XML" (undated but file stamped July 2, 2007), pg. 2, formerly available at <http://www.ecis.eu/inter/documents/ECIS_ODF_OOXML_comparison.pdf> and at <http://osacademy.hosting.amaze.nl:8060/repository/resources/white-papers/ecis_paper_on_odf_ooxml_final.pdf/view>: "The merits of ODF have already been established by its wide industry adoption. As noted above, numerous PPA vendors have implemented support for it in their products both on Windows and on other operating systems. Such widespread adoption is only possible because ODF is *fully disclosed and created to allow for document interoperability* by making it easy for various applications to *exchange* documents with full fidelity, i.e., without any loss of data or formatting of the document." These are not abstract issues. They are vitally important to software users. See e.g., Bob Sutor, Interoperability and Substitutability (5 September 2006), <http://www.sutor.com/newsite/blog-open/?p=1041>: "One of the benefits of interoperability is substitutability: the ability to take one software application from one provider and put in its place another application from a possibly different provider. Open standards enable interoperability and hence substitutability. "... Anything that locks me into software from a single provider is a strong negative. ... "There is another question that I would have that I would try to get answered, even though it might be an unusual query to pose to a salesperson or evangelist. That question is: 'What are the features and characteristics of your software that will let me rip it out and replace it with software from another provider in 6 months, a year, 3 years?' Ouch. "Try putting that into an internal product plan: list of features that let users switch to software from other providers, possibly open source. Have you done that? ... If you provide an ODF-compliant application you have. Providers of software that implement open and non-vendor controlled standards are used to living with the higher level of risk that substitutability engenders. ..." Is this not the TC charged with responsibility to make such ODF interoperability myths come true? Why do you battle against the JTC 1 Directives requirement that this TC do so? "[F]ully disclosed and created to allow for document interoperability?" I ask in response: "What are the features and characteristics of your software that will let me rip it out and replace it with software from another provider in 6 months, a year, 3 years?" Specifying in ODF "clearly and unambiguously the conformity requirements that are essential to achieve the interoperability" would be a good start, yes? > Remember, HTML is also an ISO standard (ISO/IEC 15445:2000). Do you > believe that it is not a "lawful international standard" because it was > "not even designed for interoperability" (by your definition)? Yes. And it is unmistakably HTML's most tragic limitation. The globe is brim full of HTML authoring agents that can't talk to each other. Whatever one might say about the beneficial effects of HTML pale in comparison to what could have been achieved were it actually designed for interoperability as the law requires. It's a "standard" with no thought given to 2-way conversations. It's cut from the paradigm of transmission ---> reception, rather like AM radio. AM radio may be fine for listening to music, but if you want to get some work done with someone else, you pick up the telephone or fire up your eMail client so you can have a 2-way conversation. > Could you point me to a handful of relevant international standards which > you believe are interoperable and lawful by your reading of the applicable > rules and definitions? Irrelevant. We are here interested in what the applicable rules are, not in how how popular the rules are or how often they have been honored or dishonored. Changing the subject is not a favored technique in formal debate. Doing so is generally regarded as a logical fallacy because it evades rather than addresses the merits of the opponent's argument. You have not addressed my central point that "interoperability" means 2-way rather than 1-way exchange of data and mutual use of the data at both ends of the round trip, according to JTC 1 Directives, to the European Community Court of First Instance, to the WTO Appellate Body, and to prior statements by IBM, Sun, and Microsoft spokespersons. I'll throw in another IBM statement to make the point even more clear: "Interoperability is the ability for two different and independent software applications to *exchange* information without loss of data, semantics, or metadata." Bob Sutor, Interoperability More or Less, Bob Sutor's Website and Blog (25 January 2007), <http://www.sutor.com/newsite/blog-open/?p=1372>. Your position is the outlier here, not mine. IBM seemed to have no confusion about the meaning of "interoperability" when arguing against OOXML adoption because of function duplicative of ODF's and insufficient disclosure of interoperability conformity requirements. And somehow, I doubt that IBM through ECIS is currently arguing to DG Competition that the ISO/IEC:2382 definition of "interoperability" applies to OOXML and the specs for the Office binary formats, rather than what the Court of First Instance said the term means. But rather than addressing the weight of the authorities I cited or my explanations that accompanied them, you chose to ignore all but the JTC 1 Directives definition, then mount an attack on it in isolation, and in a manner that did not address whether "interoperability" has a 1-way or 2-way meaning. So I put the question to you directly: Are you advocating for a 1-way definition of "interoperability" for ODF or for leaving that point ambiguous in the TC's report on the state of ODF interoperability? And if not, why are you wasting your time and mine with arguments against an unambiguous 2-way definition of the term in this TC's report on The State of ODF Interoperability? 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]