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: Re: [office] The Rule of Least Power


On Thursday 12. February 2009 17:02:30 ext robert_weir@us.ibm.com wrote:
> 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.

Hehe, maybe thats the way forward then :)
I mean, feel free to propose an extension mechanism that fits IBM better than 
any of the current ones ODF already has.
I'm not sure I follow your argument that its not worth writing information at 
all because there is a chance of it being lost, but if you think thats 
important for IBM, then please do suggest a good extention mechanism.

I'd like to point out that this this is a completely separate issue from 
taking away an existing extention mechanism thats native to XML. Adding 
properties and attributes in a namespace.
I don't think we should try to label implementations that choose one way of 
extending ODF over another as more pure or not. Thats not helping anyone and 
its just fooling ourselves into a sense of false security.

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.

-- 
Thomas Zander

This is a digitally signed message part.



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