Re: [oiic-formation-discuss] Support the user with diverse ODF provisions

[jose lorenzo <hozelda@yahoo.com>]

--- On Fri, 7/18/08, Peter Dolding <oiaohm@gmail.com> wrote:

> From: Peter Dolding <oiaohm@gmail.com>
> Subject: Re: [oiic-formation-discuss] Support the user with diverse ODF provisions
> To: hozelda@yahoo.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, July 18, 2008, 3:54 AM
> On Fri, Jul 18, 2008 at 8:54 AM, jose lorenzo
> <hozelda@yahoo.com> wrote:
> > Attributes belonging to the root element can be used

Before going further.. Dave provide a link to OpenFormula earlier: http://wiki.oasis-open.org/office/About_OpenFormula . The section titled "Need for Subsets and Supersets" is particularly relevant to this current discussion. It's easy to read and may preempt some amount of argument.

> > For example, an attribute
> preserve-foreign-content="true" can require
> conforming apps "editing" the document to keep
> all standard elements within a foreign tag.
> preserve-foreign-elements="true" can signify that
> everything be kept.
> 
> Sorry that does not answer the issue of foreign-content.  
> If I edit a
> document I can have altered things around foreign tags.  
> Preserving
> them can equal rendering errors.  As a implementer current
> state of
> mess only option so document renders right to the best of
> my knowledge
> right is delete them.  If you don't somehow answer the
> workable state
> they will be deleted.

Deleting (foreign element, children, and other content) or not can do a worse job depending on circumstances. This is very variable.

We can add support by standardizing attributes or other mechanisms that allow the extension creator to communicate how the extension might best be handled by apps that don't understand the extension.

Independent of this guidance, the user can want to keep docs free of foreign content entirely or will want extensions but have a preference for how to treat various extensions it doesn't implement.

We should allow for both possibilities and standardize as much as possible to allow for more intelligent handling.

> Be a web developer for a while you are just talking about
> the most
> hated feature of the w3c specs.
> 
> Dividing the spec like that makes everyone's life
> harder it adds more
> verification to the process.  It causes programs to having
> to alter
> engine more to cope with the extra types.   Basically all
> round bad.
> Better is better designed format.

A major issue I see is do we allow for and organize around widely varying capabilities among apps; or instead do we greatly limit possible variations (eg, no or few extension capabilities) or just allow for them but without much regulation at all (eg, the current ODF 1.1 approach)?

I think we should take the first approach. It's challenging, but that is what life is about. Someone will always strive to meet challenges users want addressed. Will we and at what pace?

A simple app can support just a particular mode or feature. More complex apps (ie, the more featureful ones) will implement the alternative handling methods or will know to resort to plugins to co processes that can handle the alternatives.

The most featureful apps will always implement lots of stuff. If you don't standardize as many paths as possible, then it means you can't have interoperable competition in this category of most featureful apps. In practice, many features will be implemented, including many things that were ignored, left underspecified, or even ruled out by the standard.

In the case of ruling out a major use case, we would be making a big mistake with ODF if we do this. And that's just what we would be doing if we don't allow flexibility with extensions [see first part of this email, above] or if we make having extensions be impractical for the many that will want to do so [see third/last part of this email, below].

If we pick a single use case to win out when there are at least two important conflicting use cases, then ODF will be shooting its own foot in terms of helping it catch on and be relevant since smart competitors to ODF will provide the other side of the coin on almost any issue [if they are really smart, they will provide for both].

I think we should fork to "profiles" or whatever you want to call it whenever we have conflicting items. A simple flag (eg, T/F attribute), can state the rules in play for the document. Featureful apps will implement many such attributes fully (especially since sometimes one of the two options is almost trivial to implement). Less featureful apps will implement a subset, but you would be able to have standardization across those subsets.

