From lars at umich.edu Mon Jan 5 03:54:40 2009 From: lars at umich.edu (=?UTF-8?B?TGFycyBOb29kw6lu?=) Date: Mon Jan 5 04:04:31 2009 Subject: [odf-discuss] ODF in Brazil Message-ID: <4961CAD0.6070702@umich.edu> OpenDocument Format is now required in Brazil: http://opendotdotdot.blogspot.com/2009/01/major-win-for-odf-in-brazil.html -Lars From marbux at gmail.com Mon Jan 5 06:51:33 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 5 06:51:38 2009 Subject: [odf-discuss] Microsoft's implementation of ODF 1.1 Message-ID: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com> . Jesper Lund Stocholm asks Microsoft's Doug Mahugh a right-on-the-mark question: > Doug, > > The list of elements and attributes "not supported > in core Word/Excel/PowerPoint 2007" is quite long. > Can you tell us what will happen, when Office 2007 > encouters an unsupported element. > > Will it simply be ignored? > > When roundtripping - will it be deleted or preserved? Peter Amstein answers for Doug Mahugh: > Jesper, > On load, Office 2007 SP2 will simply ignore the > unsupported elements and attributes in ODF files. > We do not attempt to round trip unsupported elements > and attributes, they will be removed from the ODF > file if you resave it using Office 2007 SP2. This is > consistent with our implementation principles and our > desire to provide predictable behavior. We > considered trying to roundtrip elements and attributes > that we do not understand or support, but we found if > we did this that we could not be sure the resulting files > were internally consistent and conformant ODF files. > > As an aside, there are some cases where we write > elements or attributes on save that we do not support > on load, for the sake of better interoperability with > other applications that use ODF. Those cases are > described in the implementer notes as well. Cf., ODF v. 1.1 section 1.5 states in relevant part: > "Conforming applications *either* shall read documents > that are valid against the OpenDocument schema if > all foreign elements and attributes are removed > before validation takes place, or shall write documents > that are valid against the OpenDocument schema if all > foreign elements and attributes are removed before > validation takes place. > > ... > > "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." One moral of the story: If you sign a check in blank and leave it lying on the street, someone is apt to pick it up and fill in an amount that will cause you some discomfort. Standards are no different. Also, in my opinion nothing in the latest draft of the conformance section for ODF v. 1.2. blocks Microsoft from doing the same with ODF v. 1.2. . Best regards, Paul -- Universal Interoperability Council From jomar.silva at br.odfalliance.org Mon Jan 5 10:29:41 2009 From: jomar.silva at br.odfalliance.org (Jomar Silva) Date: Mon Jan 5 10:28:51 2009 Subject: [odf-discuss] ODF in Brazil In-Reply-To: <4961CAD0.6070702@umich.edu> References: <4961CAD0.6070702@umich.edu> Message-ID: <49622765.7050005@br.odfalliance.org> This was a hard one to get ready :) Best, Jomar Lars Nood?n escreveu: > OpenDocument Format is now required in Brazil: > http://opendotdotdot.blogspot.com/2009/01/major-win-for-odf-in-brazil.html > > -Lars > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3698 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20090105/2332b479/smime.bin From adjb at adjb.net Mon Jan 5 12:22:25 2009 From: adjb at adjb.net (Alex Brown) Date: Mon Jan 5 12:40:13 2009 Subject: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com> References: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com> Message-ID: <496241D1.4060304@adjb.net> marbux, all, A similar laxity in conformance requirements for ISO/IEC 29500 (OOXML) was somewhat addressed by the introduction of the notion of "application descriptions" at that standard's BRM (this was a joint UK-Portugal initiative; the world's oldest treaty lives on ...). By this mechanism "application descriptions" may be defined which enumerate the features an application must support. The idea is that such desciptions might be used when procuring systems. By default, two such descriptions are provided for 29500, "base" and "full" (in which "an application conforming to this description has a semantic understanding of every feature"). Such a feature might usefully be added to ODF. In fact probably _should_ be added. Personally, I believe an application description might also be defined for OOXML and ODF which prohibits the use of XML elements/atributes that are not explictly defined within the schemas. This would prohibit ad hoc extensions to the format in anything other than an explicit way. As it is, you are correct - the application conformance bar for ODF (all flavours) is not set high, in fact it is resting on the ground. - Alex. marbux wrote: > . > > Jesper Lund Stocholm asks Microsoft's Doug Mahugh a right-on-the-mark question: > > >> Doug, >> >> The list of elements and attributes "not supported >> in core Word/Excel/PowerPoint 2007" is quite long. >> Can you tell us what will happen, when Office 2007 >> encouters an unsupported element. >> >> Will it simply be ignored? >> >> When roundtripping - will it be deleted or preserved? >> > > Peter Amstein answers for Doug Mahugh: > > >> Jesper, >> > > >> On load, Office 2007 SP2 will simply ignore the >> unsupported elements and attributes in ODF files. >> We do not attempt to round trip unsupported elements >> and attributes, they will be removed from the ODF >> file if you resave it using Office 2007 SP2. This is >> consistent with our implementation principles and our >> desire to provide predictable behavior. We >> considered trying to roundtrip elements and attributes >> that we do not understand or support, but we found if >> we did this that we could not be sure the resulting files >> were internally consistent and conformant ODF files. >> >> As an aside, there are some cases where we write >> elements or attributes on save that we do not support >> on load, for the sake of better interoperability with >> other applications that use ODF. Those cases are >> described in the implementer notes as well. >> > > Cf., ODF v. 1.1 section 1.5 states in relevant part: > > >> "Conforming applications *either* shall read documents >> that are valid against the OpenDocument schema if >> all foreign elements and attributes are removed >> before validation takes place, or shall write documents >> that are valid against the OpenDocument schema if all >> foreign elements and attributes are removed before >> validation takes place. >> >> ... >> >> "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." >> > > One moral of the story: If you sign a check in blank and leave it > lying on the street, someone is apt to pick it up and fill in an > amount that will cause you some discomfort. Standards are no > different. > > Also, in my opinion nothing in the latest draft of the conformance > section for ODF v. 1.2. blocks Microsoft from doing the same with ODF > v. 1.2. . > > Best regards, > > Paul > > From marbux at gmail.com Mon Jan 5 14:00:45 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 5 14:07:19 2009 Subject: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <496241D1.4060304@adjb.net> References: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com> <496241D1.4060304@adjb.net> Message-ID: <2c60d980901051100g7cf54b99uda82a604a2cb2ba7@mail.gmail.com> On Mon, Jan 5, 2009 at 9:22 AM, Alex Brown wrote: > > A similar laxity in conformance requirements for ISO/IEC 29500 (OOXML) > was somewhat addressed by the introduction of the notion of "application > descriptions" at that standard's BRM (this was a joint UK-Portugal > initiative; the world's oldest treaty lives on ...). > > By this mechanism "application descriptions" may be defined which > enumerate the features an application must support. Something like that is in the ODF TC charter, albeit not in the "deliverables" list: "1. In the first phase, this TC has used proven and established constructs so that the resulting standard can satisfy the immediate needs of many users, as well as serve as a base for future, less restricted development. The work of this TC in the first phase has concentrated on the following areas: "... "b. establishing a set of 'core' elements and attributes to be supported by all implementations," . Unfortunately, the core elements and attributes wound up in an informational annex (pg. 724 in ODF 1.1) without any corresponding conformity requirements. The idea is that > such desciptions might be used when procuring systems. By default, two > such descriptions are provided for 29500, "base" and "full" (in which > "an application conforming to this description has a semantic > understanding of every feature"). > The latest draft of the conformance section for ODF 1.2 takes a very loosely similar approach, defining two classes of conformance, strictly and loosely conforming. . But in my opinion the language is so poorly worded that there are more loopholes than substance. With both OOXML and ODF, there is nothing approaching what JTC 1 Directives Annex I (pg. 145) requires for international standards, which are expected to "clearly and unambiguously specify the conformity requirements essential to achieve the interoperability." . > Such a feature might usefully be added to ODF. In fact probably _should_ > be added. > > Personally, I believe an application description might also be defined > for OOXML and ODF which prohibits the use of XML elements/atributes that > are not explictly defined within the schemas. This would prohibit ad hoc > extensions to the format in anything other than an explicit way. I think you'll hit major big vendor resistance on that issue. I certainly did. Rob Weir in particular has been insistent that conformant status be granted for application-specific extensions. E.g., "You can certainly define conformance in a way that accounts for extensions. For example, ISO C Programming Language (ISO/IEC 9899:1999) has a statement in their conformance clause that reads: "An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all extensions." An example of such documentation is what the GNU gcc compiler provides: http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html "I'm going to push for a statement like that to be added to ODF 1.2. The phrase 'implementation-defined' should not be a meaningless statement. You need that conformance requirement to put teeth behind the phrase 'implementation-defined'. "I don't think you'll ever eliminate vendor extensions." . The governing law is contrary: A technical regulation must specify [i] all characteristics [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), ?? 66-70, ; reaffirmed and further explained, WTDS 231 EC - Sardines, pp. 41-51 (World Trade Organization Appellate Body; 26 September 2002), pp. 41-51, . (Under the Agreement on Technical Barriers to Trade the same document must simultaneously be capable of serving as both an international standard and a technical regulation (and as a procurement technical specification under the Agreement on Government Procurement), so those two precedents apply.) [more] > As it is, you are correct - the application conformance bar for ODF (all > flavours) is not set high, in fact it is resting on the ground. Unfortunately, yes. It's an international standard in name only, lacking even implementations. Best regards, Paul -- Universal Interoperability Council From jomar.silva at br.odfalliance.org Mon Jan 5 14:32:14 2009 From: jomar.silva at br.odfalliance.org (Jomar Silva) Date: Mon Jan 5 14:47:30 2009 Subject: Res: Re: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901051100g7cf54b99uda82a604a2cb2ba7@mail.gmail.com> References: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com><496241D1.4060304@adjb.net><2c60d980901051100g7cf54b99uda82a604a2cb2ba7@mail.gmail.com> Message-ID: <1913687334-1231184138-cardhu_decombobulator_blackberry.rim.net-1851798295-@bxe128.bisx.prod.on.blackberry> I really support Rob's proposal, and you misunderstood it. His proposal was presented to solve the 'application specific' implementation of a lot of ODF attributes. It solves the problem, stating that all 'application specific' implementation must have its documentation available and if the responsible for the implementation thinks that his feature is important/relevant to most users, it is recommended that his documentation is submitted to the ODF TC as a proposal. At least in Brazil, during the OOMXL discussion we have a lot of troubles regarding application behavior and application specific implementation, because it is a "dark area". Rob's proposal put some light on it :) Best, Jomar -----Original Message----- From: marbux Date: Mon, 5 Jan 2009 11:00:45 To: ODF Discussion List Subject: Re: [odf-discuss] Microsoft's implementation of ODF 1.1 On Mon, Jan 5, 2009 at 9:22 AM, Alex Brown wrote: > > A similar laxity in conformance requirements for ISO/IEC 29500 (OOXML) > was somewhat addressed by the introduction of the notion of "application > descriptions" at that standard's BRM (this was a joint UK-Portugal > initiative; the world's oldest treaty lives on ...). > > By this mechanism "application descriptions" may be defined which > enumerate the features an application must support. Something like that is in the ODF TC charter, albeit not in the "deliverables" list: "1. In the first phase, this TC has used proven and established constructs so that the resulting standard can satisfy the immediate needs of many users, as well as serve as a base for future, less restricted development. The work of this TC in the first phase has concentrated on the following areas: "... "b. establishing a set of 'core' elements and attributes to be supported by all implementations," . Unfortunately, the core elements and attributes wound up in an informational annex (pg. 724 in ODF 1.1) without any corresponding conformity requirements. The idea is that > such desciptions might be used when procuring systems. By default, two > such descriptions are provided for 29500, "base" and "full" (in which > "an application conforming to this description has a semantic > understanding of every feature"). > The latest draft of the conformance section for ODF 1.2 takes a very loosely similar approach, defining two classes of conformance, strictly and loosely conforming. . But in my opinion the language is so poorly worded that there are more loopholes than substance. With both OOXML and ODF, there is nothing approaching what JTC 1 Directives Annex I (pg. 145) requires for international standards, which are expected to "clearly and unambiguously specify the conformity requirements essential to achieve the interoperability." . > Such a feature might usefully be added to ODF. In fact probably _should_ > be added. > > Personally, I believe an application description might also be defined > for OOXML and ODF which prohibits the use of XML elements/atributes that > are not explictly defined within the schemas. This would prohibit ad hoc > extensions to the format in anything other than an explicit way. I think you'll hit major big vendor resistance on that issue. I certainly did. Rob Weir in particular has been insistent that conformant status be granted for application-specific extensions. E.g., "You can certainly define conformance in a way that accounts for extensions. For example, ISO C Programming Language (ISO/IEC 9899:1999) has a statement in their conformance clause that reads: "An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all extensions." An example of such documentation is what the GNU gcc compiler provides: http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html "I'm going to push for a statement like that to be added to ODF 1.2. The phrase 'implementation-defined' should not be a meaningless statement. You need that conformance requirement to put teeth behind the phrase 'implementation-defined'. "I don't think you'll ever eliminate vendor extensions." . The governing law is contrary: A technical regulation must specify [i] all characteristics [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), ?? 66-70, ; reaffirmed and further explained, WTDS 231 EC - Sardines, pp. 41-51 (World Trade Organization Appellate Body; 26 September 2002), pp. 41-51, . (Under the Agreement on Technical Barriers to Trade the same document must simultaneously be capable of serving as both an international standard and a technical regulation (and as a procurement technical specification under the Agreement on Government Procurement), so those two precedents apply.) [more] > As it is, you are correct - the application conformance bar for ODF (all > flavours) is not set high, in fact it is resting on the ground. Unfortunately, yes. It's an international standard in name only, lacking even implementations. Best regards, Paul -- Universal Interoperability Council From marbux at gmail.com Mon Jan 5 16:32:17 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 5 16:32:23 2009 Subject: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <1913687334-1231184138-cardhu_decombobulator_blackberry.rim.net-1851798295-@bxe128.bisx.prod.on.blackberry> References: <2c60d980901050351lc57c89u46f1c93a89a4d4e4@mail.gmail.com> <496241D1.4060304@adjb.net> <2c60d980901051100g7cf54b99uda82a604a2cb2ba7@mail.gmail.com> <1913687334-1231184138-cardhu_decombobulator_blackberry.rim.net-1851798295-@bxe128.bisx.prod.on.blackberry> Message-ID: <2c60d980901051332x7b5b1dcbn465c43704120af3b@mail.gmail.com> On Mon, Jan 5, 2009 at 11:32 AM, Jomar Silva wrote: > I really support Rob's proposal, and you misunderstood it. > > His proposal was presented to solve the 'application specific' implementation of a lot of ODF attributes. It solves the problem, stating that all 'application specific' implementation must have its documentation available and if the responsible for the implementation thinks that his feature is important/relevant to most users, it is recommended that his documentation is submitted to the ODF TC as a proposal. > > At least in Brazil, during the OOMXL discussion we have a lot of troubles regarding application behavior and application specific implementation, because it is a "dark area". Rob's proposal put some light on it :) Application-specific elements and attributes are the antithesis of an IT standard. Having documentation available for elements and attributes not specified by the standard does nothing for the quality of the standard. As Rob said to Microsoft's Doug Mahugh in regard to Microsoft's later release of documentation for information omitted from DIS-29500: "But the qualities of the format were set the day the standard was approved by Ecma. The standard does not gain capabilities by Microsoft writing code. Microsoft applications may gain capabilities, but the standard is what it is, and is as compatible as it is going to get the day it was standardized." I'm sorry that I must disagree with you. I did not misunderstand what Rob said on this list previously. Please read my entire conversation with Rob in the thread I quoted from. Rob vigorously advocated for implementations that are incapable of writing to unextended ODF being classified as conformant. See e.g., . ("In other words, I don't believe that the JTC1 requirements prevent a standard from defining conformance in a way that allows conformant applications from also allowing vendor extensions.") See also ("Note that with ODF, even vendor extensions have requirements, such as being in a different namespace, and these requirements are testable.") Near the close of the conversation, I asked Rob: "I will close by asking whether you see a benefit to be gained in continuing this conversation? My perception of your position (and please tell me if I have this wrong) is that ODF 1.2 under your leadership: [i] will grant conformant status to vendor-specific extensions; [ii] will grant conformant status to editors that do not support the complete schema for a given application type; [iii] will not clearly and unambiguously specify the conformity requirements essential to achieve the interoperability; [iv] will not require that implementations claiming conformity demonstrate the interoperability; and [v] will not specify all characteristics of the ODF file formats in mandatory terms. If I have correctly understood your position on these issues, I have sufficient information to form an opinion as to the direction the ODF TC is heading." . Rob objected to one clause in that summary of his position and I suggested the following clarifying language: "Pardon the careless wording, please. Does this rewrite of item 1 fix the objection? "[i] will classify documents containing markup for vendor-specific extensions as conformant;"? Rob did not reply so I assume that the rewrite met his concerns with my summary of his position. In fact, Rob went so far in that conversation as to characterize ODF as a vocabulary for development of profiles, as opposed to an IT technical standard: "I see a standard as providing a shared vocabulary for buyers and sellers to express their requirements. Some users, like IDABC will seek applications that do not extend ODF. ODF should provide a way of expressing the technical side of that requirement. Other users will have stricter requirements. Maybe archivists want to express the requirement that all fonts be embedded and that no object embedding (OLE) is used, and no macros or script is used. So, something similar to PDF/A. If so, ODF should provide a conformance class to express that technical requirement. And so on. We can do these in the standard itself, or as separate profiles. But I don't think we can express a prohibition against proprietary extensions as a technical requirement." . A "standard" that allows vendors to claim conformance while writing application-specific elements and attributes is not a standard. Standards are about uniformity, not about product differentiation. ODF and OOXML are not true standards precisely because do not specify all characteristics of an identifiable product or group of products only in mandatory "must" or "must not" terms. Interoperability is not a feature of an IT standard; it is the very essence of an IT standard. As was said by Microsoft standards attorney David Rudin: "The ultimate purpose of a software standard is to enable interoperability between different products and services. If there is no need for interoperability, there is little if any need for a common standard. The point of a standard is to make it possible for devices and services from different providers to work together." Or as was said by the IBM-backed European Committee for Interoperable Systems: "Interoperability is a cornerstone of the ICT industry. In today's networked ICT environments, devices do not function purely on their own, but must interact with other programs and devices. A device that cannot interoperate with the other products with which consumers expect it to interoperate is essentially worthless. It is interoperability that drives competition on the merits and innovation. The ability of different computer products to interoperate allows consumers to choose among them. Because consumers can choose among them, interoperable products must compete with one another, and it is this competition that has driven innovation in the software industry." The problem really is that the big vendors do not practice what they preach. With both ODF and OOXML, interoperability is a "someday" thing. Best regards, Paul -- Universal Interoperability Council From robert_weir at us.ibm.com Mon Jan 5 19:59:08 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Mon Jan 5 20:38:26 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 Message-ID: odf-discuss-bounces@opendocumentfellowship.com wrote on 01/05/2009 04:32:17 PM: >Standards are about uniformity, not about product differentiation. ODF >and OOXML are not true standards precisely because do not specify all >characteristics of an identifiable product or group of products only >in mandatory "must" or "must not" terms. Hi Paul, I think the above is at the core of your argument. So I understand your position perfectly, are you asserting that a standard is only permitted to include mandatory requirements, e.g., those expressed by "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF practice? Further, are you asserting that a standard that includes even a single optional requirement or recommendation, e.g., a "should" or "should not" in ISO practice, or expresses an implementation option, e.g., "may" in ISO practice, is not a "real standard", or is an unlawful standard, or is a standard that may not be specified as a requirement for government procurement? Regards, -Rob From marbux at gmail.com Tue Jan 6 07:59:19 2009 From: marbux at gmail.com (marbux) Date: Tue Jan 6 07:59:23 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: Message-ID: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> On Mon, Jan 5, 2009 at 4:59 PM, wrote: > odf-discuss-bounces@opendocumentfellowship.com wrote on 01/05/2009 > 04:32:17 PM: > >>Standards are about uniformity, not about product differentiation. ODF >>and OOXML are not true standards precisely because do not specify all >>characteristics of an identifiable product or group of products only >>in mandatory "must" or "must not" terms. > > Hi Paul, I think the above is at the core of your argument. So I > understand your position perfectly, are you asserting that a standard is > only permitted to include mandatory requirements, e.g., those expressed by > "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF > practice? Were it only so simple. No. But the product *characteristics* -- in the instant case, electronic document formats -- may only be specified in such terms. You have to distinguish between specification of product characteristics and other aspects of a standard. One key to understanding is the interchangeability, or substitutability, of the products in the marketplace that is the object of standards. E.g., a 1-pound bag of flour should weigh the same regardless of who produces the flour. The consumer is supposed to know what to expect when they buy "a pound" of something, regardless of the manufacturer. So too when they acquire an app whose developers claim to produce conforming ODF documents. Different methods might be used to manufacture the product, but the end product must be the same, within the limits of tolerances that are responsive to market requirements and technical feasibility. --- Which is a rather complicated way of saying that either the wrenches made by one group of companies *must* be capable of interoperating with those bolts and nuts made by still other companies or something has gone awry in the standard setting process for nuts, bolts, and wrenches, or one of the above is non-conforming. :-) At the same time, options are proper in at least three circumstances: [i] when specifying alternative methods to achieve the same result; [ii] when expressing tolerances; and [iii] when specifying a group of related products. E.g., you MAY do either this or that but the result MUST be X. The thread width MAY vary but MUST fall within the range of Y +/- Z. You MAY implement only this subset but if you do you MUST NOT claim conformance with the superset. Further, are you asserting that a standard that includes even a > single optional requirement or recommendation, e.g., a "should" or "should > not" in ISO practice, or expresses an implementation option, e.g., "may" > in ISO practice, is not a "real standard", or is an unlawful standard, or > is a standard that may not be specified as a requirement for government > procurement? No. "Should" and "should not" are only informational; they establish no normative requirements. Who can object to more information? And as mentioned above there are proper roles for options. But the only room for options in specifying product characteristics turns on the substitutability of the products in the market. If one conforming implementation of .ODT produces a document that can't be fully processed by another conforming implementation, it's a broken standard. Another way you might look at it is that standards are supposed to define markets where all can compete on equal terms because they are all producing the same product. The benefit to society is that with a more stable product, manufacturers can invest more in lowering production costs and thereby lowering the cost to consumers. I think this an important point: standards are supposed to be agreements not to compete on the basis of product differentiation, but rather on price, quality, and customer service. See e.g., Allied Tube & Conduit v. Indian Head, Inc., 486 U.S. 492 (1988), . ("Agreement on a product standard is, after all, implicitly an agreement not to manufacture, distribute, or purchase certain types of products.") In reality this isn't mysterious. E.g., IBM's Jochen Friedrich recently wrote: "... ODF has been successfully implemented by a number of vendors and application developers. Implementations include OpenOffice; Star Office; Google Docs & Spreadsheets; K-Office; Scribus; Abiword; ajaxWrite; Zoho Writer; Ichitaro; IBM Lotus/Domino; IBM Workplace; Mobile Office; Gnumeric; Neo Office; Hancom Office. In other words: all of these applications use the same standard, ODF; all of them produce files with the extension .odt for text documents, .ods for spreadsheets and .odp for presentations; and these files can be opened, read and edited by either application implementing the ODF standard. This is interoperability at its best. "Consequently, customers freely choose the applications based on look and feel, functionality, cost, or other criteria, without worrying about purchasing a specific, single-vendor software in order to work with their documents. ..." Trond Arne Undheim and Jochen Friedrich, The Momentum of Open Standards - a Pragmatic Approach to Software Interoperability, 5 European J. ePractice, pg. 5 (31 October 2008), . In a similar vein, the IBM-backed ECIS used to say on its web site: "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." 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 The only thing missing from those descriptions is reality. Both describe what should be rather than what is. But if ECIS can comprehend the importance of ODF being "fully specified," I guess the only mystery is why you do not. The legal requirements are not a mystery. An international standard is lawful only if it specifies [i] all characteristics [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), ?? 66-70, : "... the 'characteristics' of a product include, in our view, any objectively definable 'features', 'qualities', 'attributes', or other 'distinguishing mark' of a product." ... "'... compliance' with the 'product characteristics' laid down in the 'document' must be 'mandatory'. A 'technical regulation' must, in other words, regulate the 'characteristics' of products in a binding or compulsory fashion." ... "'Product characteristics' may, in our view, be prescribed or imposed with respect to products in either a positive or a negative form. That is, the document may provide, positively, that products must possess certain 'characteristics', or the document may require, negatively, that products must not possess certain 'characteristics'. In both cases, the legal result is the same: the document 'lays down' certain binding 'characteristics' for products, in one case affirmatively, and in the other by negative implication." I don't know how the Appellate Panel might have been more clear on this point. But any options specified must by law fit *under* that criteria. JTC 1 Directives are in accord. The Directives state: "... interoperability is understood to be the ability of two or more IT systems to exchange information at one or more *standardised interfaces* and to make mutual use of the information that has been exchanged. An IT system is a set of IT resources providing services at one or more interfaces. ... "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[.]" There is no "standardised interface" in ODF. Likewise, there is no specification of "the conformity requirements that are essential to achieve the interoperability." And how does one reconcile that ocean of options in ODF with the requirement of minimizing complexity and the number of options? I assume you do not suggest that OpenOffice.org, Lotus Symphony, and StarOffice coders actually use "optional," "may," "should," and "should not" as programming constructs? Do not virtually all of those ambiguities in ODF mask hard-coded "must" and "must not" programming decisions in the implementations? What's the big benefit to customers in keeping ODF dark and mysterious, in preserving all those "optional" interoperability breakpoints? My recent conclusion on ODF 1.1, comparing my stats with Dave Pawson's: "Juxtaposing the 227 maximum conformance requirements statistic shown in the attached document with Pawson's report, one may divine that no more than 227 of the 2,578 testable paragraphs he could identify are conformance requirements, or restated, a maximum possible 8.8 per cent of testable paragraphs state conformance requirements. The rest are apparently mere options or recommendations." . Not a pretty picture and the ODF and OIIC TCs doesn't seem to be doing a thing about it. It looks to me as though the best hope for salvaging ODF is SC 34. Is that the way IBM wants things to be? Best regards, Paul -- Universal Interoperability Council From robert_weir at us.ibm.com Tue Jan 6 10:45:13 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Tue Jan 6 11:05:13 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> Message-ID: odf-discuss-bounces@opendocumentfellowship.com wrote on 01/06/2009 07:59:19 AM: > Sent by: > > On Mon, Jan 5, 2009 at 4:59 PM, wrote: > > odf-discuss-bounces@opendocumentfellowship.com wrote on 01/05/2009 > > 04:32:17 PM: > > > >>Standards are about uniformity, not about product differentiation. ODF > >>and OOXML are not true standards precisely because do not specify all > >>characteristics of an identifiable product or group of products only > >>in mandatory "must" or "must not" terms. > > > > Hi Paul, I think the above is at the core of your argument. So I > > understand your position perfectly, are you asserting that a standard is > > only permitted to include mandatory requirements, e.g., those expressed by > > "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF > > practice? > > Were it only so simple. No. But the product *characteristics* -- in > the instant case, electronic document formats -- may only be specified > in such terms. You have to distinguish between specification of > product characteristics and other aspects of a standard. > Is this a definition or a requirement? In other words, I could argue that product characteristics are by definition those provisions of a standard which are mandatory. But that does not forbid a standard from allowing additional dimensions of variability. > One key to understanding is the interchangeability, or > substitutability, of the products in the marketplace that is the > object of standards. E.g., a 1-pound bag of flour should weigh the > same regardless of who produces the flour. The consumer is supposed to > know what to expect when they buy "a pound" of something, regardless > of the manufacturer. So too when they acquire an app whose developers > claim to produce conforming ODF documents. > OK. But the standard might not specify the color of the bag. That might be an allowed dimension of variability and vendors might differ in what color bag they use. There might also be tolerance in how finely the flour is ground, the protein content per gram, etc. Depending on ones use of bag of flour, this may or may not be appropriate. If you are doing dietetic testing in lab mice you might instead need stronger guarantees and adopt a profile of the standard for "1 pound bag of flour with 1% water content by weight and 4gm protein per ounce". There is nothing wrong with that. The need, by some users, to have a finer set of restrictions for a bag of flour does not make the base standard illegitimate or not useful for those who are satisfied with the variability inherent in it. If there are divergent requirements, rather than creating one monster standard that has everything, you typically factor it into a family of standards, or a standard with profiles, or a standard with conformance classes, or a modular standard, etc. > Different methods might be used to manufacture the product, but the > end product must be the same, within the limits of tolerances that are > responsive to market requirements and technical feasibility. --- Which > is a rather complicated way of saying that either the wrenches made > by one group of companies *must* be capable of interoperating with > those bolts and nuts made by still other companies or something has > gone awry in the standard setting process for nuts, bolts, and > wrenches, or one of the above is non-conforming. :-) > A standard does not mandate interoperability. There is really no way it can. A standard can only define conformance. Whether a particular real-world product interoperates or not is outside the realm of voluntary standards. Similarly, a law against jaywalking does not enforce itself. It just defines the rules for pedestrian traffic and lists the acts which are illegal. But it is only through voluntary citizen goodwill and police enforcement that this is enforced. > At the same time, options are proper in at least three circumstances: > [i] when specifying alternative methods to achieve the same result; > [ii] when expressing tolerances; and [iii] when specifying a group of > related products. E.g., you MAY do either this or that but the result > MUST be X. The thread width MAY vary but MUST fall within the range of > Y +/- Z. You MAY implement only this subset but if you do you MUST NOT > claim conformance with the superset. > Generally, a standard should describe the results, not the methods used to achieve them. We call this the "performance approach". Certainly, with industrial standards, tolerances are commonly expressed. This is a dimension of variability. With markup standards, the recognized dimensions of variability are broader and include: 1. Classes of product 2. Profiles 3. Modules 4. Levels 5. Discretionary items 6. Deprecation 7. Extensibility The W3C has a nice Note on the subject, called "Variability in Specifications" you might enjoy: http://www.w3.org/TR/spec-variability/ > Further, are you asserting that a standard that includes even a > > single optional requirement or recommendation, e.g., a "should" or "should > > not" in ISO practice, or expresses an implementation option, e.g., "may" > > in ISO practice, is not a "real standard", or is an unlawful standard, or > > is a standard that may not be specified as a requirement for government > > procurement? > > No. "Should" and "should not" are only informational; they establish > no normative requirements. Who can object to more information? And as > mentioned above there are proper roles for options. > Strictly speaking, "normative" clauses in a standard define the provisions of the standard. And provisions of the standard include the mandatory as well as the optional requirements. So the "shall's" and the "should's" are both normative. When reviewing a standard we scrutinize both kinds of clauses, since both may be implemented. > But the only room for options in specifying product characteristics > turns on the substitutability of the products in the market. If one > conforming implementation of .ODT produces a document that can't be > fully processed by another conforming implementation, it's a broken > standard. > "Fully processed" and "substitutability" are a terms of your invention, not ISO or WTO terms, and certainly not ODF terms. What do you mean by this and on what basis do you claim this to be a requirement? If it is your personal opinion, expressing your personal preferences and desires, then fine, I'll accept it as such. Also, I'd argue that your assertion is tautological. Whenever two products conform to the same standard, then by definition they are interoperable over those provisions mandated by the standard, and they are substitutable in those markets and for those uses which can accommodate the remaining dimensions of variability allowed by the standard. Whether they meet your particular need is another question entirely. Are you baking a cake? Or doing dietetic testing of mice? Needs vary and in writing a standard we try to balance the needs of many interests. > Another way you might look at it is that standards are supposed to > define markets where all can compete on equal terms because they are > all producing the same product. The benefit to society is that with a > more stable product, manufacturers can invest more in lowering > production costs and thereby lowering the cost to consumers. > Certainly not. Although the goal is certainly laudable, within a standards committee, at least in the U.S., it is forbidden to discuss things like market impact, costs, prices, equalizing competition, etc. These are all anti-trust red flag items and we are all warned when joining a committee that these items are off-limits for discussion. But I think I agree with you on the goal. But, by analogy, if you want to reduce gun violence, you won't make much progress by drafting an ISO standard that gives the requirement "A conforming gun shall not shoot the good guys." The competitive problems in the market today are not caused by bad standards. Remember, we had problems in the market long before ODF and OOXML came around. The problems are caused by poorly-conforming products, consumer indifference, lax procurement policies, and by companies that benefit from the status quo. Playing around with conformance clauses gives you very little leverage to address the root problems. > I think this an important point: standards are supposed to be > agreements not to compete on the basis of product differentiation, but > rather on price, quality, and customer service. See e.g., Allied Tube > & Conduit v. Indian Head, Inc., 486 U.S. 492 (1988), > . ("Agreement on a product > standard is, after all, implicitly an agreement not to manufacture, > distribute, or purchase certain types of products.") > I disagree. What you describe -- competition on price, etc. -- is the definition of a commodity. Certainly some agricultural and industrial products trade that way. But this is not the rule. Take web browsers, for example. HTML, CSS2, EcmaScript, etc., are all standardized. Interoperability among browsers is improving, and compared to a few years ago, is rather good. But the browser vendors, both commercial and open source, still fiercely compete on the basis of product differentiation. In fact, the elimination of vendor lock-in previously caused by the use of proprietary dialects of HTML/CSS2 has opened it up for the smaller vendors to distinguish themselves even more based on features. Is this such a bad thing? I think the competition between Firefox and Internet Explorer has been a good thing. And we have Opera, Safari and Chrome now, each bringing their own feature set. Remember, we've seen what it is like for everyone in the world to have the same features in their word processor. It is called a monopoly, and we nearly had it with Word. I'd rather not return to that world. We need interoperability, certainly, but not at the expense of product differentiation. We need to keep the wheel of progress turning, and we do that by encouraging vendors to innovate. It is not an either/or question. We need both. -Rob From lars at umich.edu Tue Jan 6 11:16:56 2009 From: lars at umich.edu (=?UTF-8?B?TGFycyBOb29kw6lu?=) Date: Tue Jan 6 11:23:04 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> Message-ID: <496383F8.4080208@umich.edu> robert_weir@us.ibm.com wrote: > ... > A standard does not mandate interoperability. There is really no way it > can. A standard can only define conformance. Which is probably why MS boosters spend so much time trying to draw discussion away from conformance... > ... Whether a particular > real-world product interoperates or not is outside the realm of voluntary > standards. Similarly, a law against jaywalking does not enforce itself. > It just defines the rules for pedestrian traffic and lists the acts which > are illegal. But it is only through voluntary citizen goodwill and police > enforcement that this is enforced... In the context of standards, standard specifications and the standards process are oriented towards users and groups that intend to implement and use the standards. Neither are really set up to deal with organized crime, which appears to be the opposition here. Regards, -Lars From homembit at gmail.com Mon Jan 5 21:44:08 2009 From: homembit at gmail.com (Jomar Silva) Date: Tue Jan 6 17:07:59 2009 Subject: Res: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: Message-ID: <115550803-1231210189-cardhu_decombobulator_blackberry.rim.net-754564723-@bxe128.bisx.prod.on.blackberry> Hi Paul, Just to illustrate the discussion, please take a look at the traceroute flag (or attribute) at the TCP/IP protocol and the real world implementation (and usage) of the traceroute functionality. To be more specific, take a look at the IETF specifications and at the MTR source code and documentation (GPL 'mega' traceroute application) and please tell me each one is more useful (at the real world, the MTR source code saved my life after more than a month testing the real world usage of the traceroute flag/attribute without any solid results). You may understand (note the MAY word) the MTR docs and source code as an 'application specific implementation' docs. On a perfect world, 'must' and 'shall' are ok, but I'm so sorry, we live on a world of maybe and if a standard isn't 'may' enough, just few folks will use it (please check the latest CNN news and you will see how far we may go without a 'maybe' on our lives). Must or Shall isn't always the best solution. Best, Jomar -----Original Message----- From: robert_weir@us.ibm.com Date: Mon, 5 Jan 2009 19:59:08 To: ODF Discussion List Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 odf-discuss-bounces@opendocumentfellowship.com wrote on 01/05/2009 04:32:17 PM: >Standards are about uniformity, not about product differentiation. ODF >and OOXML are not true standards precisely because do not specify all >characteristics of an identifiable product or group of products only >in mandatory "must" or "must not" terms. Hi Paul, I think the above is at the core of your argument. So I understand your position perfectly, are you asserting that a standard is only permitted to include mandatory requirements, e.g., those expressed by "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF practice? Further, are you asserting that a standard that includes even a single optional requirement or recommendation, e.g., a "should" or "should not" in ISO practice, or expresses an implementation option, e.g., "may" in ISO practice, is not a "real standard", or is an unlawful standard, or is a standard that may not be specified as a requirement for government procurement? Regards, -Rob _______________________________________________ odf-discuss mailing list odf-discuss@opendocumentfellowship.com http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss From homembit at gmail.com Mon Jan 5 21:45:58 2009 From: homembit at gmail.com (Jomar Silva) Date: Tue Jan 6 17:07:59 2009 Subject: Res: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: Message-ID: <601242831-1231210196-cardhu_decombobulator_blackberry.rim.net-112896368-@bxe128.bisx.prod.on.blackberry> Hi Paul, Just to illustrate the discussion, please take a look at the traceroute flag (or attribute) at the TCP/IP protocol and the real world implementation (and usage) of the traceroute functionality. To be more specific, take a look at the IETF specifications and at the MTR source code and documentation (GPL 'mega' traceroute application) and please tell me each one is more useful (at the real world, the MTR source code saved my life after more than a month testing the real world usage of the traceroute flag/attribute without any solid results). You may understand (note the MAY word) the MTR docs and source code as an 'application specific implementation' docs. On a perfect world, 'must' and 'shall' are ok, but I'm so sorry, we live on a world of maybe and if a standard isn't 'may' enough, just few folks will use it (please check the latest CNN International news and you will see how far we may go without a 'maybe' on our lives). Must or Shall isn't always the best solution. Best, Jomar -----Original Message----- From: robert_weir@us.ibm.com Date: Mon, 5 Jan 2009 19:59:08 To: ODF Discussion List Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 odf-discuss-bounces@opendocumentfellowship.com wrote on 01/05/2009 04:32:17 PM: >Standards are about uniformity, not about product differentiation. ODF >and OOXML are not true standards precisely because do not specify all >characteristics of an identifiable product or group of products only >in mandatory "must" or "must not" terms. Hi Paul, I think the above is at the core of your argument. So I understand your position perfectly, are you asserting that a standard is only permitted to include mandatory requirements, e.g., those expressed by "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF practice? Further, are you asserting that a standard that includes even a single optional requirement or recommendation, e.g., a "should" or "should not" in ISO practice, or expresses an implementation option, e.g., "may" in ISO practice, is not a "real standard", or is an unlawful standard, or is a standard that may not be specified as a requirement for government procurement? Regards, -Rob _______________________________________________ odf-discuss mailing list odf-discuss@opendocumentfellowship.com http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss From worldlabel at gmail.com Fri Jan 9 16:09:19 2009 From: worldlabel at gmail.com (Russell Ossendryver) Date: Fri Jan 9 16:09:23 2009 Subject: [odf-discuss] AbiWord gets funding for ODF development Message-ID: AbiSource Corporation is to receive funding to improve the ODF compatibility of AbiWord, the free software word processor. AbiSource Corporation, a company created by some of the AbiWord developers a few months ago, was approached by the Dutch non-profit organisation NLnet which was interested in seeing AbiWord gain better compatibility with the OpenDocument format. This would in turn would boost AbiWord's compatibility with OpenOffice.org. Read the rest http://www.heise-online.co.uk/news/AbiWord-gets-funding-for-ODF-development--/112374 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20090109/658458fd/attachment.html From jeanweber at gmail.com Fri Jan 9 17:06:54 2009 From: jeanweber at gmail.com (Jean Hollis Weber) Date: Fri Jan 9 17:14:41 2009 Subject: [odf-discuss] AbiWord gets funding for ODF development In-Reply-To: References: Message-ID: <4967CA7E.6080409@gmail.com> Russell Ossendryver wrote: > AbiSource Corporation is to receive funding to improve the ODF > compatibility of AbiWord, the free software word processor [...] > > Read the rest > http://www.heise-online.co.uk/news/AbiWord-gets-funding-for-ODF-development--/112374 This is very good news, Russell! Thanks for passing it on. I hope to contribute some bug reports from testing .odt files (produced by OOo3) in AbiWord, but -- no surprise -- so far I haven't had time. --Jean From marbux at gmail.com Sat Jan 10 13:48:36 2009 From: marbux at gmail.com (marbux) Date: Sat Jan 10 13:48:39 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <496383F8.4080208@umich.edu> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <496383F8.4080208@umich.edu> Message-ID: <2c60d980901101048l33e71438o663a6da7e1ef921e@mail.gmail.com> On Tue, Jan 6, 2009 at 8:16 AM, Lars Nood?n wrote: > In the context of standards, standard specifications and the standards > process are oriented towards users and groups that intend to implement > and use the standards. Neither are really set up to deal with organized > crime, which appears to be the opposition here. I wish I could plant a smiley here, but it's too true. Best regards, Paul -- Universal Interoperability Council From marbux at gmail.com Sat Jan 10 15:07:54 2009 From: marbux at gmail.com (marbux) Date: Sat Jan 10 15:07:58 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <601242831-1231210196-cardhu_decombobulator_blackberry.rim.net-112896368-@bxe128.bisx.prod.on.blackberry> References: <601242831-1231210196-cardhu_decombobulator_blackberry.rim.net-112896368-@bxe128.bisx.prod.on.blackberry> Message-ID: <2c60d980901101207p590843fub5e6e68971437410@mail.gmail.com> On Mon, Jan 5, 2009 at 6:45 PM, Jomar Silva wrote: > Just to illustrate the discussion, please take a look at the traceroute flag (or attribute) at the TCP/IP protocol and the real world implementation (and usage) of the traceroute functionality. > > To be more specific, take a look at the IETF specifications and at the MTR source code and documentation (GPL 'mega' traceroute application) and please tell me each one is more useful (at the real world, the MTR source code saved my life after more than a month testing the real world usage of the traceroute flag/attribute without any solid results). You may understand (note the MAY word) the MTR docs and source code as an 'application specific implementation' docs. > > On a perfect world, 'must' and 'shall' are ok, but I'm so sorry, we live on a world of maybe and if a standard isn't 'may' enough, just few folks will use it (please check the latest CNN International news and you will see how far we may go without a 'maybe' on our lives). > > Must or Shall isn't always the best solution. I'm very sorry that I don't have the time to take the deep dive into what's wrong with yet another standard right now. I'm really best at over-committing myself. :-) I won't comment on your description of the situation you describe because of my lack of information and time to acquire it. But on "must" or "shall" not *always* being the best solution, I agree. But when faced with a situation where implementations of a document standard can't interoperate without sharing the same code base, the bounds of lawful variability in the standard have been vastly exceeded. Those who flout the law do so at their own risk. Best regards, Paul -- Universal Interoperability Council From marbux at gmail.com Mon Jan 12 06:28:31 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 12 06:28:37 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> Message-ID: <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> Resending in 3 parts over the next few minutes because Mailman has been choking on the length. On Tue, Jan 6, 2009 at 7:45 AM, wrote: > odf-discuss-bounces@opendocumentfellowship.com wrote on 01/06/2009 > 07:59:19 AM: >> Were it only so simple. No. But the product *characteristics* -- in >> the instant case, electronic document formats -- may only be specified >> in such terms. You have to distinguish between specification of >> product characteristics and other aspects of a standard. >> > Is this a definition or a requirement? In other words, I could argue that > product characteristics are by definition those provisions of a standard > which are mandatory. But that does not forbid a standard from allowing > additional dimensions of variability. Not sure I understand the question or the argument. Might you clarify? One way of reading what you said in regard to product characteristics would be analogous to Humpty Dumpty's "it means just what I choose it to mean ? neither more nor less." I.e., is the argument that an international standard could lawfully fall short of specifying a complete product, that only whimsy rules what characteristics must be specified? The Asbestos Appellate Body decision defines "product characteristics" in a manner inconsistent with treating the term as a synonym for "those provisions of a standard which are mandatory." Note the "any objectively definable ..." phrase below. ==== 67 ... The word "characteristic" has a number of synonyms that are helpful in understanding the ordinary meaning of that word, in this context. Thus, the "characteristics" of a product include, in our view, any objectively definable "features", "qualities", "attributes", or other "distinguishing mark" of a product. Such "characteristics" might relate, inter alia, to a product's composition, size, shape, colour, texture, hardness, tensile strength, flammability, conductivity, density, or viscosity. In the definition of a "technical regulation" in Annex 1.1, the TBT Agreement itself gives certain examples of "product characteristics" - "terminology, symbols, packaging, marking or labelling requirements". These examples indicate that "product characteristics" include, not only features and qualities intrinsic to the product itself, but also related "characteristics", such as the means of identification, the presentation and the appearance of a product. In addition, according to the definition in Annex 1.1 of the TBT Agreement, a "technical regulation" may set forth the "applicable administrative provisions" for products which have certain "characteristics". ... ==== Perhaps also relevant depending on what the argument is, from the same decision: ==== 70. A "technical regulation" must, of course, be applicable to an identifiable product, or group of products. Otherwise, enforcement of the regulation will, in practical terms, be impossible. ... ==== I.e., I don't see how anyone could knowledgeably argue in good faith that either ODF or OOXML specify the characteristics of an "identifiable product," keeping in mind that the product of interest is an electronic document. See e.g., the ODF v. 1.1 conformance section: "Documents that conform to the OpenDocument specification may contain elements and attributes not specified within the OpenDocument schema.... ... "There are no rules regarding the elements and attributes that actually have to be supported by conforming applications ..." With both ODF and OOXML, the decision as to what constitutes the product is largely left up to individual implementers, resulting in interoperability nightmares. So the ATBT prohibition against standards that create unnecessary obstacles to international trade comes into play. Are the oceans of interoperability breakpoints in those specs necessary? What is the justification for allowing the "product" in effect to be defined by the implementer with the largest market share rather than by the standard? >> E.g., a 1-pound bag of flour should weigh the >> same regardless of who produces the flour. > OK. But the standard might not specify the color of the bag. That might > be an allowed dimension of variability and vendors might differ in what > color bag they use. There might also be tolerance in how finely the flour > is ground, the protein content per gram, etc. Depending on ones use of > bag of flour, this may or may not be appropriate. If you are doing > dietetic testing in lab mice you might instead need stronger guarantees > and adopt a profile of the standard for "1 pound bag of flour with 1% > water content by weight and 4gm protein per ounce". There is nothing > wrong with that. The need, by some users, to have a finer set of > restrictions for a bag of flour does not make the base standard > illegitimate or not useful for those who are satisfied with the > variability inherent in it. Agreed, but here our analogy parts with the present state of the ODF and OOXML specs because neither identifies or defines any product at all. > If there are divergent requirements, rather > than creating one monster standard that has everything, you typically > factor it into a family of standards, or a standard with profiles, or a > standard with conformance classes, or a modular standard, etc. No problem if each of the above specifies a separate product that is responsive to market requirements. If they don't, then we need to get down to more specific cases. But with both ODF and OOXML, what we've got is monster specs that don't specify any product at all. They're both woefully under-specified. >> Different methods might be used to manufacture the product, but the >> end product must be the same, within the limits of tolerances that are >> responsive to market requirements and technical feasibility. --- Which >> is a rather complicated way of saying that either the wrenches made >> by one group of companies *must* be capable of interoperating with >> those bolts and nuts made by still other companies or something has >> gone awry in the standard setting process for nuts, bolts, and >> wrenches, or one of the above is non-conforming. :-) >> > > A standard does not mandate interoperability. There is really no way it > can. A standard can only define conformance. Agreed, but my point was different. To restate it another way: The variability allowed by the standard must be responsive to market requirements. If that conforming wrench won't interoperate with the corresponding conforming bolt head, then the variability allowed by the standard collides with the prohibition against standards that create unnecessary obstacles to international trade. I'll also note here that an international standard for electronic documents not only can but must mandate "the conformity requirements essential to achieve the interoperability," in the words of JTC 1 Directives. So it is clear that the standard must not only specify a product but also the application behavior necessary for its interoperable exchange. > Whether a particular > real-world product interoperates or not is outside the realm of voluntary > standards. I can go quite a way down that path but can't give the statement unqualified agreement. As one example, you and I have previously discussed my opinion that JTC 1 Directives Annex I requires not only that interoperability be demonstrable but also demonstrated if necessary to have high confidence that interoperability conformance requirements are adequate. I'll note here to save you the bother that you disagreed. As another example, antitrust law could have a lot to say about a voluntary standards organization and its participants that intentionally broke interoperability with a vendor's app to disadvantage that vendor in the market. See e.g., closely analogous case in the U.S.: Allied Tube & Conduit v. Indian Head, Inc. 486 U.S. 492 (1988), (steel conduit vendors stuffed the voluntary standard organization's ballot box to exclude PVC conduit manufacturer from the market); see also U.S. Federal Trade Commission and Department of Justice, Antitrust Guidelines for Collaborations among Competitors (April, 2000), pg. 2 n. 5, . ("These Guidelines take into account neither the possible effects of competitor collaborations in foreclosing or limiting competition by rivals not participating in a collaboration nor the possible anticompetitive effects of standard setting in the context of competitor collaborations. Nevertheless, these effects may be of concern to the Agencies and may prompt enforcement actions.") And I somewhat hazily recall statements that a voluntary standard organization can sue a vendor falsely claiming conformance with interop conformance requirements and using the voluntary standard organization's trademark if the use of the trademark is conditioned on conformance. But that's an issue I have not personally researched. There may be other exceptions that either don't come to mind or that I have not run across in my research. > Generally, a standard should describe the results, not the methods used to > achieve them. We call this the "performance approach". I can also ride a fair bit of the way with you on that point. The origin of that approach traces to economic theory embodied in competition law. The principle of origin is that vendors of standardized products should be encouraged to compete through more efficient means of production and marketing, thereby lowering costs to consumers. But the performance approach is not a blanket authorization to under-specify a standard. E.g., there is no performance approach exception to the ATBT prohibition against standards "prepared, adopted, or applied with a view to or with the effect of creating unnecessary obstacles to international trade." Likewise, there is no performance approach exception to the corresponding section of JTC 1 Directives, the requirement that IT international standards "clearly and unambiguously specify the conformity requirements essential to achieve the interoperability." And on the factual precedent end, RFC 2119 --- which was incorporated by reference in OASIS ODF 1.0 --- recognizes an exception from the performance approach for interoperability: "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." . A useful rule of thumb here might be that responsiveness to market requirements trumps the performance approach when they collide. See e.g., World Trade Organization Committee on Technical Barriers to Trade, Decisions and Recommendations Adopted by the Committee Since 1 January 1995 (23 May 2002), : "In order to serve the interests of the WTO membership in facilitating international trade and preventing unnecessary trade barriers, international standards need to be relevant and to effectively respond to regulatory and *market needs,* as well as scientific and technological developments in various countries. They should not distort the global market, have adverse effects on fair competition, or stifle innovation and technological development. ... "11. Accordingly, it is important that international standardizing bodies: "Take account of relevant regulatory or *market needs,* as feasible and appropriate, as well as scientific and technological developments in the elaboration of standards[.]" > Certainly, with > industrial standards, tolerances are commonly expressed. This is a > dimension of variability. With markup standards, the recognized > dimensions of variability are broader and include: > 1. Classes of product > 2. Profiles > 3. Modules > 4. Levels > 5. Discretionary items > 6. Deprecation > 7. Extensibility > The W3C has a nice Note on the subject, called "Variability in > Specifications" you might enjoy: http://www.w3.org/TR/spec-variability/ I would not choose the word "broader." It is in my opinion a difference in kind rather than magnitude. E.g., all of the above and more could undoubtedly be found in standards for physical products. I also approve of your use of "include." It's an incomplete list, particularly for apps that both read and write documents. (The W3C is more than somewhat biased toward browser developers and browsers have only very limited editing capability.) E.g., for implementations that write to ODF, preservation of conformant markup is a dimension of variability in critical need of definition in the spec. And the word "supported" in the conformance section needs to be defined in a manner that does not allow destruction of conforming markup except by user initiated action, etc. [continued in next post] From marbux at gmail.com Mon Jan 12 06:29:57 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 12 06:30:03 2009 Subject: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901120222kcf1291al35d1d39ad064d653@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901101018w52d9457bm12ea522292fd9f99@mail.gmail.com> <2c60d980901120222kcf1291al35d1d39ad064d653@mail.gmail.com> Message-ID: <2c60d980901120329h48184641v893e260850310ffd@mail.gmail.com> [continued from last post] > Strictly speaking, "normative" clauses in a standard define the provisions > of the standard. And provisions of the standard include the mandatory as > well as the optional requirements. So the "shall's" and the "should's" > are both normative. When reviewing a standard we scrutinize both kinds of > clauses, since both may be implemented. You might take up that issue with OASIS: "Normative Statement ? a statement made in the body of a specification that defines *prescriptive* requirements on a Conformance Target.... "4. Normative Statements "A specification broadly consist of descriptive text and Normative Statements. The Normative Statements define what a Conformance Target MUST do to adhere to that part of the specification, and the descriptive text provides background information, descriptions and examples. ..." . I put in a fair amount of time awhile back looking for an authoritative definition of "normative" in the technical standards context for the Interop Glossary. I didn't find one. I've also encountered a lot of folks who intend different meanings when they use the term. In my experience, folks are all over the map on this. So I've opted to stick with the dictionary definition until I hit something more authoritative in context that says otherwise. That's what OASIS did too, apparently. "Prescriptive" is the only sense for "normative" given by my trusty Webster's Unabridged that is in the ballpark. If you have an authoritative reference for your definition, I'd be happy to quote and cite it in the Glossary and change my own usage. >> But the only room for options in specifying product characteristics >> turns on the substitutability of the products in the market. If one >> conforming implementation of .ODT produces a document that can't be >> fully processed by another conforming implementation, it's a broken >> standard. >> > "Fully processed" and "substitutability" are a terms of your invention, > not ISO or WTO terms, and certainly not ODF terms. What do you mean by > this and on what basis do you claim this to be a requirement? If it is > your personal opinion, expressing your personal preferences and desires, > then fine, I'll accept it as such. I erred in using the phrase "fully processed" as a shorthand and apologize for that error. A more appropriate shorthand in context would be "equally processed." See definitions of "interoperability" and "application-level interoperability" as well as (for citations and reasoning) their footnotes at . As to my use of the term "substitutability of products in the market," I am frankly surprised that you question it. Would it help to remind that the products under discussion are electronic documents, not the programs that generate or otherwise process them? Otherwise, we're off into a discussion whether standards can lawfully bestow conformance on a pound of flour weighing four ounces when produced by one manufacturer and 16 when produced by another. The entire concept of standardized products goes up in smoke. I'll happily respond with more if you still question the concept. But given our "pound of flour" discussion already, I strongly suspect that for a moment you fell into thinking of the programs as the products under discussion rather than the electronic documents. > Also, I'd argue that your assertion is tautological. Whenever two > products conform to the same standard, then by definition they are > interoperable over those provisions mandated by the standard, and they are > substitutable in those markets and for those uses which can accommodate > the remaining dimensions of variability allowed by the standard. That statement conflicts mightily with any authoritative definition of interoperability I've come across. E.g., if the standard doesn't require conforming apps to preserve markup created by other conforming apps, and one conforming app trashes all markup created by other conforming apps, would you still call that state of document exchange interoperability and the electronic documents substitutable? You might try reconciling that view with the following: 1. The ATBT prohibition against technical standards being "prepared, adopted or applied with a view to *or with the effect of* creating unnecessary obstacles to international trade." 2. The Asbestos Appellate Panel's holding that a technical regulation must specify [i] *any objectively definable* "features", "qualities", "attributes", or other "distinguishing mark" [ii] of a product or group of products [iii] only in mandatory "must" and "must not" terms. 3. The JTC 1 Directives requirement that standards must clearly and unambiguously specify the conformity requirements essential to achieve the interoperability. 4. The JTC 1 Directives definition of "interoperability," "the ability of two or more IT systems to exchange information at one or more standardised interfaces and to make mutual use of the information that has been exchanged," with particular attention given to the "make mutual use ..." clause. 5. Bob Sutor's definition of interoperability, "Interoperability is the ability for two different and independent software applications to exchange information *without loss of data, semantics, or metadata."* . Is this what you meant by "interoperable" and "substitutable?" "One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that's useful to me and then save it and continue in KOffice without loosing lots of data. "Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal :)" KWord lead developer Thomas Zander, email to OASIS OpenDocument Adoption Technical Committee mailing list (September 27, 2007), Or did you mean interoperability like this? "Any comments on ODF as the default format? There was a 2004 discussion, but has anything changed after that? "No. We will not make it our default file format. Our internal model does not map 100% to ODT and visa versa (basically because ODT is nothing more than a dump of OpenOffice.org's internal format). Any data loss that happens because of saving and loading a file again will not be accepted by our users. ... "So you don't advise distributions to set it as default either? "No, I'd strongly advise against making ODT the default format in Abiword for distributions given the previously mentioned lack of 100% feature coverage." AbiWord developer Marc Mauer, as quoted in Rahul Sundaram, AbiWord Team Interview, Red Hat Magazine (8 May 2008), http://www.redhatmagazine.com/2008/05/08/abiword-team-interview/. Or like this? ==== Implementation / Raw Score / Raw Score Percentage / Weighted Percent OpenOffice.org 151 100% 100% StarOffice 149 99% 97% Sun Plug-in for Word 142 94% 96 Clever Age/MS Plug-in for Word 139 92% 94% Wordperfect 122 81% 86% Koffice 121 80% 79% Google Docs 117 77% 76% TextEdit 55 36% 47% Abiword 48 32% 55%... ... There are no implementations that offer 100% compatibility with OpenOffice.org. ==== Shah, Rajiv C. and Kesan, Jay P., Lost in Translation: Interoperability Issues for Open Standards - ODF and OOXML as Examples (September 2008), (fidelity comparisons of ODF implementations testing only a small set of word processing features). [continued in next post] From marbux at gmail.com Mon Jan 12 06:30:45 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 12 06:30:56 2009 Subject: [odf-discuss] Re: Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901120329h48184641v893e260850310ffd@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901101018w52d9457bm12ea522292fd9f99@mail.gmail.com> <2c60d980901120222kcf1291al35d1d39ad064d653@mail.gmail.com> <2c60d980901120329h48184641v893e260850310ffd@mail.gmail.com> Message-ID: <2c60d980901120330x26b5ca70oda0ed403a92fe21a@mail.gmail.com> [continued from last post] Or did you mean interoperability like this experience? I need to get the latest published draft of the ODF 1.2 draft standard into WordPerfect X4 SP 1. When I open it, I get an error message telling me the Zip file is corrupt. I opened the document in Lotus Symphony and wrote it to PDF, then attempted to import the PDF into WordPerfect. The PDF is blank after the first few pages, regardless of the PDF import options selected. Surprising, because the X4 PDF import is quite good; it even incorporates OCR for scanned documents and text in images. I try again, using Symphony to write the document to RTF. WordPerfect X4 can't open it. I try WordPerfect X3 but no joy. I try again, using Symphony to write to DOC. Neither version of WordPerfect can open it. Surprising again because WordPerfect's DOC filters have been outstanding since WordPerfect 9. I go through similar travails with the ODF 1.1 spec, using both the PDF and ODT versions. Bottom line: I can't get either document into WordPerfect X3 or X4. Or did you mean like this? "... Interoperability is the goal to deliver better goods, services and intelligent data. This gives businesses choice rather than one proprietary solution. ... "Small and medium sized businesses will benefit tremendously from open standards such as the OpenDocument Format (ODF) and Web-based applications. Information will be more easily shared among computing systems, such as desktop, laptop, portable devices, or the data center, *without* single choice propriety operating systems and *application roadblocks.*" Robert S. Sutor, Open for Business, Express Computer (24 December 2007), . (In which century, Bob?) > Whether > they meet your particular need is another question entirely. Are you > baking a cake? Or doing dietetic testing of mice? None of the above. My immediate need is to get some ODF documents into an app that has a grammar checker so I can generate some counts of passive voice clauses. Perhaps I need to buy a license for Microsoft Office 2007 so I can use Symphony to convert the documents to DOC and then open and resave them in Office? Then I could send them to WordPerfect. How much time and money do I have to spend to find out if that might work, Rob? Beyond those two documents, I need to stop being locked into incompatible word processors by their vendors. I'm a power user; I need to produce complex documents. That means that I need a full featured, fully specified, truly open real standard for editable word processing documents with competing and fully interoperable implementations. Which standard do you recommend to fulfill that need, Rob? Which implementations may I select from? > Needs vary and in > writing a standard we try to balance the needs of many interests. A bit odd that specifying conformity requirements essential to achieve the interoperability hasn't made it onto the ODF TC agenda since the TC was formed in 2002, Rob, even as a discussion item. Hasn't come up yet on the OIIC TC mailing list either. Makes it look like compliance with JTC 1 Directives -- and the ATBT prohibition against standards that create unnecessary obstacles to international trade -- never got entered into that balancing act you describe. Perhaps as co-chair of the ODF TC and member of the OIIC TC you might manage to get that put that on one of those TC's agenda before I die of old age? I haven't experienced open standard-based word processing interoperability since IBM embraced and extended Teletypesetter ("TTS") back in the electromechanical era, when I was punching paper tape for hot metal linecasting equipment in daily newspapers. The last time was 1973. I've been waiting ever since. >> Another way you might look at it is that standards are supposed to >> define markets where all can compete on equal terms because they are >> all producing the same product. The benefit to society is that with a >> more stable product, manufacturers can invest more in lowering >> production costs and thereby lowering the cost to consumers. >> > Certainly not. Although the goal is certainly laudable, within a standards > committee, at least in the U.S., it is forbidden to discuss things like > market impact, costs, prices, equalizing competition, etc. These are all > anti-trust red flag items and we are all warned when joining a committee > that these items are off-limits for discussion. What does any of that have to do with what I said? I don't have a clue. (I'll caveat here that I am not agreeing with what you said in regard to "market impact." You paint with far too broad a brush there. As only one example, how does one ensure that their standard fulfills market requirements and does not create unnecessary obstacles to international trade without discussing market impacts?) > But I think I agree with you on the goal. Hey, we've achieved partial consensus! Now I owe you at least a cup of coffee. :-) xx--snip--xx >The competitive problems in the market today are not caused > by bad standards. True. But in my opinion, bad standards are one major symptom of the illness and a gargantuan barrier to the cure. Remember, we had problems in the market long before ODF > and OOXML came around. The problems are caused by poorly-conforming > products, I think poorly-conforming products are largely irrelevant with ODF and OOXML because of their gross under-specification. One must specify the conformity requirements essential to achieve the interoperability before poor conformance could become a major factor in the tragedy of ODF non-interoperability. > consumer indifference, lax procurement policies, Those two items tend toward blaming the victims, particularly when we've got folks like Sutor running around telling the world that ODF is an "open standard" designed for interoperability that already has competing, interoperable implementations. I question whether ODF will ever get repaired so long as the vendors are out there lulling consumers and procurement officers into indifference with false information. Or is there some other explanation for the disinformation campaign? Query, has anyone ever told Sutor that ODF is badly broken? Are his false claims simply the result of ignorance? I can agree that governments are not carrying out their relevant standards responsibilities under the Agreement on Government Procurement in regard to office productivity software. On the other hand, how can they when there is no competent editable electronic document standard with implementations for them to specify in procurement? > companies that benefit from the status quo. Hey, consensus again! At the same time, I think it important to recognize that a nuclear strike on Redmond, Washington tomorrow would leave plenty of companies just as motivated to build their own monopoly. I.e., it's not enough to set Microsoft's Office Monopoly board ablaze; one need be concerned with what rises from the ashes. (And that just may be the most concise explanation for my my deep concerns with the deeply disappointing lack of progress in fixing the ODF spec.) In aid of brevity I've denied my urge to add items to your list of causes, other than noting that I don't see any sign that ODF will get fixed without government intervention. So inadequate involvement of competition regulators would be one of my nominated items to add to the list. > Playing around with > conformance clauses gives you very little leverage to address the root > problems. It's the only leverage voluntary standard body participants have within the standard body framework. But I could agree that reform seldom springs from within the organization being reformed. Far more often, it's external events that cause big changes. >> I think this an important point: standards are supposed to be >> agreements not to compete on the basis of product differentiation, but >> rather on price, quality, and customer service. See e.g., Allied Tube >> & Conduit v. Indian Head, Inc., 486 U.S. 492 (1988), >> . ("Agreement on a product >> standard is, after all, implicitly an agreement not to manufacture, >> distribute, or purchase certain types of products.") >> > I disagree. What you describe -- competition on price, etc. -- is the > definition of a commodity. Certainly some agricultural and industrial > products trade that way. But this is not the rule. Google Define doesn't produce any definition of commodity that's even in the ballpark, Rob. In any event, that's a term you introduced into the conversation, not me. And I'm scarcely alone in my view that competition on price, etc., is one of the recognized benefits of standards. I don't have time to dive for a court decision squarely on point at the moment, but it's a point that comes up fairly often. Under U.S. antitrust law, the issue of liability for standards activity and other competitor collaborative ventures largely turns on whether the relevant activity has procompetitive or anticompetive effects. Perhaps this quote from Andy Updegrove might be close enough for us to move on from this point? "Standards have significant procompetitive effects such as increasing price competition as standard products are more readily compared[.]" Andy Updegrove, The Essential Guide to Standards, Ch. 9 -- Government Issues and Policy, . > Take web browsers, > for example. HTML, CSS2, EcmaScript, etc., are all standardized. > Interoperability among browsers is improving, and compared to a few years > ago, is rather good. But the browser vendors, both commercial and open > source, still fiercely compete on the basis of product differentiation. In > fact, the elimination of vendor lock-in previously caused by the use of > proprietary dialects of HTML/CSS2 has opened it up for the smaller vendors > to distinguish themselves even more based on features. Can't agree that what browsers do is interoperability. Interoperability involves two-way conversations with equal mutual use of the data exchanged. Browsers compatibly render the same data provided by servers. They have a limited ability to send some data back, but it isn't the same data received. And they don't communicate with each other. They do compatibility, not interoperability. Although this is subjective, I also can't agree that the compatibility is "good." I don't think we achieve "good" before "quirks mode" is eliminated and non-conformant web content won't load. I realize there are two sides to that argument, but I'm decidedly on the side of "strict." To me, "quirks" is pretty much a synonym for "broken." That's not a good foundation to build a Connected World on. E.g., Microsoft got page breaks across subdocuments wrong in the Word 1.0 page layout engine. Now their code is too brittle to fix it. Moral of the story: the longer you put off fixing an increasingly complex system, the harder it becomes to fix. > Is this such a bad thing? I think the competition between Firefox and > Internet Explorer has been a good thing. And we have Opera, Safari and > Chrome now, each bringing their own feature set. I am not anti-innovation and I am not pushing for sameness in implementations. We've discussed this before, but nothing in the law stops IBM from offering customers the choice among writing to RealStandardDocument, RealStandardDocumentPlusVendorExtensions, and any other formats IBM wishes to support, even SuperSecret-IBM-Binary until IBM attains monopoly status for Lotus Symphony because of that secret format, etc. The only issue is whether the RealStandardDocument standard confers conformant status on RealStandardDocumentPlusVendorExtensions. If it does, that violates the Agreement on Technical Barriers to Trade because the extensions are product characteristics not specified in the RealStandardDocument standard and unnecessary obstacles to international trade are created by the standard in the form of interop breakpoints created by the vendor extensions. > Remember, we've seen what it is like for everyone in the world to have the > same features in their word processor. It is called a monopoly, and we > nearly had it with Word. I'd rather not return to that world. How is a trio of big vendors collaborating on the same source code code a significant improvement, particularly when a single company holds the only key for the lock on that code base? A cartel arises from the ashes of the monopoly, falsely claiming that its document formats are open when in truth the conformity requirements essential to achieve interoperability are concealed from would-be competitors? Microsoft achieved its office monopoly in no small part using trade secret, binary, moving interoperability target document formats. Now we have plain text ODF XML, but the ODF cartel keeps the specification dark and mysterious by keeping from the specification the conformity requirements essential to achieve interoperability. Out here in User Land, we're still locked in by incompatible apps. What's there to celebrate? That it's not Microsoft locking us in? That we have this theoretical freedom to clone OOo ourselves? > We need > interoperability, certainly, but not at the expense of product > differentiation. We need to keep the wheel of progress turning, and we do > that by encouraging vendors to innovate. It is not an either/or question. I agree it is not an either/or question. So why do we not have either interoperability or a standard that specifies the conformity requirements essential to achieve the interoperability? And why is no one working on that? > We need both. It's only a question of priorities, Rob. The law does not say we must have new features. The law does say that standards must meet minimum requirements, including complete specification of a product and no unnecessary obstacles to international trade. JTC 1's lawyers quite correctly translated those duties into the IT context by requiring that its international standards specify the conformity requirements essential to achieve the interoperability. So bottom line, Rob, the law says interop comes ahead of new features in standards work, that those interop conformity requirements must be in the specification before the standard is adopted. The feature wars are supposed to happen outside the standards context. I've been waiting for open standards-based word processor interop to reappear since 1973. But all I've seen is a continuing feature war, with ODF and OOXML both granting conformant status to documents that include vendor extensions. I am not angry at you. I am confident that you are not calling the shots on this. You're still one of the good guys in my book. But there is a complete failure of IBM to hold itself to the same standard it successfully held Microsoft to in the Commission v. Microsoft litigation and that IBM is now asserting against Microsoft before DG Competition in regard to Microsoft Office and OOXML: Commission v. Microsoft, European Community Court of First Instance (Grand Chamber Judgment of 17 September, 2007), para. 226, 230, 421, (rejecting Microsoft's argument that "interoperability" has a 1-way rather than 2-way meaning; information technology specifications must be disclosed with sufficient specificity to place competitors on an "equal footing" in regard to quality of interoperability; "the 12th recital to Directive 91/250 defines interoperability as 'the ability to exchange information and mutually to use the information which has been exchanged'"). The JTC 1 Directives definition of "interoperability" differs only in level of detail, "the ability of two or more IT systems to exchange information at one or more standardised interfaces and to make mutual use of the information that has been exchanged." JTC 1 Directives also require that international standard are to "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." So when do we get that ODF interop Sutor talked about, Rob? I'm already well past the average life expectancy for someone who's had one heart attack and I've had three, two of them major, so I'm not exactly patient when I read excuses for not getting started or irresponsible claims that ODF already delivers interop. I want to live long enough to see IBM take that first step on the ODF interop walk. Maybe at SC 34? Best regards, Paul From robert_weir at us.ibm.com Mon Jan 12 09:18:22 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Mon Jan 12 09:17:11 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> Message-ID: odf-discuss-bounces@opendocumentfellowship.com wrote on 01/12/2009 06:28:31 AM: > > Please respond to ODF Discussion List > > Resending in 3 parts over the next few minutes because Mailman has > been choking on the length. > Probably a good sign that the discussion is not appropriate for a list. Might make an interesting essay, though, to post on the web or whatever, if you can tighten up the argument and consider multiple perspectives. -Rob From marbux at gmail.com Mon Jan 12 09:58:00 2009 From: marbux at gmail.com (marbux) Date: Mon Jan 12 09:58:06 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> Message-ID: <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> On Mon, Jan 12, 2009 at 6:18 AM, wrote: > odf-discuss-bounces@opendocumentfellowship.com wrote on 01/12/2009 > 06:28:31 AM: >> >> Please respond to ODF Discussion List >> >> Resending in 3 parts over the next few minutes because Mailman has >> been choking on the length. >> > > Probably a good sign that the discussion is not appropriate for a list. > Might make an interesting essay, though, to post on the web or whatever, > if you can tighten up the argument and consider multiple perspectives. I've been leaving the other perspectives up to you. :-) It's mostly from a pile of research I've been putting together for a series of articles. But I'm not sure the second two parts have made their way through yet. They're still not showing in the archives. OTOH, I've noticed before that Mailman is much quicker about serving mail than it is about archiving posts and that the amount of time before posts appear in the archives seems highly variable. If the other two parts don't make it into the archives by tonight, I'll resend unless someone fires a flare to let me know that they received them. Best regards, Paul -- Universal Interoperability Council From jeanweber at gmail.com Mon Jan 12 15:21:16 2009 From: jeanweber at gmail.com (Jean Hollis Weber) Date: Mon Jan 12 15:21:26 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> Message-ID: <496BA63C.5060908@gmail.com> marbux wrote: > But I'm not sure the second two parts have made their way > through yet. They're still not showing in the archives. OTOH, I've > noticed before that Mailman is much quicker about serving mail than it > is about archiving posts and that the amount of time before posts > appear in the archives seems highly variable. > > If the other two parts don't make it into the archives by tonight, > I'll resend unless someone fires a flare to let me know that they > received them. All 3 parts arrived here within a few minutes of each other (last night, my time), and you've probably found that all are now in the archives. --Jean From marbux at gmail.com Tue Jan 13 03:34:45 2009 From: marbux at gmail.com (marbux) Date: Tue Jan 13 03:34:48 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <496BA63C.5060908@gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> <496BA63C.5060908@gmail.com> Message-ID: <2c60d980901130034p2e1e029ai84d1f6a99fe51700@mail.gmail.com> On Mon, Jan 12, 2009 at 12:21 PM, Jean Hollis Weber wrote: > All 3 parts arrived here within a few minutes of each other (last night, my > time), and you've probably found that all are now in the archives. Thanks, Jean. Since you received them I won't resend. But the last two parts are still not showing in the archives. . I suspect they'll show up one of these days. :-) Like I said, the time it takes for posts to show up in the archives is really erratic. Best regards, Paul -- Universal Interoperability Council From jeanweber at gmail.com Tue Jan 13 03:38:38 2009 From: jeanweber at gmail.com (Jean Hollis Weber) Date: Tue Jan 13 03:45:41 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <2c60d980901130034p2e1e029ai84d1f6a99fe51700@mail.gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> <496BA63C.5060908@gmail.com> <2c60d980901130034p2e1e029ai84d1f6a99fe51700@mail.gmail.com> Message-ID: <496C530E.5030606@gmail.com> marbux wrote: > On Mon, Jan 12, 2009 at 12:21 PM, Jean Hollis Weber wrote: > >> All 3 parts arrived here within a few minutes of each other (last night, my >> time), and you've probably found that all are now in the archives. > > Thanks, Jean. Since you received them I won't resend. But the last two > parts are still not showing in the archives. > . > I suspect they'll show up one of these days. :-) Like I said, the time > it takes for posts to show up in the archives is really erratic. Yes, they are there in the archives, just not properly threaded with the earlier discussion. http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2009-January/007834.html http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2009-January/007835.html --Jean From marbux at gmail.com Tue Jan 13 04:05:39 2009 From: marbux at gmail.com (marbux) Date: Tue Jan 13 04:05:42 2009 Subject: Fw: [odf-discuss] Microsoft's implementation of ODF 1.1 In-Reply-To: <496C530E.5030606@gmail.com> References: <2c60d980901060459q239f15eeu5e0a8bbb180c6d6a@mail.gmail.com> <2c60d980901120328nc04cb5bt89539faecc799a9c@mail.gmail.com> <2c60d980901120658n189b4551vfba8ce9ad4b72df9@mail.gmail.com> <496BA63C.5060908@gmail.com> <2c60d980901130034p2e1e029ai84d1f6a99fe51700@mail.gmail.com> <496C530E.5030606@gmail.com> Message-ID: <2c60d980901130105h7c8960a0h889aad70ffa0ce59@mail.gmail.com> On Tue, Jan 13, 2009 at 12:38 AM, Jean Hollis Weber wrote: > marbux wrote: >> >> On Mon, Jan 12, 2009 at 12:21 PM, Jean Hollis Weber >> wrote: >> >>> All 3 parts arrived here within a few minutes of each other (last night, >>> my >>> time), and you've probably found that all are now in the archives. >> >> Thanks, Jean. Since you received them I won't resend. But the last two >> parts are still not showing in the archives. >> >> . >> I suspect they'll show up one of these days. :-) Like I said, the time >> it takes for posts to show up in the archives is really erratic. > > Yes, they are there in the archives, just not properly threaded with the > earlier discussion. > http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2009-January/007834.html > http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2009-January/007835.html Ah, I must have mistitled them. Thanks. Best regards, Paul -- Universal Interoperability Council From marbux at gmail.com Tue Jan 13 09:51:50 2009 From: marbux at gmail.com (marbux) Date: Tue Jan 13 09:51:53 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions Message-ID: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> . E.g., "I think there is good scope for useful convergence of the various standards. The key would be to piggybacking it on some mutually attractive feature, such as better support for multi-document packages and websites. I have mentioned this aspect before, when talking about whether a file can be ODF and OOXML and a website at the same time. Can it be ODF and XPS and MARS at the same time? "My expectation for convergence would be that there would be a level of convergence where everyone agrees on ZIP (deflate), self-identification of document type, multuple document support, /mimetype, W3C DSIG, Dublin Core metadata and IS29500 OPC's URL scheme for identifying parts, but then an advanced layer with more platform-dependent features on things like references, relationships, RDF and rights where one vendor's meat may be another's poison--encryption & DRM may certainly be contentious. (The OEBPS ssytem already has such a split model, with the OPF layer sitting on top of OCF to provide references, if my brief reading is correct.) The goal should including making sure the same archive can support a plurality of these different platforms without one locking out the other. (Which brings up consistency-guarantee issues, of course.)" Best regards, Paul -- Universal Interoperability Council From robert_weir at us.ibm.com Tue Jan 13 10:10:09 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Tue Jan 13 10:09:02 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> Message-ID: Not sure what the benefit of this would be. From an implementation perspective, writing code to support different ZIP+XML packaging formats is trivial. It amounts to maybe 0.1% of the effort of supporting ODF or OOXML for an editor. But if the XML inside the Zip is not harmonized, then the other 99.9% of the differences is what will cause you grief. It is like saying, I'll write a book in English and you'll write a book in Japanese, but we'll agree that the table of contents goes in front, right after the title page, and that amounts to the sum total of our "interoperability": Might have some use if your application only looks at the table of contents and nothing more. But for typical uses of office documents, e.g,, editing, viewing, etc., it is not a very compelling use-case and hardly seems worth the effort. IMHO, harmonization needs to serve the goal of document interoperability and not merely be the target of an intellectual tidiness fetish. -Rob odf-discuss-bounces@opendocumentfellowship.com wrote on 01/13/2009 09:51:50 AM: > > odf-discuss-bounces@opendocumentfellowship.com > > Please respond to ODF Discussion List > > < http://broadcast.oreilly.com/2009/01/packaging-formats-of-famous-ap.html>. > > E.g., > > "I think there is good scope for useful convergence of the various > standards. The key would be to piggybacking it on some mutually > attractive feature, such as better support for multi-document packages > and websites. I have mentioned this aspect before, when talking about > whether a file can be ODF and OOXML and a website at the same time. > Can it be ODF and XPS and MARS at the same time? > > "My expectation for convergence would be that there would be a level > of convergence where everyone agrees on ZIP (deflate), > self-identification of document type, multuple document support, > /mimetype, W3C DSIG, Dublin Core metadata and IS29500 OPC's URL scheme > for identifying parts, but then an advanced layer with more > platform-dependent features on things like references, relationships, > RDF and rights where one vendor's meat may be another's > poison--encryption & DRM may certainly be contentious. (The OEBPS > ssytem already has such a split model, with the OPF layer sitting on > top of OCF to provide references, if my brief reading is correct.) The > goal should including making sure the same archive can support a > plurality of these different platforms without one locking out the > other. (Which brings up consistency-guarantee issues, of course.)" > > Best regards, > > Paul > > -- > Universal Interoperability Council > > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > From marbux at gmail.com Wed Jan 14 02:36:57 2009 From: marbux at gmail.com (marbux) Date: Wed Jan 14 02:37:00 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> Message-ID: <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> On Tue, Jan 13, 2009 at 7:10 AM, wrote: > Not sure what the benefit of this would be. From an implementation > perspective, writing code to support different ZIP+XML packaging formats > is trivial. It amounts to maybe 0.1% of the effort of supporting ODF or > OOXML for an editor. But if the XML inside the Zip is not harmonized, > then the other 99.9% of the differences is what will cause you grief. > > It is like saying, I'll write a book in English and you'll write a book in > Japanese, but we'll agree that the table of contents goes in front, right > after the title page, and that amounts to the sum total of our > "interoperability": Might have some use if your application only looks at > the table of contents and nothing more. But for typical uses of office > documents, e.g,, editing, viewing, etc., it is not a very compelling > use-case and hardly seems worth the effort. > > IMHO, harmonization needs to serve the goal of document interoperability > and not merely be the target of an intellectual tidiness fetish. I'm sorry I didn't notice that Jelliffe had missed linking his previous article from part of the first paragraph I quoted: "I have mentioned this aspect before, when talking about whether a file can be ODF and OOXML and a website at the same time. Can it be ODF and XPS and MARS at the same time?" His latest piece would have been more understandable had he linked that prior discussion. . (Note the partial buy-in by Bruce d'Arcus and Patrick Durusau in the comments.) I'm not a huge fan of the idea of packaging both an ODF and OOXML version of the same document in a Zip, at least in the present state of both specs. There's too much incompatible variation. Still I suspect Jelliffe's concept could with some elaboration be a useful step along the path to harmonization and then convergence. But the concept of packaging together the editable and archival version of a document, e.g., ODF plus PDF packaged together is something Gary Edwards and I have been advocating for at least a couple of years. "Pixel-perfect" archival plus editable in the same package fulfills a lot of needs presently unfulfilled; e.g., the needs of both those who want to see precisely what the person at the other end of the conversation is seeing as well as the needs of those who wish to edit the document. Likewise, packaging archival with the editable removes a lot of headaches from recycling of archived content, not to mention the management of archival operations. Likewise, adding a minimalist XHTML version of the same document to that package dramatically extends the variety of apps that can process the document, assuming there is a more universal packaging convention implemented by the receiving apps. Likewise, a full-blown word processor could package two versions of the document, one in a supersetting profile and one in a subsetting profile, e.g., .ODT and .ODT Tiny. Jelliffe has been over several articles exploring the concept of "adaptability standards" and "etiquettes" in the XML standards context. See e.g., for a more detailed explanation of the terms, Ken Krechmer's "Standards Mark the Course of Economic Progress," International Center for Standards Research, University of Colorado at Boulder (undated), . One example of an etiquette is the "handshaking" step of modem < > modem communications, where the two IT systems involved negotiate which communications protocol they will use for the exchange of data. With data storage, system memory, and communications bandwidth no longer so limiting, there are good grounds to expect that adaptability standards and etiquettes will evolve for different electronic document standards. E.g., one might view XSL as a group of standards with significant adaptability aspects. With packaged XML standards, combining different markup language versions of the same documents presents us with a Zips within a Zip problem. Is the variability of the packaging convention within each nested Zip really necessary, given the unpredictability as to implementations of which standards will be packaged together? In that context, standardizing the packaging convention makes a lot of sense to me. E.g., why should browser developers be required to implement a bunch of different unpackaging methods? It's a dimension of variability among different standards that could be standardized considerably, with variability only where there is a compelling market requirement to be fulfilled by variation. Jelliffe's article identifies some low hanging fruit for reducing the future variability, emerging areas of consensus in XML document packaging. He also identifies a few remaining areas of disagreement, where there may or may not be a compelling need for variation. I think there are fair grounds for debating whether packaging a plurality of formats together is a desirable path to walk. But Jelliffe is exploring more than an intellectual tidiness fetish. -- Universal Interoperability Council From mfioretti at nexaima.net Wed Jan 14 04:18:05 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Wed Jan 14 04:50:13 2009 Subject: [odf-discuss] Wanted: material on the Message-ID: <39891.213.203.159.55.1231924685.squirrel@nexaima.net> Hello, everybody! I am preparing an updated, extended edition of my seminar "How file formats can be used to favor (or hamper) innovation: concrete impacts on free markets, business competition, culture, equal opportunities, education..." You can download, read and reuse the 2005 edition from http://www.opendocumentfellowship.com/MarcoFioretti Right now, I welcome, either here or privately, anything you think should be mentioned in a seminar with such a title, especially (but not necessarily!!!) if it happened after dec. 2005. I'd like to give complete coverage of the matter, so while I'll leave plenty of space to ODF/OoXML, I am really interested in examples from other fields of digital technology. Once I've finished, of course, I'll put this edition too on my ODF web page! TIA, Marco Fioretti http://mfioretti.net -- Help *everybody* love Free Standards and Software: http://digifreedom.net From marbux at gmail.com Wed Jan 14 08:49:18 2009 From: marbux at gmail.com (marbux) Date: Wed Jan 14 08:49:21 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> Message-ID: <2c60d980901140549q59e7aae1y615b0aab9f0ccc1e@mail.gmail.com> Another use case for standardizing the container just popped up on Google News Alerts, . "I'd like to see MHTML, or something similar, become a true industry standard so we can move away from the loose files downloads which are very inconvenient for archival purposes. Additionally, many CSS stylesheets now disrupt nice printing of pages which limits the ability of PDF printing for archival purposes.. "An alternative to MHTML would be ZIP containers similar to ODF, OOXML, and XPS. Moving to standardized, containerized files will provide the same benefit of MIME HTML, allowing entire webpages and associated resources to be treated as a single file for better usability." Best regards, Paul -- Universal Interoperability Council From robert_weir at us.ibm.com Thu Jan 15 10:40:17 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Thu Jan 15 10:39:40 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> Message-ID: My point is that these packaging conventions are standardized (albeit in two different versions) and the difference between their implementations amounts to around 20 lines of code for a developer (assuming their runtime libraries already support Zip, as Java, Python, etc., already do). There is only many years I'm going to sit in a standards committee to save a developer 20 lines of code. Maybe we get there some day and bundle it it with other work. But right now it sounds like Rick is debating what color wallpaper to use before the foundation of the house is even poured. You can do all the things you mentioned, packing ODF and OOXML, or ODF and PDF, or even HTML/CSS/PNG using the packaging formats as defined today. In fact, doesn't OpenOffice have some support for the ODF/PDF combination already? Harmonizing the packing format is the least of my concerns, purely from the cost/benefit standpoint. The benefit is negligible (20 lines of code) and the cost, like any formal standards work, is significant. Of course, if someone else has the energy and time to do further work in this area, then I wish them all the luck. It isn't critical, but then again it wouldn't be the most useless effort in ISO. -Rob odf-discuss-bounces@opendocumentfellowship.com wrote on 01/14/2009 02:36:57 AM: . . . > > In that context, standardizing the packaging convention makes a lot of > sense to me. E.g., why should browser developers be required to > implement a bunch of different unpackaging methods? It's a dimension > of variability among different standards that could be standardized > considerably, with variability only where there is a compelling market > requirement to be fulfilled by variation. > > Jelliffe's article identifies some low hanging fruit for reducing the > future variability, emerging areas of consensus in XML document > packaging. He also identifies a few remaining areas of disagreement, > where there may or may not be a compelling need for variation. > > I think there are fair grounds for debating whether packaging a > plurality of formats together is a desirable path to walk. But > Jelliffe is exploring more than an intellectual tidiness fetish. > From marbux at gmail.com Thu Jan 15 11:08:25 2009 From: marbux at gmail.com (marbux) Date: Thu Jan 15 11:08:28 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> Message-ID: <2c60d980901150808r5fde6bafhf4ebc759e509d3b7@mail.gmail.com> On Thu, Jan 15, 2009 at 7:40 AM, wrote: > You can do all the things you mentioned, packing ODF and OOXML, or ODF and > PDF, or even HTML/CSS/PNG using the packaging formats as defined today. In > fact, doesn't OpenOffice have some support for the ODF/PDF combination > already? I'll have to check. 'Twould be nice. It isn't > critical, but then again it wouldn't be the most useless effort in ISO. :-) Best regards, Paul -- Universal Interoperability Council From jeanweber at gmail.com Thu Jan 15 16:28:49 2009 From: jeanweber at gmail.com (Jean Hollis Weber) Date: Thu Jan 15 16:28:59 2009 Subject: [odf-discuss] Re: ODF/PDF combination files (Was: Recommended reading: Rick Jelliffe on converging....) In-Reply-To: References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <2c60d980901132336l76723553o3a19eba444124adb@mail.gmail.com> Message-ID: <496FAA91.6020700@gmail.com> Robert Weir wrote: > ... doesn't OpenOffice have some support for the ODF/PDF combination > already? Yes, the free Sun PDF Import Extension (Beta) provides for a "hybrid" file. http://extensions.services.openoffice.org/project/pdfimport --Jean From lars at umich.edu Fri Jan 16 02:51:34 2009 From: lars at umich.edu (=?UTF-8?B?TGFycyBOb29kw6lu?=) Date: Fri Jan 16 02:51:40 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> Message-ID: <49703C86.3010305@umich.edu> robert_weir@us.ibm.com wrote: >... it is not a very compelling use-case and hardly seems worth the effort. It's not. He appears to be trying to draw the discussion away from standards compliance and conformance guidelines. > IMHO, harmonization needs to serve the goal of document interoperability > and not merely be the target of an intellectual tidiness fetish. Please don't make the mistake that any of Rick's writings on the topic are intended to do anything more than stir up pointless debates and waste time and resources. Either an application conforms to ODF or it does not. As we saw in an earlier link, MSO 2007 SP2 not only does not, it also destroys ODF documents created by other applications. Regards -Lars From mike.carden at gmail.com Fri Jan 16 03:12:29 2009 From: mike.carden at gmail.com (Mike Carden) Date: Fri Jan 16 03:18:24 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <49703C86.3010305@umich.edu> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <49703C86.3010305@umich.edu> Message-ID: <24dc89620901160012i795347aco390173deff0d9428@mail.gmail.com> I have never understood why anyone would ever engage Rick Jelliffe or Paul Merrell in a dialogue. -- MC From marbux at gmail.com Fri Jan 16 11:19:37 2009 From: marbux at gmail.com (marbux) Date: Fri Jan 16 11:19:41 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <49703C86.3010305@umich.edu> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <49703C86.3010305@umich.edu> Message-ID: <2c60d980901160819r5ddde90ehb361e3bd48128089@mail.gmail.com> On Thu, Jan 15, 2009 at 11:51 PM, Lars Nood?n wrote: > robert_weir@us.ibm.com wrote: >>... it is not a very compelling use-case and hardly seems worth the effort. > > It's not. He appears to be trying to draw the discussion away from > standards compliance and conformance guidelines. I'm assuming that "he" was intended to refer to Jelliffe because I'd be really surprised to hear someone here thought I was trying to draw the discussion away from standards compliance and conformance guidelines, particularly in this conversation. But if you did mean to refer to me, I'd appreciate you making that explicit. >> IMHO, harmonization needs to serve the goal of document interoperability >> and not merely be the target of an intellectual tidiness fetish. > > Please don't make the mistake that any of Rick's writings on the topic > are intended to do anything more than stir up pointless debates and > waste time and resources. Can't say I agree with that. Jelliffe wrote much that I strongly disagree with, particularly in regard to the desirability of competing international standards. But that's far from saying I disbelieved everything he says. Jelliffe in my opinion can provide fairly solid information when he sticks to subjects he knows. He does less well when he steps into topics he doesn't know, such as the law governing international standards. E.g., he commented awhile back on a TIm Bray article: "In which jurisdictions do JTC1 (Information Technology) International Standards automatically have 'the force of law'? As far as I am aware there is not one country where this is so, in the sense of forcing citizens to adopt technologies. It is a basic feature of ISO participation that ISO does not have any sovereignty, nor does a country give up any sovereignty by participation at ISO. "To talk of 'force of law' rather than, say, 'theoretical preferential consideration for national standards or government procurement wishlists' is surely ratcheting things up a little?" Obviously he's working beyond his knowledge here because international standards have the force of law in every nation that is a Member of the Agreement on Technical Barriers to Trade, which is just yet another reason why the supposed desirability of competing international standards either appeals to or flows from ignorance. And in Jelliffe's case I strongly suspect the latter. How does one comply with two conflicting laws? > Either an application conforms to ODF or it does not. As we saw in an > earlier link, MSO 2007 SP2 not only does not, it also destroys ODF > documents created by other applications. I've seen nothing so far indicating that Microsoft's support for ODF will be non-conforming. One of the major weaknesses of the ODF conformance section is that it allows apps to trash other conforming apps' documents whilst still claiming conformance. Preservation of conformant metadata is a subject not discussed in the conformance section other than a short bit on preservation of foreign elements and attributes. The conformance section expressly states: "Conforming applications either *shall* read documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place, or *shall* write documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place. ... "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." The ODF conformance section doesn't say a thing about *preserving* valid elements and attributes that are defined by the spec and hasn't since JTC 1 flipped the requirements keyword definitions from RFC 2119 to ISO/IEC JTC 1 Directives Part 2. Implementations are free to trash conforming elements and attributes whilst their developers remain entitled to claim conformance. Microsoft is apparently not the only company taking advantage of that fact. E.g., Thomas Zander's statement: "One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that's useful to me and then save it and continue in KOffice without loosing lots of data. "Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal :)" Thomas Zander, email to OASIS OpenDocument Adoption Technical Committee mailing list (September 27, 2007), . (Zander is lead developer for the KDE KOffice KWord word processor and a member of the OASIS OpenDocument Technical Committee.) I think it's a bummer and a shame that ODF allows this kind of thing. But bottom line: trashing conformant elements and attributes is not a violation of ODF conformance requirements. It's a dimension of allowed variability that needs some severe tightening in the specification. Best regards, Paul -- Universal Interoperability Council From marbux at gmail.com Fri Jan 16 12:50:18 2009 From: marbux at gmail.com (marbux) Date: Fri Jan 16 12:55:44 2009 Subject: [odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions In-Reply-To: <24dc89620901160012i795347aco390173deff0d9428@mail.gmail.com> References: <2c60d980901130651s20c70a6y7cc7eb102dec3fbe@mail.gmail.com> <49703C86.3010305@umich.edu> <24dc89620901160012i795347aco390173deff0d9428@mail.gmail.com> Message-ID: <2c60d980901160950x4677ee5bpd273e78c88e86135@mail.gmail.com> On Fri, Jan 16, 2009 at 12:12 AM, Mike Carden wrote: > I have never understood why anyone would ever engage Rick Jelliffe or > Paul Merrell in a dialogue. Pure ad hominem, Mike, that completely ducks the merits of anything I've said in my entire lifetime. Nothing there but ad hominem. I'm ignorant as to your aversity to having a dialogue with me. But I note your previous statement that you have a personal beef with Jelliffe. : "We started with an intro by Rick Jelliffe [http://www.oreillynet.com/pub/au/1712] who, for unrelated reasons, I happen to have a personal issue with." If you have a personal issue with me too, I've never heard of it so I can't respond. Best regards, Paul -- Universal Interoperability Council From cputtick at gmail.com Fri Jan 23 02:28:29 2009 From: cputtick at gmail.com (Chris Puttick) Date: Fri Jan 23 02:34:58 2009 Subject: [odf-discuss] RIM support for ODF? Message-ID: <388f7e1a0901222328o5f59c256j307faad78ab3ba30@mail.gmail.com> RIM supports Lotus Symphony ergo RIM supports ODF? http://www.eweek.com/c/a/Mobile-and-Wireless/RIM-Now-Supports-IBM-Lotus-Quickr-Lotus-Symphony-on-Smart-Phones/?kc=EWKNLWMU01222009STR1 Regards Chris -- My employers website: http://thehumanjourney.net - opinions in this email are however very much my own and may not reflect that of my current employer, past employers, associates, friends, family, pets etc.. Documents attached to this email may be in ISO 26300 format: http://iso26300.info From yoonkit at gmail.com Fri Jan 23 02:46:42 2009 From: yoonkit at gmail.com (Yoon Kit Yong) Date: Fri Jan 23 03:50:07 2009 Subject: [odf-discuss] RIM support for ODF? In-Reply-To: <388f7e1a0901222328o5f59c256j307faad78ab3ba30@mail.gmail.com> References: <388f7e1a0901222328o5f59c256j307faad78ab3ba30@mail.gmail.com> Message-ID: >From the Article: "RIM's BlackBerry smartphone users can now access IBM's Lotus Symphony word > processing documents, with the eventual capability to use presentations and > spreadsheets from Symphony, built on the Open Document Format, as an > alternative to Microsoft Office. Lotus Symphony document viewing will be > available in the second quarter of this year. " > yk. 2009/1/23 Chris Puttick > RIM supports Lotus Symphony ergo RIM supports ODF? > > > http://www.eweek.com/c/a/Mobile-and-Wireless/RIM-Now-Supports-IBM-Lotus-Quickr-Lotus-Symphony-on-Smart-Phones/?kc=EWKNLWMU01222009STR1 > > Regards > > Chris > > -- > My employers website: http://thehumanjourney.net - opinions in this > email are however very much my own and may not reflect that of my > current employer, past employers, associates, friends, family, pets etc.. > > Documents attached to this email may be in ISO 26300 format: > http://iso26300.info > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20090123/7ba6200e/attachment.htm From mfioretti at nexaima.net Sat Jan 24 06:51:44 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Sat Jan 24 07:15:48 2009 Subject: [odf-discuss] Wanted: material on on how file formats impact innovation and fair markets In-Reply-To: <39891.213.203.159.55.1231924685.squirrel@nexaima.net> References: <39891.213.203.159.55.1231924685.squirrel@nexaima.net> Message-ID: <20090124115144.GF3279@nexaima.net> Sorry, maybe I canceled some reply by mistake, but isn't it anything to report on the topic below? TIA, Marco On Wed, Jan 14, 2009 10:18:05 AM +0100, Marco Fioretti wrote: > Hello, everybody! > > I am preparing an updated, extended edition of my seminar "How file > formats can be used to favor (or hamper) innovation: concrete impacts on > free markets, business competition, culture, equal opportunities, > education..." > > You can download, read and reuse the 2005 edition from > http://www.opendocumentfellowship.com/MarcoFioretti > > Right now, I welcome, either here or privately, anything you think should > be mentioned in a seminar with such a title, especially (but not > necessarily!!!) if it happened after dec. 2005. I'd like to give complete > coverage of the matter, so while I'll leave plenty of space to ODF/OoXML, > I am really interested in examples from other fields of digital > technology. > > Once I've finished, of course, I'll put this edition too on my ODF web page! > > TIA, > Marco Fioretti > http://mfioretti.net -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84