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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

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

--- On Fri, 7/11/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] Value and danger of extensions
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, July 11, 2008, 1:22 AM
> 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.

OK, extensions that are "good" should not be zapped. "Good" is based on documentation/standardization. There may be a central registry approach or lookup to find such documentation.

[aside] .. or ODF might want to standardize a tag/attrib to link with such documentation [Ie, foreign element support might be improved by creating a new tag to link specifically to extension docs. We might even standardize a bit on what those docs should look like or provide if used as a link. Perhaps source code would be one optional requirement for the docs, or ODF might standardize a direct source code link as well.]

Bad tags should be dropped IMO.
> > 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?

There is mileage in some reuse since ODF is better than nothing. After all, why would we be here if ODF were useless? But the power would be in conjunction with ODF incorporating more semantics that currently resides in many specialized formats.

I suspect competing formats are not going to slow down in an effort to out-feature ODF. Unification will be valuable.

> And I strongly suggest that anyone interested in helping
> out should
> consider spending time to get relatively comfortable with
> 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
> 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.

I think the link you provided is what I was looking for. I don't have quick access to my regular desktop, so I tried googling and took a guess. Thanks. I think that's that book I had in mind. .. So its title is simply, "RELAX NG".


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

I think the key would be good vs bad extensions. Filter out the bad only.


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