Re: [oiic-formation-discuss] Value and danger of extensions

["Dave Pawson" <dave.pawson@gmail.com>]

2008/7/11 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.


Downside. Currently, for content (not metadata), applications are not
required to pass on your extension.
So Vendor X sees your extension code, zaps it and writes the file back to disk.





> 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.

Like most loose formats, ODF is basically the xhtml element set. Hx p
list table. I'm unsure if there's much mileage in this Jose?



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).

I found http://books.xmlschemata.org/relaxng/page2.html very good,
although the paper version is better for reference.
The schema is possibly the worst part of ODF IMHO.



>
> 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

+1




>
> 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


'Filtering aggressively'? To which the reaction might be, OK, I'll
dump all your extensions.
I've heard the view that this is happening Sun to Koffice IIRC. I
don't think it's a good trend.



> 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.

+1. Best use of extensions.
The next step is to feed back to the main TC that 'I like extension
xyz' to the main TC and suggest
adoption.

regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk