[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Profiles: suggested use-cases
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]