[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: PROPOSAL: Formation of a Central Repository for ODF extensions
Before someone throws up the good old its out side standard we should not care. How are we going to enforce compatibility between standard supporting applications? Does not take much brains to wake up if you can add a non documented extension to ODF you can break compatibility with everyone else applications effectively locking in your market share. Problem this has been done in history with w3c and RTF and others. So currently we cannot truly foster compatibility Now as a TC without central reporting how are we going to go after these abusers. Currently we cannot. Reason we target them they answer you have not target OpenOffice or Koffice either. So there is no way we can enforce this effectively. We have no list of above board extensions to hunt the abuses of standard from. Ie you using something that you have not reported you must be up to something wrong. There is worse standard states clearly you should not create extensions that do exactly the same as what is in standard. How are we going to have to prove this. Waste time reversing the non documented extensions. Not workable. We need central reporting so this is enforceable. Most importantly how are we going to resolve disputes over added keys for features. KOffice and OpenOffice both have there extensions and both complain that the other deletes them. Yet has there ever been a compare between the extensions they add that are different to check for overlap? Most likely no. If you did were could you list the extensions for the rest of the implementers. Currently no where. So we can expect implementer to create and create overlapping extensions and not even have a way to find out. They currently have no option to delete the other parties extensions because there is no way to find out what the extension does to add that feature to there code base. Some implementers will complain about this hard line that it is going to cost time over head and so on. Sorry to say it should not be costing over head if you are truly documenting what you are doing so you application always acts the same. If other Ideas are throw up the following need to be checked against them. 1) Does idea allow all implementers to use extensions developed by other implementers. If no these extensions will most likely get deleted causing bad blood between parities. 2) Does idea allow the TC to go after anyone intentionally breaking compatibility with everyone else. This need to be resolved. There are a lot of valid reasons and need to create one inside the compatibility part of the TC charter. Central Repository of extensions http://opengl.org/registry/ has served opengl quite well blocking fragmentation and infighting even sorting out ideas before they are put upto the standard. It works as a testing ground where each can improve the code. Schemes and other models from w3c have failed to keep standards safe and workable. There are very few open source standards that have been above long term crippling. We don't need to go down the roads of failure again. I will be happy as long as solution safe for the standard is setup. Resisting fragmentation and destruction of standard. Peter Dolding
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]