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 Fri, Jul 18, 2008 at 8:54 AM, jose lorenzo <hozelda@yahoo.com> wrote:
> Attributes belonging to the root element can be used to control conformance requirements. There is always going to be disagreement over what should define a conforming app or doc. Why not just let the creator of the document specify the rules for the document (restricted to ODF provisions). You want restriction X or Y on foreign elements? No prob. You don't? No prob. User rulz.
> 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.

> Instead of more top level attributes (along existing ones like office:version) to define the full semantics, the document can use top level elements which themselves could specify through attributes or child elements if the semantics applies to "editing", to opening the document for any purpose, or to specify any other finer grain semantics ("opening" might be considered a special degenerate case of some flavor of "editing").
> As existing analogy, HTML has various "profiles" for conformance(?) and for document interpretation, eg, XHTML 1.0, HTML-trans, HTML 4.0. Here, the interpretation of the document depends on an attribute (if present) specifying which of these three cases defines the rules for the document.
> An extension of this HTML analogy to include "editing" would then correspond to the scenario being described in this email.
> We can apply this principle to many parts of the document, eg, to define conformance or to define something else for any part of the document. Foreign tags is just a particular recurring example on this list, but it's not the only possible use case (foreign tags description is found near the front of the standard and this helps it gets more "hits" throughout debates).
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.

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.

Peter Dolding

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