Re: [office] The Rule of Least Power

[Thomas Zander <T.Zander@nokia.com>]

On Friday 13. February 2009 22:58:46 ext Jomar Silva wrote:
> 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 think this looks good at first, but thinking a bit more about it, I get the 
strong impression its a bit too simplistic. Too much black/white.
Lets use the usecase of koffice:nodeTypes again, which is an attribute saved 
in a path.
The property is saved to allow the user to edit the path and the path will 
remember the type of node. If you ever edited a vector path you know that it 
is build up from 'nodes' that have one or more control points. The way you 
interact with this depends on the node-type.

The suggestion to make koffice save 'strict conforming' data then basically 
means that you will always loose the information of which type of control you 
are editing. Making re-editing rather annoying, but not much more.

Therefor I think having this information saved even in an 'strict conformance' 
mode does not harm anyone and only helps the user not loose part of his work, 
which is really critical for using ODF as a native format for professional 
vector editors.

In conclusion this one example falls between the two usecases.  No government 
will care at all that this extension is there and forcing KOffice to not save 
it will just harm the user that uses the same app for re-editing.

In fact, I want to go back to the origin of the reason for asking for usecase 
(1) in the first place.
I'm curious if others can come up with an example where an implementation 
extending ODF using namespaces is willingly hurting ODF and thus something we 
need to enhance the spec to protect against, as this proposal does.

The more I read this thread and ask questions, the more I get the impression 
that the only reason this proposal is made is out of unfounded fear.

In reality applications will be chosen based on which subset of the features 
of ODF they support, both loading+displaying and saving them.
So I fear that those governments that were told they need a 'strict 
compliance' tool have been misguided.  Using the ODF-Testsuite we would get 
*much* more realistic results that show the compliance of the implementation.
-- 
Thomas Zander

This is a digitally signed message part.