OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Versions and ODF-Next: was Thoughts on ODF-Next

    Posted 01-18-2011 12:56
    Greetings! I have changed the subject line to make it a little more obvious what is under discussion. What I am missing in this discussion is what advantage is there to having a designation, say ODF 1.3, that identifies *different* versions of ODF? Or to put it differently: What is the disadvantage in *accurately* identifying the version of ODF that is being implemented? Hope everyone is having a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1


  • 2.  Re: [office] Versions and ODF-Next: was Thoughts on ODF-Next

    Posted 01-18-2011 14:32
    Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:54:58 AM: > > Greetings! > > I have changed the subject line to make it a little more obvious what is > under discussion. > > What I am missing in this discussion is what advantage is there to > having a designation, say ODF 1.3, that identifies *different* versions > of ODF? > Advantage: If there are more than one vendor who can read the same draft of ODF then they can handle in a more coordinated way any incompatible specification changes between that draft and subsequent versions. > Or to put it differently: What is the disadvantage in *accurately* > identifying the version of ODF that is being implemented? > Disadvantage: This may not be sufficient. In practice, early implementations of a draft may have incompatibilities as much caused by differing interpretations of the same specifications as by the use of different versions of the specifications. That is one reason why we encourage early implementation, why we have plugfests, etc. Merely knowing that someone has implemented "ODF 1.3 CSD01" may not tell enough. You may need to look also at the <meta:generator> element in meta.xml. Also, we need to remember that a given editor may actually implement several versions of ODF, and even a given ODF document may be conformant to several versions of ODF. So having a string that says "I am conforming to this version of the spec" will not reflect the fullness of the facts and circumstances. If a document conforms to ODF 1.0, 1.1 and 1.2 (including all CSDs of them) as well as ODF 1.3 CSD01, then any single value of a "version-supported" attribute would be a lie. And what if (hypothetically) there was an error in ODF 1.2 CSD-02, making the document conformant to all previous drafts except that one. Even a "latest-version-conformant-to" attribute would not work there. So no objections per se to adding an attribute for this kind of information, though I don't see in practice how it could be made accurate or useful. -Rob > Hope everyone is having a great day! > > Patrick > -- > Patrick Durusau > patrick@durusau.net > Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 > Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) > > Another Word For It (blog): http://tm.durusau.net > Homepage: http://www.durusau.net > Twitter: patrickDurusau > Newcomb Number: 1 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >


  • 3.  Re: [office] Versions and ODF-Next: was Thoughts on ODF-Next

    Posted 01-18-2011 15:46
    Rob, On Tue, 2011-01-18 at 09:34 -0500, robert_weir@us.ibm.com wrote: > Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:54:58 AM: > > > > Greetings! > > > > I have changed the subject line to make it a little more obvious what is > > under discussion. > > > > What I am missing in this discussion is what advantage is there to > > having a designation, say ODF 1.3, that identifies *different* versions > > of ODF? > > > > Advantage: If there are more than one vendor who can read the same draft > of ODF then they can handle in a more coordinated way any incompatible > specification changes between that draft and subsequent versions. > Sorry, that went by rather quickly. Do you mean that having one label, say ODF 1.3, then vendors can get together to handle inconsistencies between the "editions" that lead up to the final 1.3 "version?" I suppose but where does that leave users who only see "1.3?" > > Or to put it differently: What is the disadvantage in *accurately* > > identifying the version of ODF that is being implemented? > > > > Disadvantage: This may not be sufficient. In practice, early > implementations of a draft may have incompatibilities as much caused by > differing interpretations of the same specifications as by the use of > different versions of the specifications. That is one reason why we > encourage early implementation, why we have plugfests, etc. Merely > knowing that someone has implemented "ODF 1.3 CSD01" may not tell enough. > You may need to look also at the <meta:generator> element in meta.xml. > > Also, we need to remember that a given editor may actually implement > several versions of ODF, and even a given ODF document may be conformant > to several versions of ODF. So having a string that says "I am conforming > to this version of the spec" will not reflect the fullness of the facts > and circumstances. If a document conforms to ODF 1.0, 1.1 and 1.2 > (including all CSDs of them) as well as ODF 1.3 CSD01, then any single > value of a "version-supported" attribute would be a lie. And what if > (hypothetically) there was an error in ODF 1.2 CSD-02, making the document > conformant to all previous drafts except that one. Even a > "latest-version-conformant-to" attribute would not work there. > > So no objections per se to adding an attribute for this kind of > information, though I don't see in practice how it could be made accurate > or useful. > I wasn't necessarily suggesting the attribute approach, which as you point out, may have problems. It could be that we simply have to tell users to view claims of conformance to non-final versions with a grain of salt. That unless and until a final version appears, there is a greater burden on users of investigating what they are being promised by a particular implementation. Hope you are having a great day! Patrick PS: Cautioning users might be a useful exercise in any case. Conformance clauses are not self-executing and users need to compare implementations to conformance clauses or undertake other testing of conformance before reaching conclusions with regard to conformance. -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1


  • 4.  Re: [office] Versions and ODF-Next: was Thoughts on ODF-Next

    Posted 01-18-2011 16:07
    Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 10:45:34 AM: > > > > Advantage: If there are more than one vendor who can read the same draft > > of ODF then they can handle in a more coordinated way any incompatible > > specification changes between that draft and subsequent versions. > > > > Sorry, that went by rather quickly. > > Do you mean that having one label, say ODF 1.3, then vendors can get > together to handle inconsistencies between the "editions" that lead up > to the final 1.3 "version?" > > I suppose but where does that leave users who only see "1.3?" > I think you would need either: office:version="1.3 (CSD01)" or office:version="1.3.1" or office:version="1.3" along with office:draft-version="CSD01" > > So no objections per se to adding an attribute for this kind of > > information, though I don't see in practice how it could be made accurate > > or useful. > > > > I wasn't necessarily suggesting the attribute approach, which as you > point out, may have problems. > > It could be that we simply have to tell users to view claims of > conformance to non-final versions with a grain of salt. > > That unless and until a final version appears, there is a greater burden > on users of investigating what they are being promised by a particular > implementation. > The practical problem with that approach is that users don't read the spec. In fact, most don't even read the product manual. Maybe if the file save dialog said "Save as ODF 1.3 (CSD03)" and gave a repressible warning message the first time, maybe that would work. An implementation that was concerned about this issue and wanted to inform its users about the trade-offs of saving to a pre-final version of the standard could do that. There is nothing in the ODF specification that prevents a vendor from doing this today. -Rob