Re: [office] The Rule of Least Power

[Bob Jolliffe <bobjolliffe@gmail.com>]

Thomas

2009/2/16 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.

It sound like you are saying that ODF is missing a critical feature
for professional vector editing  (I don't pretend to be an expert on
vector editing but I understand the idea).  Have you proposed such a
feature for 1.2?  I don't recall seeing it.  If not, it sounds like
this is a really good candidate for requirements collection for the
next version.

> 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.

Wrong.  What we want to avoid is any kind of return to application
specific formats.  What we want are standard document formats.  There
are strong democratic and pragmatic imperatives which drive this
logic.  Now I like Koffice, but I also really want it to produce
standard documents.  The problem is that all the many vendors involved
can and will say that their application can do a little something a
little better than what the standard specifies.  That is
understandable.  Vendors want to differentiate their products after
all.  But the way I see it, you have two choices:
(1) if the feature is sufficiently critical - propose it for inclusion
(2) if it is a "nice to have" peculiar to the functionality of a
particular application, then you can produce an odf-hosted (I still
prefer hosted to extended - I'll just use the term one last time) xml
stream which contains your extended node descriptions.

> 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.

Willing or unwilling is not the point.  Even hurting ODF is not the
point.  If it hurts the users who have an expectation that an odf
document is an odf document, then that is something which I fear.  I
guess there's always a bit of a tradeoff - what is good for one
implementation may be awkward for another.  And what's good for users
might be inconvenient for vendors.

> 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.

It seems you are saying "give us guns, we won't use them".  And I
agree, probably you won't.  But hey, I'm still not supporting the
giving out of guns.

> 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.

We weren't told.  We pretty much figured it out for ourselves :-)

>  Using the ODF-Testsuite we would get
> *much* more realistic results that show the compliance of the implementation.

Agreed.  Format compliance is just one step along the way towards
interoperable applications.  The rest depends on the consensus seeking
around features which takes place between implementors on this
committee.  And there's no easy way round that.  When I first joined
this committee it was engaged in going through that detailed
spreadsheet of application default settings.  That exercise,
unexciting as it was, impressed me greatly.  A lot of effort, a lot of
compromise, a lot of generosity, a lot of shared vision.  That's what
we need at this point.  Just not too much generosity for an
"extension" mechanism which will allow each vendor to clear the low
conformance hurdle whilst maintaining their own application specific
idiosyncrasies.

Regards
Bob

> --
> Thomas Zander
>