Every time I see discussions like this one I remember the good and old
KISS methodology.
It is clear to me that we have, at least, two different user cases here,
and we are trying to discuss them as if they are the same one.
They are:
1. Users that need to have the ability to exchange their office suite
(or application) as they change they socks. They also need to get
assured that anyone who need to exchange documents with them will be
able to use any office suite too, without missing anything (features or
data or even formating properties). For those users (typically
governments), a "strict conformance" class is absolutely necessary (and
I have several real world histories and use cases in Brazil to
illustrate this scenario...).
2. Users that may have the opportunity to define (or develop) a specific
office suite (or office application) tho their use, that will accept and
treat some additional data inside their ODF documents, that are useful
on their corporate environment (and may or not, be useful to others).
Those users can easily define that Jomar's Office is the best
application to their own needs and define that they'll only use that
application (despite if it generate "strict" or "extended" ODF documents).
I don't think that with two conformance classes we'll be creating a
"first" and a "second" class of documents. ODF users have different
needs and they will "choose" the best conformance to their needs, not
us. (I live in Brazil and it may not be the best place to live to a user
that requires "high tech products at low price", but it is a paradise
for a user that have as a requirement "great beaches and cold caipirinha
!!!").
Best,
Jomar
