ODF 1.2 Approval and Extensions (was RE: [libreoffice-users] Calc corrupted an Excel xlsx f...)

users
#1

[Thanks Cor, I caught this one on time. New thread - this is not about the original users problem at all.]

I have no idea what it means to be using 1.2 extended (other than it being the recommended default).

There is no way to identify an ODF document as "1.2 extended". There's also no way to tell as an user whether a document written with that option set *actually* depends on a LibreOffice extension or not. Using 1.1 as my output format, or using 1.2 as my output format (not extended), I have never received a warning that my document uses features that are not supported by the target format. I don't know if that is because I have not done anything to require an extension or because I am not being told.

And finally, I have no way of telling what another consumer will do if an actual extension feature is encountered in a document identified as being ODF 1.2. (Well, I know what ODF 1.2 suggests be done. I will sort-of know what MSFT products will actually do, assuming that implementation notes come along for any support of ODF 1.2 from Redmond. I also don't know what the ODF 1.1 support will do to ODF 1.2 features not in ODF 1.1 or extensions beyond 1.2. I wonder if it is possible to know that much from current MSFT ODF 1.1 implementation notes. I must go look.)

In short, I have no idea how to answer this question.

I am on the OASIS Technical Committee for ODF Interoperability and Conformance (the OIC TC). I hope that efforts there can help take some of the unknowns out of what I just said. That is not the current state of affairs.

- Dennis

PS: Concerning your second question, Microsoft has participants on the ODF TC who've contributed considerable effort in polishing the OpenFormula specification, along with folks affiliated with OpenOffice.org, LibreOffice, Lotus Symphony, Gnumeric (very big thank you to Andreas Guelzow) and others. There were also great contributors on the comment lists. There is a ballot underway *this*very*week* to advance the ODF 1.2 Committee Specification 01 to ODF 1.2 Candidate OASIS Standard and subsequent approval by the OASIS membership. That would be the last step.

There are no secrets in this process. Here is the current status of the electronic ballot now in progress: <http://www.oasis-open.org/committees/ballot.php?id=2101>. See for yourself. It hasn't passed yet, but I have no doubt that it will, and without any "No" votes. (I am on leave-of-absence, so you don't see my name there. I am an eligible Voting Member.)

Participants from Microsoft have not voted against advancement of this specification toward becoming a standard even once. Not once. Not ever on the ODF TC. To my limited knowledge, participants representing National Bodies at the ISO and also associated with Microsoft have never voted against approval of ODF or any updates to ODF that have been made so far at ISO. That's not where No votes seem to come from in that particular document-standards cat-fight and fud-match.

#2

...

I have no idea what it means to be using 1.2 extended (other than it being
the recommended default).

Is this a legitimate question to ask the programmers?

There is no way to identify an ODF document as "1.2 extended".

I've been experimenting to use the flat xml odt format (to enable
subversion control) and notice that the element 'office' does show the
attribute 'version=1.2'. However, cannot see an indication within LO
user interface to indicate office file format version.

no way to tell as an user whether a document written with that option set
*actually* depends on a LibreOffice extension or not. Using 1.1 as my
output format, or using 1.2 as my output format (not extended), I have never
received a warning that my document uses features that are not supported by
the target format. I don't know if that is because I have not done anything
to require an extension or because I am not being told.

This should be as important than telling the user that saving a
document in a non-standard m$ format

And finally, I have no way of telling what another consumer will do if an
actual extension feature is encountered in a document identified as being
ODF 1.2.

A detailed features list would solve this problem

Participants from Microsoft have not voted against advancement of this
specification toward becoming a standard even once. Not once. Not ever on
the ODF TC. To my limited knowledge, participants representing National
Bodies at the ISO and also associated with Microsoft have never voted
against approval of ODF or any updates to ODF that have been made so far at
ISO.

Good to hear; further justification for the EU legal case that occurred.

#3

[Thanks Cor, I caught this one on time. New thread - this is not
about the original users problem at all.]

I have no idea what it means to be using 1.2 extended (other than it
being the recommended default).

