Re: [office] The Rule of Least Power

[robert_weir@us.ibm.com]

Jirka Kosek <jirka@kosek.cz> wrote on 02/12/2009 09:58:26 AM:
> 
> robert_weir@us.ibm.com wrote:
> 
> > However, I could give you equally plausible extension attributes which 

> > would require entirely different processing, and in fact would lead to 

> > horribly corrupted documents if the same processing rules were 
> > indiscriminately applied.
> 
> Indeed. But even if ODF will use the simplest policy that application
> should strip unknown extension elements/attributes this problem will be
> eliminated.
> 

That is certainly one solution.  But I think that is unsatisfactory to 
application vendors who wish to extend ODF.  I can certainly imagine 
situations where we might want to add extensions to Lotus Symphony.  But 
we cannot assume a homogenous world where everyone runs only Lotus 
Symphony.  It would not be worth adding extensions unless we had some 
confidence that they would not be stripped by every other ODF application. 
 But the general extension mechanism doesn't provide enough information to 
allow even gross level preservation of extension data under common editing 
manipulations.

This is non-optimal for the application writing the extension as well as 
the application processing the extended document.  The lack of a way to 
define safe extensions -- and I believe most are innocuous -- will stall 
the development and success of all extensions. 

It is like airport security.  Because they cannot figure out a way to 
distinguish drinking water bottles from explosives, they confiscate all of 
our liquids.  The solution is not to stop checking passengers for 
explosives.  The solution is to find a good way to distinguish safe from 
unsafe liquids.

> > Has anyone done this work already?  I'm surprised there is not a 
> > well-known standard for expressing such editing semantics.  I think 
most 
> > of my concerns would be answered if we had a standard vocabulary for 
> > indicating for extensions things like volatile="true", 
> > preserveOnCopy="false", etc.
> 
> I think that this task is very complex and AFAIK the completely general
> solution leads to NP-complete problem. Probably nothing what anyone
> would like to implement in his office application.
> 
> Of course, the most typical cases could be handled by rules you propose.
> 

The general problem is hard, as you state.  But I think we would hit 95% 
of uses by having a short list of attributes like preserveOnCopy, 
preserveOnEdit, preserveOnMove, etc. 

The key is to consider the Least Power Rule's "choosing the least powerful 
language suitable for a given purpose".  Depending on how you define the 
"given purpose" you will get different results.  If the purpose is purely 
representational, how to encode extensions data at that's all, then you 
end up with one solution.  But of we acknowledge the context of ODF, which 
by our charter is for office application "document processing and 
interchange", then we need to consider more than just encoding in the 
purpose.  The purpose needs to consider interchange as well as processing. 
 So the question we should be asking is what is the "least powerful" way 
to define extensions that work in that context?

-Rob