OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] Goals/levels/packaging/complex numbers

Daniel Carrera <daniel.carrera@zmsl.com> wrote on 03/01/2006 05:10:36 AM:
> > I'm not sure there is such thing as ODF-compliance for an application
> > which merely reads ODF other than accepting all valid ODF documents and
> > degrading gracefully if reference is made of an unimplemented feature.
> So, ODF viewers and ODF import filters can't be "compliant"?

It depends on your definition.  At the core, compliance with a markup specification is a requirement for document validity.  So a program that creates an ODF document has a straightforward definition of compliance.   But if you are not writing or modifying a document's markup, then compliance == validity doesn't make sense.  We would need a different definition for compliance in that case.

For example, you can imagine a range of nested statements, from least-interoperable to most-interoperable:

For documents:
  1. validity -- document is valid according to schema
  2. validity++ -- document follows additional constraints from the specification, including packaging, additional semantic constraints, etc.
  3. preferred -- document follows best practices(style guidelines) for things like consistent use of named styles, use of accessibility annotations, complete bibliographic metadata, etc.

For applications which write documents:
  1. produces only valid output
  2. produces only valid++ output
  3. produces only preferred output

For applications which read documents:
  1. can read all preferred documents
  2. can read all valid++ documents
  3. can read all valid documents
  4. can read all documents, including ones which are sightly malformed, and correct them

Note that the most interoperable application is the one which always produces preferred output, but is tolerant of less-than-perfect input.  But the whole topic is complex and really deserves some attention from the TC as a whole, and probably in a new compliance subcommittee at some point.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]