[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] (1)(d) A list of deliverables, with projected completion dates.
2008/6/12 <firstname.lastname@example.org>: > > Another piece I suggest we start working on: "(1)(d) A list of > deliverables, with projected completion dates". > > However, I'd suggest we discuss this as if it said "a list of prioritized > list deliverables". From a practical standpoint, it is impossible to > project completion dates until we have a good idea who will be joining the > proposed TC. Those who do line up to join the TC can huddle before we > submit the charter and turn the prioritization into projected dates. > > So far I've heard the following items (in no particular order) > > 1) A conformance test of ODF documents and implementations, i.e., test the > formal shall's and should's, etc. What do you mean by this Rob? I don't understand it sufficiently. > 2) An Acid-style test of ODF implementations, i.e., feature and > rendering-oriented, essentially highlighting ODF features that are not > widely implemented (or implemented correctly) but are desired (by whom???) > 3) A comprehensive test suite of atomic (single feature) tests Clarification. Statement of (atomic) test requirements, mapped against the ODF standard, version (TBC) > 4) A formal profile of ODF Suggest for 3,4,6 these are premature and not our job. Deliverable: A list of profiles, including a precise definition. (We then need a firm definition of a profile) > 7) A report on best practices for authoring portable documents (v.low priority) > 8) A periodic interoperability report on the state of ODF interoperability, > with specific recommendations for implementors. This group will be disbanded by then. The task needs to be put back to the main TC. Inappropriate, other than as a recommendation, together with a reason for it, wrt our audience. > > What did I miss? Basically traceability. The rationale is to stop Fred and Mary introducing tests that their implementation passes and nobody else does. No trace, no test is the logic. Any test failure should be traceable back to an ODF requirement. http://sites.google.com/a/odfiic.org/tc/Home/odf-interoperability-and-conformance#TOC-Document-hierarchy. The following sequence of documents shows the traceability needed. What is this groups responsibility, what is the TC+1 as I've called it, is for you Rob. 1. This document, Conformance and Interoperability specification. 2. The test requirement. A specification stating how each requirement of the standard will be tested and what the expected outcome of each test. 3. The test plan. A matrix linking the test requirement to the standard and a test program to the test requirement. 4. A test program. An implementation of the test requirement. 5. Expected Test results. A static document, indicating the expected output of executing an abstract implementation of the test requirement. 6. Actual test results. Generated by executing a test program. 7. Overall test result. A comparison of actual and expected test outcomes. A boolean statement of pass or fail. Additional text may provide more information. That proposes a hierarchy to address tracability. -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk