Value and danger of extensions

[jose lorenzo <hozelda@yahoo.com>]

In potentially tough competition with rival less open formats, ODF stands to gain by being attractive to market participants. Extensions (like foreign elements) add to this attraction. I anticipate a market of closed as well as open plugins to handle extensions, customizations using extensions, etc. Clearly, many people would like to spin their own creations and useful extensions.

FOSS plays an important role in helping interop by *generally* filtering out extensions and so helping keep most documents in the wild free of most (bad) extensions. Extensions should always be the exception. But note an exception to this: FOSS extensions can be understood by anyone because the implementing source is available. Also, even closed source extensions may come well-documented, thereby increasing interop and the likelihood of surviving or being codified in the future. ODF should always strive to grow by codifying the better extensions as fast as would be wise.

As long as we generally apply filtering, I think FOSS may stand to gain in interoperability by incorporating ODF more into itself. [An example mentioned on this list earlier was to have desktop cut/paste clipboards support ODF. .. +1] ODF is a format richer (comprehensive and integrated) than text and than many other smaller or ad hoc formats. It should be possible (and this needs to be checked and tested) to cleanly use various small ODF subsets. Doing so would increase take up by making ODF more attractive for use cases with limited needs.

Cleaning out ODF language further also would increase the odds of interop. Consider helping the main ODF TC by reviewing ODF 1.0/1.1/1.2-pre for inconsistencies and ambiguous language and posting fixes or suggestions [links to archives, downloads, and email subscription have been posted already on this list.] Also, consider suggesting interesting functionality. And I strongly suggest that anyone interested in helping out should consider spending time to get relatively comfortable with RELAX-NG since it's used by ODF to provide basic and key information not otherwise expressed in the standard. OASIS hosts Relax-ng. See the formal spec, http://www.relaxng.org/spec-20011203.html , an OASIS tutorial, http://www.relaxng.org/tutorial-20011203.html , and an open book titled "RELAX NG: A Simpler Schema Language for XML" (google for the online version or buy).

We have a very powerful tool to help keep the ODF market interoperable. We have the ability to shift resources around in terms of working to tighten the spec or to build in more safeguards as the need arises. In the short-term, with ODF already decent and getting better slowly, a wise use of resources should/could/would be to build useful testing frameworks aimed at helping *those that want ODF to succeed*. Focusing on this group's needs allows time and energy to be saved from building testing aimed at uncooperative groups (since those sorts of tests and framework would be different). Why focus on this group? ..because for the moment, interop is weak, and improving interop among existing players, who are mostly cooperative, helps ODF become attractive sooner. Remember we can shift focus later on. From what I can best tell (after some pain), the ODF and ODF interop teams at OASIS seem willing to support this model of shifting resources to suit the growth
 of ODF (eg, by working effectively to improve existing interop and promote good uses of extensibility).

Remember that interop is desirable for virtually all users/vendors of ODF. The more interop, the better ODF will do against rival less open formats.

There is a downside to extensions. Serious abuse of extensions is possible and would be dangerous to the ODF market. One example of abuse can come from strong backers of rival formats. An embrace/extend strategy, similar to the one being used to fuel positive growth at the edges of ODF and to provide flexibility, can be abused to create chaos in the market, chaos that would help to make competing formats more attractive. We want to fight bad extensions in order to preserve a high level of interop, eg, by filtering aggressively for them from FOSS apps (note that reverse engineering can be useful to the extent it is correct and openly documented). Abuse of extensions is dangerous proportionately to the number of people using tools/API/etc which create or support such undocumented extensions.

Finally, to end on a positive note, extensions are one way to test out and work to incorporate existing formats into ODF. Many FOSS formats with generally useful semantics should be looked at with an eye to eventually standardize these into ODF. This increases interop for everyone (having a single and cohesive standard that is as comprehensive as possible). I sense that many opportunities for unification exist within a typical Linux distro.

The moral of this story: use extensions for good (eg, document ..and open source if possible) and aggressively avoid bad extensions (ie, those that are undocumented properly). Support TC work and market place apps that abide by this guideline.

Thanks to all contributors on this list and elsewhere for making it easier for me to more clearly see the value present in the upside of extensions, relative to their downside, and to see the current value in focusing on cooperation. The engineering side of me always wants to cooperate as much as possible (it's healthier and advancement is quicker), but any skepticism in the user side of me will always rise to the surface to take control. And a quick apology where I may have been too rude or for cases where I emailed the list without taking into account existing archive (eg, I only recently managed to read most emails from June 30 onward).