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: The Rule of Least Power

I've been struggling to articulate exactly why I don't like the 
general-purpose foreign-content mechanism in ODF, and why I think it is so 
dangerous.  But I just stumbled on a W3C "TAG Finding" (essentially 
architectural principles promulgated by the W3C's top architects) that 
says it clearer than I have.

The paper is called "The Rule of Least Power" and I'd encourage members to 
give it a quick read. 


The abstract gives the gist of it:

"When designing computer systems, one is often faced with a choice between 
using a more or less powerful language for publishing information, for 
expressing constraints, or for solving some problem. This finding explores 
tradeoffs relating the choice of language to reusability of information. 
The 'Rule of Least Power' suggests choosing the least powerful language 
suitable for a given purpose."

This is one reason our RDF/XML metadata may be preferred than the general 
foreign-content mechanism, and why even more targeted mechanisms are 
appropriate for more targeted purposes. 

It is paradoxical, but the "most powerful" extensibility mechanism is not 
always the best.  Certainly arbitrary memory pointers in C are more 
powerful than object references in Java.  But this is a hindrance and a 
liability unless you need that particular power in pointers, i.e., in the 
DOS days when we could write directly to video RAM at a fixed address. 
Bringing out the nuclear death ray gun every time you want to swat a fly 
will eventually get you in trouble.

So I wonder where exactly in ODF do we need/want extensibility?  Can these 
easily be enumerated?  If so, what is the least powerful extensibility 
mechanism that will work in these cases?  Remember, if we reduce the power 
of the mechanism for expressing extensions, we at the same time reduce the 
requirements for consumers of the documents, who would then not need to 
manage dealing with the general case of arbitrary extensions.

I've started a wiki page where we can hopefully enumerate what mechanisms 
we know are currently in use, or anticipated.  I'd encourage TC members to 
append additional examples that you know of. 



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