Daniel Carrera <> 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:
validity -- document is valid according to
schema
validity++ -- document follows additional
constraints from the specification, including packaging, additional semantic
constraints, etc.
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:
produces only valid output
produces only valid++ output
produces only preferred output
For applications which read documents:
can read all preferred documents
can read all valid++ documents
can read all valid documents
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.
-Rob
