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] Support the user with diverse ODF provisions


On Sun, Jul 20, 2008 at 7:46 AM, jose lorenzo <hozelda@yahoo.com> wrote:
> --- 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)?

Its the what you are not seeing.   ODF already have sub sections of a
single standard.  Splinting any more just damages the standard not
improving it.   If something is needed like a profile it should be put
forward as a subsection to the standard.  Following the W3C model is
just a disaster waiting to happen.

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

Extensions private is not workable.  That is that will never change.
If you don't want to document you Extensions expect to get them
deleted from time to time.

> 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.
>
There is a difference between stifling of innovation and having a W3C
mess.  Where implementers forms dift into a incompatible messes.
Critically thing how will other programs be able to process there
addons right?  If people can add undocumented stuff they will.  Ok
create a schema and tell no one how it works.  Nice now I have vendor
locking for a while.
>
> 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.
>
I come back to the OpenGL model because its worked for years.  Has
seen extensions added by many parties and keeps on working.  A
constant form of evolution.

Anyone looking at a W3C model need to pull there head out sand.   Its
just fragmented and keeps on fragmenting and getting worse.
Treatment has created long lasting vendor lockins and other evils.

Innovator in the opengl model still has the feature first.  Yet if
that feature takes off all the other implementers can create it.
This is the major difference.  Yes in opengl it still pays to the
innovator.  Yet this does not come at the price of vendor lock in.

Also running a catalog of extensions does not need standard alteration
so its something the TC or standard body could decide to do.
Basically if the standard body does not we should.  It all about
improving compatibility between ODF program makers.

Adding tags to say what extensions do requires standard alteration and
most likely not wise either.

Peter Dolding


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