Re: [office] The Rule of Least Power

[robert_weir@us.ibm.com]

Thomas Zander <T.Zander@nokia.com> wrote on 02/12/2009 06:51:39 AM:

> 
> On Thursday 12. February 2009 11:49:33 ext robert_weir@us.ibm.com wrote:
> > > I've asked in another mail for your reason to drive this proposal.
> > > Please give
> > > a usecase where the current ODF conformity clause will give us 
headaces.
> >
> > > I don't see them and I will never be convinced to take away useful 
and
> > > good features unless I see a good reason where it ends up hurting 
more.
> >
> > Sorry, we must have missed each other's messages in the traffic.  I
> > addressed the specific kinds of problems caused by the general 
mechanism
> > in this note:
> >
> > http://lists.oasis-open.org/archives/office/200902/msg00070.html
> 
> That mail just posts some anonymous element; thats not a usecase.
> I can't even argue that the "foo:bar" is or is not a loss if an 
> implementation 
> ignores it since you don't give a realistic usecase to argue from.
> 

But that's the important point.  From the perspective of an general ODF 
consumer, say a word processor, these private extensions are opaque, 
without any discernible semantics, just like foo:bar.  The consumer is 
only able to make very general assumptions -- the extension is well-formed 
XML -- but this is insufficient to make even the most basic judgements 
about how the extension behaves when the extended content is copied, 
edited, split, combined, etc., the most basic editing operations.  As I 
showed, given such arbitrary extensions, the general consumer is pretty 
much forced to drop all extension markup. 


> > Now, you might very well say, "But here are N specific examples where 
this
> > is not a problem".  But that proves my point.
> 
> I'd rather call a real usecase where things go really wrong 'proof' ;)
> 

The entire point of my criticism is that the consumer of an extended 
document just sees arbitrary XML.  It has no knowledge of use cases, of 
what that extension is for.  It just sees foo:bar.  It is a black box.


> > If those N specific 
> > examples can be written using a more targeted extension mechanism, 
then we
> > can get the benefits without the liabilities.
> 
> Hmm, there is an assumption in there where we can properly create 
anextension 
> mechanism for all usecases.
> I notice that in the linked mail you were under the impression that 
nobody 
> uses this feature in the first place. Which turns out to be a 
> misunderstanding, KOffice has used it for years.
> 
> I have given 4 examples where we currently use namespaced extensions in 
my 
> mail 2 days ago.  One is legal, one *may* be made into an extention if 
we see 
> an advantage to that, and two proper and current usecases are not even 
> addressed. Meaning that if we forbid their usage KOffice might have to 
look 
> at not using pure ODF as its native fileformat. That can't be the 
intention.
> 
> Can I ask you to reconsider your proposal based on the new 
> information that we 
> use extentions using namespaces in more than one implementation (I named 
3) 
> already and in a variety of places in the XML tree which defies a clean 
> extention mechanism ?
> 

I'm hoping we can capture the current use of extensions in ODF 
applications on the wiki here:

http://wiki.oasis-open.org/office/Extensibility_Mechanisms

I added some initial items.  Are there other mechanisms used by KOffice?

Once we have a good view of what mechanisms are in use, then we can better 
discuss whether more targeted least-power approaches are more appropriate 
rather than the all-powerful nuclear death ray gun approach.

I know that "least-power" may be unintuitive.  Why would we ever want to 
do something less than the most powerful extension mechanism possible? But 
I think we need to look at power from the perspective of the application 
consuming ODF as well.  The more constrained the extensibility mechanism, 
the more assumptions the ODF consuming application can make, and that 
allows it to make more powerful decisions on how to process the extended 
documents.  We need to balance these concerns.

Regards,

-Rob