Definitions.profile: is a set of policies, guidelines [[and constraints]] defined for a particular application. A profile defines conformance, just like any other standard. And this conformance could be tested. Profiles examples.1. E.g. Web based documents, Googledocs. What parts of ODF are appropriate, essential, nice to have, less useful. 2. E.g. A mobile profile. How ODF might be used on a mobile phone or PDA. 3. E.g. Interchange profile. Some (reduced?) schema for document interchange and archiving. Readily validated. 4. E.g. Accessibility profile for non visual user. The application reading the document processes the same file list, but no visual styling is done. Audio and tactile output are produced. Document related Profile. 1. Some variation (subset or superset?) of the ODF Schema for a given purpose. Could be to 'enable', or satisfy a use case. 2. Schema based, Adjustments to the schema are made to suite a use case. E.g. restrict the character set to (xyz) for use in Country xx-YY. 3. An interchange format. A schema solely for interchanging ODF instances. See also http://en.wikipedia.org/wiki/Profile_%28engineering%29 User based profiles.
From discussions ~20 June. Author GH. Base Interoperability Profile-data specification language-equation specification language -element specification language -document metadata specification -internationalization specification (US English, Spanish, Portugese, etc.) Visual Interoperability Profile-all of the Base Interoperability Profile-display specification language Accessibility Interoperability Profile-all of the Base Interoperability Profile-tone specification language (audio) -volume specification language (audio) -other accessibility options Printing Interoperability Profile (some of this may not be necessary)-all of the Base Interoperability Profile-printer option specifications (may be PostScript compliance, font specifications, etc.) Some applications would not need to implement all of these profiles, others would need to implement them all, depending upon their function and audience. For example, you really wouldn't expect a drawing program like OpenOffice.org's 'draw' to implement the Accessibility Interoperability Profile for the audio specifications, would you? I am not trying to be insensitive here, but how many blind people use drawing tools? Presentation tools maybe, but not drawing tools. This is another reason why I pulled out things like Internationalization, metadata specifications, data specifications, and equation specifications into the 'Base Interoperability Profile'. These are things that will apply to (almost) all applications, whether they have accessibility requirements or not. It also means people can test base compliance separately from accessibility features. Functional profiles based on feature sets:
Profiles use cases. SM.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 1Say there is some core profile "ODF/C" and an extended profile "ODF/E" which is a superset of 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 2Same as above, say there is some core profile "ODF/C" and an extended profile "ODF/E" which is a superset of 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. DP. A profile which describes the use of ODF as an archive format for long term storage of documents. A profile which describes the use of ODF in a minimalist environment such as a PDA A profile which subsets the spreadsheet functionality removing all graphics (for ease of implementation) A profile which constrains ODF not to have any graphical content, for use with a tactile output device. Please, write more use-cases. Comment on these. Expand them. -- Comment on the utility of profiles. A practical way in which this would all help improve interoperability, would be if applications, when reading ODF, were able to read everything that the ODF standard allows, but when writing ODF, they should write conservatively, and aim to have their output documents issue no errors (of course) but also no warnings or notes. -- If we consider "ODF standard" above to be shorthand for (one or more) ODF profile(s), eg, ODF/core-X, then it highlights that reading and writing can follow distinct (levels of) profiles. More generally: an app can implement (adhere to) multiple profiles and follow any one of these during a prescribed scenario. Perhaps the choice is guided by a manual user settable mode/config or else based on configured or fixed automated interpretation of context. -- The above also actually *recommends* a particular approach: to read liberally but write conservatively (as IETF guidelines). This won't apply in all use cases, however. One more example and one that is somewhat at odds with round-tripping: -- an app working from (a mode of) a strict profile rejects or warns, etc, about documents that do not conform to its strictness. The issue is about not accepting deviations from the strict expectations. This is a great profile class for those users that want to have some added confidence that documents are not being invaded by foreign features outside of their configured settings (outside of the strict mode). This is very useful to many different groups under many scenarios. |
Profiles |