Deliverables. Summary.

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

Not a trawl of all 300+ emails.
Searched on all threads containing 'deliverable'. (Around 120)

results below.
If you see anything with your initials against it, please shout.

Summary notes from emails.
Up until 2008-06-20
Source Dave Pawson.
I have interpreted where I believe a deliverable


*Deliverables

[RW summary]
1) Researching the state of ODF interoperability today and issuing a
report, with recommendations.  Update this report periodically. RW
2) Researching the best practices in profiles, and issuing a "ODF
Profiles Requirements" document. RW
3) Creating an "ODF Conformance Test Requirements" document that
details the exact items required to test conformance of an ODF
document and of an ODF application to the ODF standard. RW
4) Creating an ODF Interoperability Test Requirements document that
defines additional tests, including an Acid-like test and other
interoperability tests. RW
5) Create the actual ODF instance documents needed to meet the
requirements of the Interoperability Test Requirements above. RW
6) Write profile of ODF to improve interoperability in specific areas.
 I've heard ODF for archiving and ODF for web mentioned. RW
7) Write guidelines for ODF implementors on various topics, i.e., how
to use the internationalization features of ODF. RW
8) Write a report on best practices in creating interoperable
documents with ODF. RW
9) Unspecified deliverables on improving interoperability with other
markup languages, e.g., DITA, OOXML.  RW


From earlier emails

our formal deliverables need to be documents. RW



** Related to deliverables

If it says nothing about how a particular combinations of elements are
rendered, then we cannot require a specific rendering in our
conformance assessment. I think we will find that most rendering and
runtime behaviors are outside the scope of what ODF defines.  RW

a set of test cases that exercise all of the rendering primitives of ODF. RW

We need features tested in combination to find defects that are
exhibited under those circumstances. RW

Compliance needs to cater for vendors which only provide a part of
ODF, e.g. a spreadsheet. DP

Categories of interop: Full, partial and incomplete. MR


Anticipated deliverables with target delivery dates include:     *
XML.org OpenDocument Focus Area (3Q/2006) SJ
    * White papers (3Q/2006) SJ
    * Position papers (3Q/2006) SJ
    * Case studies (4Q/2006) SJ
    * Presentations (3Q/2006) SJ
    * Webinars (3Q/2006) SJ
    * FAQs (3Q/2006)  SJ
    * Proof-of-Concept demo scenarios and templates (4Q/2006) SJ


The traceability of our requirements is critical.  If we have a test
document that says "verify that the application does X" then we better
be sure we can cite chapter and verse of the ODF standard to where X
is called for.  RW

I suggest we don't make "name and shame" a formal TC goal.  It is
probably better to let someone else do that.  In fact, there are good
reasons for drawing a clear line between those who define the tests
and those that evaluate implementations.  RW


Include acid test. (to be run by anyone) [[TC identifies the 10, 20,
50 or whatever features that in practice are causing interoperability
problems RW]] PD SJ LB ...

A profile which excludes 'difficult' functionality, could be called
ODF/A (For archiving)   SJ


'Layout perfect' to be addressed.[[fonts, line endings changed]] DG


there appears to be a requirement that we examine the ('printed')
output of these applications. *What* we expect, in terms of scaling,
devices, tolerances etc. is important  SJ

One deliverable I've proposed is a report "Authoring Portable
Documents: How to maximize interoperability with ODF", which would be
targeted to end-users.  RW

All deliverables to be reviewed for accessibility. Reading and use.  DP

Some form of prioritization for compliance test, e.g. to indicate that
test X is higher priority than test Y. DP

A way to validate formulae syntax/implementations/results. DP


Reference implementation. Mentioned, very useful, not doable?

a report on the commonly demanded features and their interoperability staus. SJ

to propose a new TC in OASIS that would create these test cases, and
then invite the public to discuss the idea, and hopefully to join the
new OASIS TC.  RW


Report back ['bugs' e.g. radial gradient issue] to the main TC. SJ DP.
(Note RW wanted to use liaison for this purpose).


to provide guidance for implementors. Simply speaking, the best way to
achieve interoperability between ODF applications is that these
application implement as many of ODF as possible and reasonable for
the specific application, and with as little bugs as possible. MB
Note: later,
 However, the former definition[[the one above]], which Michael
mentions, is what I had in mind when drafting the initial scope
statement.  But although I see the need for such "guides for ODF
implementors" we might want that to be a function of the ODF TC. RW.



Depending on the conclusions that will be reached in discussions with
the Accessibility Subcommittee, either (a) a test suite based on the
recommendations of the ODF Accessibility Guidelines document, or (b)
an explanation why no such test suite is needed" on the list of
deliverables.  NB

Tests to verify compliance with a profile. SJ.

A list of profiles, including a precise definition. (We then need a
firm definition of a profile) DP

Requirement for tracability of any test to the standard. DP

If we provide tests, then we should provide tests that are applicable
to all kind of documents.  MB, concerning presentational tests.
2008-06-13

aim to measure, improve or write guidelines for those ODF features
that are commonly used rather than caring about a few features that
are seldom used. MB

I am indifferent to whether it[[implementation guidelines for ODF]] is
done in this TC or the ODF TC. RW


a document that details the requirements of a conformance testing
tool.  This would mainly be a task of collecting and collating the
normative provisions of each ODF version, along with provisions in
referenced standards, and putting them in a logical order, noting
dependencies, assigning each one an ID, etc.  It would also define
scoring and reporting requirements for a conformance test.  RW

interoperability tests should be traceable to a provision of the ODF
standard, or to a profile of the ODF standard that the proposed TC
creates. RW

To provide feedback, where necessary, to the ODF TC on ways in
which the standard could improve interoperability. MBX (goes on to
quote the formation scoping notice)

recommend to the OpenDocument TC a clear and unambiguous specification
of "conformity requirements essential to achieve the interoperability.
MBX

exit criterion" means a requirement that must be complied with prior
to a profile being submitted to the OASIS membership as a candidate
OASIIS standard): [[To be added to each profile]] MBX

As an exit criterion, that each and every such profile be fully
implemented in at least two Different Information Technology Systems. MBX
Numerous other exit criteria. See his message 2008-06-13


development of a profile that matches as closely as is feasible the
requirements specified by IDABC and other European Union governments
at the Open Document Exchange Formats Workshop 2007 and the Advancing
eGovernment Conference. <http://ec.europa.eu/idabc/en/document/6474>.
MBX

 the conformity assessment methodology document would define scoring
requirements.  ..., one could say that total score = number of tests
which pass / total number of tests defined in the suite. RW


include a goal of improving that area [[layout perfect]] in the
charter.  The fact that perfection is not possible should not prevent
us from doing what is doable. RW SM

creation of a report on the applicability of CDRF to ODF profiles.
Query from RW.


propose changes back to the TC to clarify a requirement. DP SC




regards DaveP

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk