[BCC to AOO Project Management Committee]
A. THE SITUATION
We have some situations of the following kind:
1. An user is working in Apache OpenOffice and makes use of various features
that appear to succeed and the desired result is visible in the presentation.
2. When the working document is saved in the default OpenDocument format, the
save occurs and there is no observed indication that the saved document is in
any way different than what the user sees.
3. On later opening the document from the saved file, the thought-to-be
successful feature result is corrupted to something else.
4. There are three flavors of this condition:
a. It is a bug (e.g., change-tracking in AOO Writer that is not preserved
across a save in OpenDocument Text file format).
b. A feature that works if saved to Microsoft Office format yet silently
fails without any indication when the document is saved to OpenDocument format.
E.g.,
<https://bz.apache.org/ooo/show_bug.cgi?id=126827>.
c. Situations, similar to (a), where a document is saved in an Office
format such that it is opened successfully in Office, but not back in AOO.
There is no problem with saving as OpenDocument though, and it is apparently an
inconsistency between export and import. I've seen this; I don't have an
example handy.
B. THE POLICY QUESTION
Category (4a) and (4c) cases are essentially defects.
Category (4b) presents policy questions concerning interoperability.
THE QUESTION IS, should the policy be that interoperability in interchange via
OpenDocument Format has precedence and is by default?
Please [DISCUSS].
- Dennis
FURTHER CONSIDERATIONS
C. COMPLICATIONS
The background principle is that any silent loss of features in saving to
default, native formats is a serious usability issue, since it occurs as
loss/corruption to the user. It is necessary to consider how to prevent such
confidence-undermining behaviors while also supporting users in what we want
them to be able to accomplish.
Using the example from (4b), the problem is that the illustrated feature is
found in .xls documents.
1. The feature works in Excel and is presented by AOO Calc as expected on
import of the .xls. The feature can be applied in AOO Calc by an user with an
opened .xls, .ods, or brand new document.
2. The feature can be preserved on saving to a .xls document but it cannot be
preserved in OpenDocument Spreadsheet (.ods) document. Instead, saving to .ods
*silently* alters the document to a form that is acceptable in the OpenDocument
Spreadsheet format.
3. Note that on saving to .xls, the rubber-stamp warning about possible loss
of features occurs, but in this case the feature is not lost. There is no such
warning when the feature in its unsupported form is transformed and saved as an
.ods file.
D. ALTERNATIVES
These are not proposals. They are just to illustrate the complexity of the
policy question.
1. In the specific case of the (4b) example, it is pretty clear that the
feature adjustment happens during Save and there is no good way to know, before
Save starts, that such a condition will arise without prior detection. We
would then be faced with warning an user, either prior to or after the save,
that a feature was not preserved and saving as an .xls should be done to retain
it. If we instead did a reload so that the altered form can be seen, the
original will be lost from the still-open document. (Note that there is
nothing to be done if the save happens as part of a shut-down of AOO or even
the computer.)
2. Another approach is to restrict features to those that are preserved in ODF
formats by AOO and to not allow their exercise otherwise. This means that the
formatting done in the example of situation (4b) would not be allowed. It also
means that, on import of an Office document where features are not preserved,
the user be warned that has happened.
3. There is a middle case. If a feature such as that of (4b) is preserved on
round-trips from an AOO non-native format (such as .xls) but not OpenDocument,
there could be a warning on opening of such a non-native format when there are
features of the document that are only preserved if the document is only saved
back to the same format. (Those should be documented somewhere, of course.)
If the feature is not supported at all, alternative (2) here could apply.
Warning could also pop-up when an user relies on such a feature in an edit,
if not already warned. If the document is saved to AOO-native OpenDocument
format, then alternative (1) above could kick in. Since more is known, in this
case, the warning in (1) could happen before the save is carried out, just as
there are (unfortunately rubber-stamp) warnings on saves to non-native formats.
E. IMPLEMENTATION
Except for doing nothing or rejecting documents in some heavy-handed way, any
improvements in this area will likely have to be gradual and will all depend on
our capacity and capability for making changes in this area. It may mean that
we do nothing for an extended time.
That does not mean we should be unclear about what our policy is about these
questions. It just remains to ensure that future execution is aligned.
*** end of further considerations ***
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
