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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] The Rule of Least Power

On Thursday 12. February 2009 18:01:00 ext robert_weir@us.ibm.com wrote:
> I'm trying to balance the various interests, that's all.  There are people
> who want to extend ODF.  OK.  Let's define a way to do this well, but in a
> way that extended data can be preserved during editing. 

As I mentioned before, having such a way sounds good. A proposal to have this 
kind of extention should be designed and proposed.

> You won't get 
> high value uses of extensions without that capability.

I respectfully disagree.  I have given various examples where this is very 
much useful. I have seen others give them as well and we have software that 
does use this feature and expects throwaway roundtripping in external 
software and accepts it.
I respect that this is your opinion, or that of IBM. But your assessment is 
false for other users of ODF.

> But I'm not sure I hear a constituency asking specifically for an
> extensibility mechanism that can never be better than a throw-away.

I think I put up my finger various times, didn't I?
That would make KOffice and Qt/Nokia be constituencies that I talk for which 
think this is still a good idea to have.
Naturally this doesn't mean I am against anything better. I just oppose the 
removal of a useful feature without proper replacement.

> And 
> if someone did want that, it could be just as well defined using less
> powerful extension mechanism.

I have to disagree again;
I'll take one of my previous examples. Please take a look at my example where 
KOffice wants to know the knot-types in a draw:path element. Then please tell 
me how I can have all path elements have an extra koffice namespaced property 
in ODF in a 'less powerful extention mechanism' ?
If all my draw:path elements (potentially quite a lot of them) need to have 
this property and you want something that is editable by other apps, I'm not 
sure what works that is not going to give us a complete mess and something 
that is very hard to use and process by generic tools.

> What am I missing here?  

I think the main thing missing in our discussion is an agreement on what the 
effect is of loosing properties.
My point of view is that its not a problem as long at the developers know 
about this up front.
Your point of view seems to be that we should scrap any extentions as long as 
there is nothing better that we could force implementations to retain.

Maybe we can find a middle ground and *first* come up with an extension 
mechanism that satisfies people with your point of view and if that proves to 
work properly we can reopen the topic of removing the extensions capability 
of ODF.
Thomas Zander

This is a digitally signed message part.

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