OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[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

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

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]