OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members,


I want to propose to add value "none" to attribute 
style:default-outline-level to indicate that the style has no value for 
this attribute. This will solve the following problem:
Currently, only positive integers are allowed as values for 
style:default-outline-level. Thus, in a ODF document the following style 
constellation can't be expressed:
- Style A is specified to have a default outline level with value 2 
(style:default-outline-level="2").
- Style B is specified to have style A as its parent and to have no 
default outline level.
The problem is, that if attribute style:default-outline-level is missing 
in style B, it inherits the value from its parent style A. Thus, 
attribute style:default-outline-level has to be defined for style B. 
But, in this case currently no appropriate value exists to express, that 
style B has no default outline level.
The new proposed value "none" will solve this problem.


Regards, Oliver.

On Tuesday 20 February 2007 10:38, Oliver-Rainer Wittmann - Software 
Engineer - Sun Microsystems wrote:
> I want to propose to add value "none" to attribute
> style:default-outline-level to indicate that the style has no value for
> this attribute. This will solve the following problem:
> Currently, only positive integers are allowed as values for
> style:default-outline-level. Thus, in a ODF document the following style
> constellation can't be expressed:
> - Style A is specified to have a default outline level with value 2
> (style:default-outline-level="2").
> - Style B is specified to have style A as its parent and to have no
> default outline level.
> The problem is, that if attribute style:default-outline-level is missing
> in style B, it inherits the value from its parent style A. Thus,
> attribute style:default-outline-level has to be defined for style B.
> But, in this case currently no appropriate value exists to express, that
> style B has no default outline level.
> The new proposed value "none" will solve this problem.

The usecase is;

Paragraph Style "Header 1" with style:default-outline-level=1
Paragraph Style "body" has as parent-style "Header 1" but is not a numbering 
style.

Now, I have to ask. Why on earth would you want to have the above construct?
The concept of inheriting styles is that you can change properties in the 
parent and they will change in the child automatically.

Making validation of this field impossible (due to it not being a number 
anymore) needs a bit more justification then a weird usecase that is trivial 
to avoid by any application.
-- 
Thomas Zander

Hi,

see my comments/questions inline.

Thomas Zander wrote:
> On Tuesday 20 February 2007 10:38, Oliver-Rainer Wittmann - Software 
> Engineer - Sun Microsystems wrote:
>> I want to propose to add value "none" to attribute
>> style:default-outline-level to indicate that the style has no value for
>> this attribute. This will solve the following problem:
>> Currently, only positive integers are allowed as values for
>> style:default-outline-level. Thus, in a ODF document the following style
>> constellation can't be expressed:
>> - Style A is specified to have a default outline level with value 2
>> (style:default-outline-level="2").
>> - Style B is specified to have style A as its parent and to have no
>> default outline level.
>> The problem is, that if attribute style:default-outline-level is missing
>> in style B, it inherits the value from its parent style A. Thus,
>> attribute style:default-outline-level has to be defined for style B.
>> But, in this case currently no appropriate value exists to express, that
>> style B has no default outline level.
>> The new proposed value "none" will solve this problem.
> 
> The usecase is;
> 
> Paragraph Style "Header 1" with style:default-outline-level=1
> Paragraph Style "body" has as parent-style "Header 1" but is not a numbering 
> style.

What do you mean by "Paragraph Style being a numbering style"?
> 
> Now, I have to ask. Why on earth would you want to have the above construct?
> The concept of inheriting styles is that you can change properties in the 
> parent and they will change in the child automatically.

The concept of inheriting styles also includes the feature of overriding 
properties of the parent style in the child style.
Thus, I've made this proposal. In the current specification attribute 
style:default-outline-level can't be overriden as any attributes can be 
overriden.
For example think of attribute style:list-style-name:
- Style A is specified to have a list style applied 
(style:list-style-name="L1").
- Style B is specified to have style A as its parent and to have another 
list style applied. Here you can specify that style-list-style-name="L2" 
at Style B.
- Style C is specified to have style A also as its parent and to have no 
list style applied. Here you can specify that style-list-style-name="" 
at Style C.
Thus, why do you disagree to my proposal to have this possibility for 
attribute style:default-outline-level, too?

> 
> Making validation of this field impossible (due to it not being a number 
> anymore) needs a bit more justification then a weird usecase that is trivial 
> to avoid by any application.

Sure you can. But, this should be specified also in the ODF 
specification. Because otherwise you can't assure that this is avoided 
in future applications supporting ODF. Thus, you would have something 
special for a certain attribute, which isn't needed, if you would 
support my proposal.



Regards, Oliver.

Morning Oliver.

On Wednesday 21 February 2007 10:29, Oliver-Rainer Wittmann - Software 
Engineer - Sun Microsystems wrote:
> Thus, why do you disagree to my proposal to have this possibility for
> attribute style:default-outline-level, too?
Simple;
ODF isn't a math specification, the spec doesn't have to be 100% 
self-consistent.
ODF should be driven by need of users, not need of the programmer to express 
any and all structure in it.