Not sure if this is helpful as I know little-to-nothing about the
subject, but from the help file (lifted directly from OOo (it's the same
in OOo-Dev):

<quote>
ODF format version
OpenOffice.org 3 and StarOffice 9 introduce new features which have to
be saved using the OpenDocument format (ODF) version 1.2. The prior
versions of OpenOffice.org 2 and StarOffice 8 support the file formats
ODF 1.0/1.1. Those prior file formats cannot store all new features of
the new software.
Current versions can open documents in ODF formats 1.0/1.1 and 1.2.
When you save a document, you can select whether to save the document in
the format ODF 1.2, ODF 1.2 (Extended), or in the prior format ODF 1.0/1.1.

Currently, the ODF 1.2 (Extended) format enables files of Draw and
Impress to contain comments. Those comments can be inserted by Insert -
Comment in the latest software version. The comments get lost when
loading files into prior software versions that were saved by the latest
software version.

Some companies or organizations may require ODF documents in the ODF
1.0/1.1 format. You can select that format to save in the listbox. This
older format cannot store all new features, so the new format ODF 1.2
(Extended) is recommended where possible.
</quote>

Looks like it started here:
http://www.openoffice.org/dev_docs/features/3.2/rc1.html#general_odf
and Cor asked about it here:
<http://openoffice.org/projects/framework/lists/dev/archive/2010-01/message/16>

There is no way to identify an ODF document as "1.2 extended".
There's also no way to tell as an user whether a document written
with that option set *actually* depends on a LibreOffice extension or
not. Using 1.1 as my output format, or using 1.2 as my output format
(not extended), I have never received a warning that my document uses
features that are not supported by the target format. I don't know
if that is because I have not done anything to require an extension
or because I am not being told.

I guess that the only way you might know is to try 'Commenting' in Draw
and/or Impress. Or examining the xml.

Way too many pages in http://docs.oasis-open.org/office/v1.2/
...

#4

Wow, that's great information Gary!

Thanks. So there is no reason to choose 1.2 (extended) unless one is using the Draw and Impress commenting provision. And losing the comments in other products that don't recognize the extension is benign.

It would be great to test that.

- Dennis

#5

I didn't ask the question about extensions. I was answering the question.

You can specify the version of ODF output that is produced by going to Tools | Options | Load/Save | General | ODF format version [1.0/1.1, 1.2, 1.2 extended (recommended)]

My response is that I have no idea what 1.2 extended allows nor the consequences of producing 1.2 (or 1.1) and inadvertently using a feature not supported at those levels. Nor can one know what the impact is on another implementation of ODF 1.0/1.1 or 1.2 if some extension is actually encountered.

I think your suggestions are all good for improving the interoperability of OpenOffice.org via ODF and also having Users be able to understand the consequences of their choices.

A features list won't completely solve the interchange problem. What is needed is to know how the XML inside the ODF 1.2 document is extended to provide the feature. That is what anyone else will run into if they want to support the feature in a compatible way. But I think that is all on the right path. When I talk about implementation notes I am thinking of mostly support in the document format, but it is all good to have and know.

I don't understand the reference to a legal case. And how does Microsoft *supporting* ODF Standardization activities justify a case, or are you assuming this behavior is a consequence of an old case? Could be a factor, of course. I don't have any way to know how much.

I think the implementation notes were partly inspired by a need to demonstrate that Microsoft was not doing things that contravened the standard. I think MSFT may have felt compelled to account for deviations in their support of the format in order to be completely transparent about what they were doing. That's my sense of it based on very casual observation. More than that, I think implementation notes are a good thing regardless. It is valuable to the development team, to those who want to interoperate, and to those who need to determine whether there minimum requirements for ODF features are satisfied by a given product.

- Dennis

#6

Wow, that's great information Gary!

Thanks. So there is no reason to choose 1.2 (extended) unless one is using the Draw and Impress commenting provision. And losing the comments in other products that don't recognize the extension is benign.

It would be great to test that.

- Dennis

I'll see if I can get time to do some tests tomorrow. However, my guess
is that we'll need to post on the dev list to get further details.

Note: I've not rewrapped your response this time. You might want to look
into configuring Outlook to wrap your lines at 76 or 80 characters. Not
sure about the newer versions, but Outlook 2002 allows you to configure
this via: Tools|Options|Mail Format|Intenet Format (untick HTML of
course)|Plain text options: Automatically wrap at xx characters (76 is
the default).

Leaving the tailings in place...

#7

Dennis, I checked and it's already been asked on the dev list:

<http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/6824>
(note: you will need to click on '(continue reading)' to expand the
responses... or just go over to the dev list and view the thread there.

Still not sure if that answers /any/ questions as it seems that the
responses are as vague (to me) as the question.

Gary

...

#8

I agree. I think the question was asked better here, in terms of what the consequences for user choice are. I also think the answer about Draw and Impress is nicely concrete.

The only way I can think of other than that is to see how those features show up in the XML representation of the document. Then one might look to see if there are any others in documents, but hitting one that way may be a wild-goose chase. I agree, there should be a documented list somewhere.

It would also be good to see how such features are ignored in other products (older versions and newer) that were doubtless implemented in ignorance of those features. (An easy thing to check would be to see what Word 2007 would do with an .odt having comments in drawings. A standard action would be to silently ignore the extension. I can try Symphony too.)

This may be off-topic for [libreoffice-users] except understanding about the interoperability impact of configuration options seems useful for those who work with multiple products.

- Dennis

PS: Won't your viewer wordwrap? I know that there are screwy HTML archive pages that don't figure out when to use <p> instead of <pre>, so wordwrap is disabled. (I would love a browser button that caused wordwrap to the current width of the browser page.)

My problem, as in all of these things, is then I have to do a setting like that with everyone and not everyone likes the result of fixed line lengths (especially when the level of quotation leads to a new line break).

I'll consider it though.

#9

Dennis

I agree. I think the question was asked better here, in terms of what the consequences for user choice are. I also think the answer about Draw and Impress is nicely concrete.

The only way I can think of other than that is to see how those features show up in the XML representation of the document. Then one might look to see if there are any others in documents, but hitting one that way may be a wild-goose chase. I agree, there should be a documented list somewhere.

It would also be good to see how such features are ignored in other products (older versions and newer) that were doubtless implemented in ignorance of those features. (An easy thing to check would be to see what Word 2007 would do with an .odt having comments in drawings. A standard action would be to silently ignore the extension. I can try Symphony too.)

This may be off-topic for [libreoffice-users] except understanding about the interoperability impact of configuration options seems useful for those who work with multiple products.

To me it is on topic basic it furthers understanding of the
import/export problems with MS Office formats. This question comes up
fairly often and being able to answer it more correctly helps

#10

...
This may be of interest regarding ODF validity:
https://bugs.freedesktop.org/show_bug.cgi?id=37390
[Bug 37390 - LibreOffice does not create valid ODF.]
Includes links to the April thread & some of the tests that I did using
<http://tools.odftoolkit.org/odfvalidator/>
Also see:
<http://tools.odftoolkit.org/odfvalidator/info/>