Re: [office] Choice of Authoritative ODF Format for Specifications

[Michael Stahl <Michael.Stahl@Sun.COM>]

On 16/06/2010 19:42, Dennis E. Hamilton wrote:
[snip]
> What appears to be the common tool for producing the specification drafts,
> OO.o 3.2.0, has the option of producing ODF 1.1 documents and it would
> probably be useful to rely on that rather than have any suggestion that an
> ODF 1.2 consumer is required for proper reading of the specifications.  (I
> am told there are some discrepancies with how numbering works, and I don't
> know if that is an implementation bug or there is a breaking change from 1.1
> to 1.2 that matters for the specification itself.)

being able to use a consumer that only supports ODF 1.1 but not ODF 1.2 to
read the ODF 1.2 specification sounds like an actual argument and a valid
use case to me (the first one so far in this discussion).

> Someone who is aware of any substantive difficulty producing and consuming
> the current specifications as ODF 1.1 should say what the problem is, if
> any.
> 
>  - Dennis
> 
> PS: I think the "ideological" objection is using a tool that has, since last
> year, claimed to be producing ODF 1.2 documents when the draft
> specifications have not even begun their first combined public review as I
> type this.  While I doubt that the specifications so-produced will be judged
> to fail to be ODF 1.2 documents at some future point, it is an irritant for
> some of us, perhaps for different multiple reasons (having at least 3 of
> them myself).

to some degree i agree that this is not ideal.
well, it's a consequence of using ODF as the native format.
we can't just tell our customers "if you want to use this new feature that
you demanded, don't save as ODF, but in the non-standard format", because
there is no non-standard format (that we can extend, at least), there is
only ODF.

i believe for post-ODF 1.2 features in OOo a different approach will be
employed, but i haven't implemented any such feature, so don't know how it
works exactly :)

> PPS: FYI for the bystanders.  It is incorrect to claim that the editable
> form of the ODF 1.0 specification is in ODF 1.0.  It is identified as a
> Star/Open Office format that happens to be consumed successfully in later
> OO.o versions.  I note that a non-OO.o ODF 1.1 consumer I have does not open
> it successfully.  On inspection of its Zip packaging and the files therein,
> it is clear that it is not an ODF document of any flavor, even though it
> resembles ODF in many ways if you ignore little things such as the 100%
> difference in namespace bindings and mimetype value and the fact that there
> are external DTDs that the XML parts depend on.  

indeed it is.  it even says so on the OASIS ODF TC website:
<quote>
It is available in PDF and in OpenOffice.org XML formats.
</quote>

my bad, had been thinking of the "1.0 second edition", which is apparently
in ODF (except for the formulas used in conditional styles, but then ODF
1.0 does not contain a formula language...).

>    FURTHERMORE The editable form of the OASIS ODF 1.1 Standard specification
> is explicitly identified as an ODF 1.0 document and I have no doubt that is
> what it is.  

> PPPS: I also notice that, as often happens when older documents are used as
> bases for editing newer ones, every part of ODF 1.2 draft 4 *except* Part 2
> (OpenFormula) still has the metadata title "OASIS Open Office
> Specification."  This leaks onto the Windows title bar for the PDF versions,
> the ones I suspect most people read.  Whether or not this is some sort of
> Freudian truth-in-labeling entertainment, we should probably clean this up.
> I shall submit an appropriate JIRA issue.

thanks for noticing this; this has also annoyed me once, but i forgot to
report it.

-- 
Michael Stahl            mailto:michael.stahl@sun.com
http://www.sun.de        OpenOffice.org/StarOffice Writer
Sun Microsystems GmbH    Nagelsweg 55, 20097 Hamburg, Germany
-----------------------------------------------------------------------
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Jürgen Kunz