Re: [office] The Rule of Least Power

[robert_weir@us.ibm.com]

Thomas Zander <T.Zander@nokia.com> wrote on 02/12/2009 11:31:52 AM:


> 
> Afterall, putting my properties in a the app-specific data or in 
1.2-metadata 
> makes it just as much of a black box as putting it directly in the tags. 
They 
> are just as hard to manipulate by 3th party implementations and those 
have no 
> idea when the properties should be removed of modified or duplicated. 
But 
> your policy would make *that* a legal way of extending ODF allowing an 
> implementation to still be called 'pure' while a more readable version 
with 
> exactly the same bad interoperability will not be.
> 


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.  You won't get 
high value uses of extensions without that capability.

I also hear that some people want no extensions at all in an ODF document. 
 If that's what they want, then let's define a strict conformance class so 
those users can more easily specify their requirements when procuring 
software with those specific capabilities.

But I'm not sure I hear a constituency asking specifically for an 
extensibility mechanism that can never be better than a throw-away.  And 
if someone did want that, it could be just as well defined using less 
powerful extension mechanism.  Does anyone lose by moving toward a 
better-defined extensibility model?  I don't want to leave anyone out. But 
honestly I see a move like this as a win-win situation. 

What am I missing here?  Is the concern about the forwards compatibility 
of ODF 1.1 documents?  Or the ability of ODF 1.1 processors to read ODF 
1.2 documents? Something else?

If we do come up with a better mechanism, such as some extension data 
processing attributes, we could apply those to the RDF metadata as well. 
As you point out they have the same issues.

-Rob