[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Deliverables. Summary.
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