If you don't provide a standardized way apps can implement subset features, you will be burned because underpowered apps will come in droves. For good reasons an app can be very useful while only handling a very small subset of ODF. It's incorrect to think that you must implement all aspects of a feature to be useful, or that if you do implement such a small amount, you will inherently give up the possibility for interop.

Generally, wrt ODF 1.1, it would help interop to make sure that as many SHOULDs as possible describe what would already be well-defined standardized alternatives. Have there be a way for whichever of the alternatives would be in play within a document to be clearly known (eg, via a set attribute). In fact, just by standardizing the complementary options, we begin the process of standardizing how these will behave in the wild when an app understands one way but not another.

It's naive to think that useful use cases addressed by the wider market won't (sort of inherently) conflict with other use cases also addressed by the market. A simple example: you can't at the same time both filter foreign tags (entirely or partially) and keep them around. Some use cases will *demand* one way. We can standardize both ways and continue trying to specify (define/standardize) the more challenging interop scenarios. Picking a single winner or ignoring the issue would not be wise.

> You are better to look at the Opengl model.    In
> particular
> http://www.opengl.org/registry/  All opengl
> extensions(opengl equal to
> foreign keys) are listed there with how they work.   Now
> could there
> be sub groups in the registry yes.   This also answers
> anyone who says
> its unworkable.   Large sections used in the opengl
> registry over time
> have moved from one companies creation to the full standard
> because
> its well done.
> 
> We need a merging pattern not a dividing one.   Stuff goes
> into this
> group of foreign keys to be looked at for next version of
> ODF.   So
> there is always just 1 standard  with a set of proposed
> keys/extentions.  Usage of the proposed keys/extensions
> also tests how
> good a idea is 1 company only uses them.  Key will most
> like go on
> being deleted by everyone else.   Now if its good more
> implementers
> will add it for its advantage so the key starts naturally
> living.  Its
> a survial of the fitness bits model.   In the case of
> opengl
> applications using it guide the direction of opengl.  ODF
> could also
> inspect documents people are creating and using to see if
> the users
> are even using the feature.

Managing numbers.

Compared to OpenGL, I imagine ODF will have a lot more people wanting to add extensions to it. Many will even want to keep their extensions private. One reason why more people is that ODF has a wider scope than OpenGL (in fact and in potential). Another reason for the larger numbers is that it is easier to fully implement an ODF extension since it will likely only require software to get the effect you want. A lot more people can write new software than can design and implement new hardware.

Quoting from the link given at the top:
>> Room for innovation by anyone. We define "namespaces" for functions. These allow spreadsheet applications to add new innovative functions, without interfering with current standard functions, future standard functions, or functions defined by other applications. This makes it possible for different applications to innovate without fear, and once a consensus arises about the new function, it can be standardized (combining the ideas of many). What's more, the namespace is based on the Internet's naming service, so you don't need to pay separately to innovate... everyone can innovate! Without this ability, only one supplier could practically create new functions; the result would be a stifling of innovation. The OpenFormula approach creates a whole process for bringing innovation from anywhere in the world, from any supplier, to users.

Specifying the use of DNS names is scalable and inclusive of everyone.. at least to the extent DNS already has these two properties. I think the OpenFormula group is being smart.

A registry such as the one by OpenGL to which you linked looks like an example of what might be a near final step in growing ODF. OASIS may want to deal closely with one or more groups that would provide a catalog where users can submit their own extensions. The OIIC TC might want to explore this. It takes effort to manage such a catalog properly. The market might come up with more than one catalog. Also, other players may provide their own analysis and cleaning out of such catalogs. Perhaps only certain accredited users would be able to submit to the (OIIC?) ODF TC. OASIS may thus be able to provide a somewhat organized and smaller catalog. It would be "quasi" standard.

I think the proposed OIIC should task itself with creating such an environment of groups to manage catalogs of extensions. It would coordinate, accredit perhaps, and serve as a sort of final tier for collating and organizing decent extensions prior to them possibly (but not necessarily) becoming part of a future ODF standard.