[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] The Rule of Least Power
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]