Re: [office-comment] ODF 1.2 CD03 2.11.2 <config:config-item-set>

[Jesper Lund Stocholm <4a4553504552@gmail.com>]

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/