[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] ODF 1.2 CD03 2.11.2 <config:config-item-set>
Hi Rob, Thanks for your reply, 2009/9/29 <robert_weir@us.ibm.com>: > Jesper Lund Stocholm <4a4553504552@gmail.com> wrote on 09/29/2009 05:04:23 > PM: > >> >> I propose to add the following to the specification: >> >> To 2.11.2 <config:config-item-set>: >> Add the following text: >> >> "The setting elements SHALL not contain settings that impact document >> functionality and SHALL not contain settings that impact document >> layout. Application settings that impact document functionality or >> impact document layout SHALL use the machanisms described in 1.4.5 >> Document Processing. >> > > I don't think that will work. It is untestable. How can I look at a > document and determine whether a given setting element impacts document > layout? You might guess based on the name of the setting. But that is > not really a good test. What if the name is "foo"? But there are quite a few constructs in ODF 1.2 that are not easily testable either. In section 1.4.5 you have "Conforming extended producers should not use foreign elements and attributes for features defined in the OpenDocument schema." This is not easily testable either, but I would not advocate removal of that text. Also, section "19.141 19.141draw:measure-vertical-align" has this text: "The draw:measure-vertical-align attribute specifies the vertical alignment of a measure text relative to a measure line. If the value of this attribute is automatic, the application chooses the best position. The defined values for the draw:measure-vertical-align attribute are: above: below: center:" This is not easily testable either (what's the easy way to test if something is "centered"?). That a feature is not easily testable should imo not restrain you from putting it in the specification. > I think you want to restate this to to be a statement regarding > application conformance, not a statement regarding document conformance. I think it goes two ways. If an ODF producer uses <config:config-item-set>-elements to manipulate document layout and functionality, it should be categorized as an "Extended producer". Similarly, if a document contains <config:config-item-set>-elements that impact document layout or document functionality, it should be categorized as an "extended document". > Also, why the focus on layout alone? Would a setting that causes the > spreadsheet to calculate differently be OK? What if it made presentation > transitions run faster or slower? What if it changes the way the document > prints? I am not only focusing on layout - I have mentioned "document functionality" multiple times. If, say, Microsoft used the <config:config-item-set>-element to mark an ODF Spreadsheet as "leap-year-bug-enabled", then yes, I would certainly regard that document as an extended document - and that provision should be described in ODF. Currently the ODF-spec would allow such a document/application to avoid being labelled as "extended". > Maybe the closest it to say that "A conformant ODF Consumer shall not vary > document semantics and behavior based on the presence or absence of config > items". Similarly for document producers: "A conformant ODF Producer shall not use config items to store information intended to vary document semantics and behavior." I think that goes a long way towards what I am aiming at. Do note, however, that OOo imo would be categorized by this provision as an "extended consumer". > But that might restrict otherwise harmless changes, such setting > the default zoom level in a document editor. What I am trying to say is that the <config:config-item-set>-element is being "abused" by major implementers of ODF, and the most prominent of those is Sun Microsystems in OpenOffice.org. OOo-usage of <config:config-item-set>-element to "legacy-enable" ODF is an example of using the <config:config-item-set>-element as a back door to extend ODF. I know that Sun is a major contributor to ODF, but I believe that the ODF TC should act on this - regardless of who the culprit is. The ODF TC should send a clear message that extensions to ODF _must_ use ODF extension mechanisms and not any backdoor a vendor sees fit to use. I strongly support your new addition to ODF 1.2 to have an "extended conformance class" of documents and applications - but your effort is quite moot if the biggest implementer of ODF uses a back door to extend ODF - and ODF TC does nothing to stop it. Again, thank you for your time. :o) -- Jesper Lund Stocholm www.idippedut.dk SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]