Profiles: suggested use-cases

[Sander Marechal <s.marechal@jejik.com>]

In an attempt to write down what profiles should do through use-cases,
while skipping the exact definition of profiles (as suggested:
http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00557.html),
here is an attempt to come up with some use-cases for ODF profiles.

Use-case: Round-tripping, part 1
--------------------------------

Say there is some core profile "ODF/C" and an extended profile "ODF/E"
which builds on ODF/C. Now say that application "AppC" only implements
ODF/C and that application "AppE" implements ODF/E.

When AppE is presented with an ODF/C document, the application should be
able to edit the document and save it as ODF/C, so that the document can
be loaded by AppC again. This should be the default behaviour for AppE.
Of course, AppE may be configured to save it as OFD/E instead, to make
use of the extra features that are not in ODF/C.

Rationale: interoperability profiles should not be a one-way street. If
AppE doesn't write ODF/C then it will be very hard for users if they
want to keep their documents in ODF/C. They could only use applications
that explicitly support ODF/C and not applications that support more.


Use-case: Round-tripping, part 2
--------------------------------
Same as above, say there is some core profile "ODF/C" and an extended
profile "ODF/E" which builds on ODF/C. Now say that application "AppC"
only implements ODF/C and that application "AppE" implements ODF/E.

When AppC is presented with a document in ODF/E it should be able to
load it and let the user do everything that is supported by ODF/C. AppC
should ignore all the parts of the document that are in ODF/E but not in
ODF/C, but it should not forget them. When the document is edited and
saved, it should by default save the document to ODF/E and attempt to
preserve the extra bits from ODF/E that it does not understand.

A more explicit example: Suppose ODF/C is a core spreadsheet profile
containing the table model, the formulas but not the charts. Suppose
ODF/E is ODF/C plus the charts. AppC should be able to edit the data in
the table cells and simply save the chart elements unchanged, so that
the chart will show up when the document is opened again in AppE.
Alternatively, when the unknown chart elements are on sheet 2 for
example, and the user deletes sheet 2, AppC may discard those unknown
elements when it saves the document.

Rationale: A user of AppE should not loose a whole lot of data from a
document, just because a document was edited by someone else who used AppC.


Please, write more use-cases. Comment on these. Expand them. Speak up if
you disagree with them.

-- 
Sander Marechal