Re: [oiic-formation-discuss] (1)(d) A list of deliverables, with projected completion dates.

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/12  <robert_weir@us.ibm.com>:
>
> 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