Navigation

Recent site activity

List of Deliverables

1d. A list of deliverables, with projected completion dates.


This document is available for editing here (and published here)




AudienceDescription
ImplementorsCommercial and Open Source distributors of ODF native or compatible applications and tools.
IntegratorsThird-party developers and independent software vendors who interact with and/or integrate ODF.
UsersEnd Users of ODF applications and tools, including both typical and 'power' users.
ProcurersProcurers and purchasers of ODF-related technology.
RegulatorsOfficials who specify the use of document standards.
TestersThird-party testing and certification labs.
Implementors


Added to from list discussions: 2008-06-20
  1. Produce a report on the current state of ODF implementation interoperability; strengths, weaknesses and recommendations for future improvement.
  2. Research  best practices on profiles and  produce a report on ODF Profiles.
  3. Produce an "ODF Conformance Test Requirements" document  detailing how each atomic item in the standard is to be tested for conformance of an ODF document and of an ODF  application to the ODF standard.
  4. A definition of a normalized/canonical ODF instance used to support a comparison tool. (See Issues page for more on C18N)
  5. To consider and provide, if applicable, relative priorities to tests or groups of tests?
  6. Remember conformance requirements now apply. See http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html
  7. The TC shall deliver a definition of c18N above and beyond w3c c18N, to include such as style variations and any other relevant considerations for the purposes of supporting interop testing.
  8. To consider and provide, if applicable, relative priorities to tests or groups of tests, one test or test group with another
  9. To define how test documents are to be collected for use in testing.
  10. A means of identifying extensions to ODF and adding an warning comment to the test output"
  11. The specification of an FAQ, if appropriate, targeted at interoperability and conformance issues [see note 2]
  12. A specification of interoperability addressing XML code level interoperation. [see note 3]

Note. To steal from the xml-c14n spec:

A canonical form of ODF is: "A set of specifications that describes a method for generating a physical representation, the canonical form, of an [ODF] document that accounts for the permissible changes."

"A set of" is used because we'd need more than one. We'd need a spec to canonicalize styles.xml, content.xml, the manifest, the zip file (packing order of the files? it may already be in the zip spec. If so, this could be skipped), etcetera.


The ideas behind the 'extensions constraint' were:
Inclusion of an unknown feature breaks interoperability. Therefore, if content implementing an unknown feature is inserted into an ODF document, the result is no longer an ODF document. Such content should [issue a warning to the user? | not be done | be flagged as fail on conformance testing | be considered as non-interoperable behavior | pick one, several, add to list].

An unknown feature is defined as any content placed into an ODF document which is not supportable by a known, unrestricted [able to be used by all without royalty or use restriction], and operable implementation of that method.




Note 2.
Questions that would be  useful to a non-technical audience include:

"What features can (and cannot) be expected to interoperate between conformant apps?"

and

"Will an ODF document opened by a conformant app and then saved as an ODF document loose information?"

The FAQ deliverable is more aimed at the sorts  of questions an implementor may be asking.  But there is nothing saying we  cannot put a plain language explanation of the TC's charter into the FAQs as  well.  The FAQ can easily serve as a tool to express ideas or concerns the  public and/or implementors may want to hear about.


Note 3.

XML level interop to act as if the following were part of the standard
"when an application doesn't support an element or attribute that is part of the ODF namespaces, the application shall  not change or remove said element or attribute (unless the parent is  changed or removed by the user?)"
This means that an application shall not amend user created content or markup (metadata such as date last modified is classed as user content)