> > Making validation of this field impossible (due to it not being a number
> > anymore) needs a bit more justification then a weird usecase that is
> > trivial to avoid by any application.
>
> Sure you can. But, this should be specified also in the ODF
> specification. Because otherwise you can't assure that this is avoided
> in future applications supporting ODF. 

What part needs clarification?

> Thus, you would have something 
> special for a certain attribute, which isn't needed, if you would
> support my proposal.

Ehm, now you are confusing me; you are the one that wants to introduce 
something special for a certain attribute. Based on the logic that a numeric 
item is the same thing as a reference to another item in the file.
I'm confused how you can say that these two things are so similar that they 
need the same behavior.
-- 
Thomas Zander

Thomas Zander wrote:
> Morning Oliver.
> 
> On Wednesday 21 February 2007 10:29, Oliver-Rainer Wittmann - Software 
> Engineer - Sun Microsystems wrote:
>> Thus, why do you disagree to my proposal to have this possibility for
>> attribute style:default-outline-level, too?
> Simple;
> ODF isn't a math specification, the spec doesn't have to be 100% 
> self-consistent.

But in this case, it can be easilier achieved with my proposal.

> ODF should be driven by need of users, not need of the programmer to express 
> any and all structure in it.
> 
>>> Making validation of this field impossible (due to it not being a number
>>> anymore) needs a bit more justification then a weird usecase that is
>>> trivial to avoid by any application.
>> Sure you can. But, this should be specified also in the ODF
>> specification. Because otherwise you can't assure that this is avoided
>> in future applications supporting ODF. 
> 
> What part needs clarification?
>
If my proposal will be rejected, it should be clarified, that
applications, which support ODF, don't support the use case I've described.

>> Thus, you would have something 
>> special for a certain attribute, which isn't needed, if you would
>> support my proposal.
> 
> Ehm, now you are confusing me; you are the one that wants to introduce 
> something special for a certain attribute. Based on the logic that a numeric 
> item is the same thing as a reference to another item in the file.
> I'm confused how you can say that these two things are so similar that they 
> need the same behavior.

No, it isn't something special. Please consider my given example. I'm
proposing the same for attribute style:default-outline-level as for any
other attribute, e.g. style:list-style-name.
I can change my proposal: Instead of introducing new value "none" for
style:default-outline-level, I can propose new value "0". Then all
possible values of style:default-outline-level are numeric, which you
seem to prefer. Thus, the value type of style:default-outline-level will
be nonNegativeInteger instead of positiveInteger.



Again, can you please answer my question, what do you mean by "Paragraph
Style being a numbering style"?


Regards, Oliver.

Thomas Zander wrote:
> Morning Oliver.
> 
> On Wednesday 21 February 2007 10:29, Oliver-Rainer Wittmann - Software 
> Engineer - Sun Microsystems wrote:
>> Thus, why do you disagree to my proposal to have this possibility for
>> attribute style:default-outline-level, too?
> Simple;
> ODF isn't a math specification, the spec doesn't have to be 100% 
> self-consistent.

But in this case, it can be easilier achieved with my proposal.

> ODF should be driven by need of users, not need of the programmer to express 
> any and all structure in it.
> 
>>> Making validation of this field impossible (due to it not being a number
>>> anymore) needs a bit more justification then a weird usecase that is
>>> trivial to avoid by any application.
>> Sure you can. But, this should be specified also in the ODF
>> specification. Because otherwise you can't assure that this is avoided
>> in future applications supporting ODF. 
> 
> What part needs clarification?
>
If my proposal will be rejected, it should be clarified, that 
applications, which support ODF, don't support the use case I've described.

>> Thus, you would have something 
>> special for a certain attribute, which isn't needed, if you would
>> support my proposal.
> 
> Ehm, now you are confusing me; you are the one that wants to introduce 
> something special for a certain attribute. Based on the logic that a numeric 
> item is the same thing as a reference to another item in the file.
> I'm confused how you can say that these two things are so similar that they 
> need the same behavior.

No, it isn't something special. Please consider my given example. I'm 
proposing the same for attribute style:default-outline-level as for any 
other attribute, e.g. style:list-style-name.
I can change my proposal: Instead of introducing new value "none" for 
style:default-outline-level, I can propose new value "0". Then all 
possible values of style:default-outline-level are numeric, which you 
seem to prefer. Thus, the value type of style:default-outline-level will 
be nonNegativeInteger instead of positiveInteger.



Again, can you please answer my question, what do you mean by "Paragraph 
Style being a numbering style"?


Regards, Oliver.

On Tuesday 20 February 2007, Thomas Zander wrote:
> The usecase is;
> 
> Paragraph Style "Header 1" with style:default-outline-level=1
> Paragraph Style "body" has as parent-style "Header 1" but is not a numbering 
> style.
> 
> Now, I have to ask. Why on earth would you want to have the above construct?
> The concept of inheriting styles is that you can change properties in the 
> parent and they will change in the child automatically.

The concept of inheriting styles is also that the derived style can override any attribute
of its parent. Otherwise it's just an alias, not a derived style ;)

For many other attributes we already have a way to model "the parent wants 

On 21/02/07, David Faure 

Dave Pawson wrote:
> On 21/02/07, David Faure