| Glossary of terms used during the TC discussion list phase. The purpose of this glossary is to capture the meaning of terms as used by that group. Term: Our usage 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. Profile 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 Acid test: The phrase comes to us from the Web Standards Project (WSP) acid tests. In their usage, it's a document that does a comprehensive test and renders the results visually in a manner that makes failures immediately obvious to the casual observer. Profile: ISO defines a profile as a "harmonised document which identifies a standard or group of standards, together with options and parameters, necessary to accomplish a function or set of functions". Shall, must, may .... RW:Whether something is testable or not does not depend on whether it is a "shall" or a "should". Both are provisions of the standard, and both are normative. "Shall" denotes a requirement and "should" denotes a recommendation. Whether it is testable or not depends on whether the provision is written precisely, accurately and clearly. In particular, we could define the test requirements such that violations of requirements and recommendations are both reported, perhaps with different output classes, e.g., "error" versus "warning" versus "informational". |