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