Re: Feedback on Comment list

[Stefan Nikolaus <stefan.nikolaus@kdemail.net>]

On Monday 04 September 2006 20:58, Michael Brauer wrote:
> Tables: default-cell-style-name interpretation
>
> http://lists.oasis-open.org/archives/office-comment/200607/msg00003.html
>
> This is a clarification request for the "table:default-cell-style-name"
> attribute described in section 8.1.2. The current attribute description is:
>
> "The table:default-cell-style-name attribute specifies a default cell
> style. Cells contained in the row without an individual cell style use
> these default cell style."
>
> There was a long discussion on the user mailing list regarding the
> interpretation of this attribute, and the essential question seems to be
> whether the attribute should be applied to cells that are displayed by
> typical spreadsheet applications (because they usually display sheets as a
> very large/indefinite table), but are not contained in the table stored in
> a file.
>
> Actually, I think that the OpenDocument specification shall only specify
> the behavior for cells that are actually contained in the document. An
> application may of course display more cells, and typical office
> applications usually do so, but it is up to the application to decide how
> to render them. I therefore think that the current description is
> sufficient, because it specifies what happens for cells that are contained
> in the document, and makes no assumptions for others.

The @dcsn is a column/row attribute. In spreadsheet applications these are 
also used to render the cells outside the used area - think cell dimension or 
visibility. The @dcsn should be treated the same way.

> The clarification request further contains the following suggestions:
>  > 1. Split the third paragraph of 8.1 "Basic Table Model", so it becomes
>  > more obvious, that the rendering part belongs to both kind of apps. It
>  > would also increase the readability.
>
> This seems to be reasonable. I propose that we add a paragraph break before
> the sentence that starts with "All other applications typically".

The rendering paragraph I refered to starts actually at "Incomplete rows are 
basically ...".

>  > 2. Clarify, that the spreadsheet loading part refers to the dimension of
>  > the spreadsheet app, not the dimension of the saved doc. It's already
>  > given by 'just like in an empty sheet', but obviously it's not definite
>  > enough.
>
> Actually, the "spreadsheet loading part" always refers to the dimension of
> the saved doc, and never to dimension of the table that is displayed by an
> application. I therefore propose to not change this.

As the loading is described explicitly for spreadsheet applications, it should 
be obvious, that there has to be a difference to other kind of applications. 
And this difference is IMHO the dimension of the table.

>  > 3. The spec should be extended to make use of the brevity approach. E.g.
>  > by introducing two cell attributes "style-columns-repeated"
>  > and "style-rows-repeated". A cell, lying in the repeated range, use this
>  > style, except the cell sets its own. The repeated range belongs to the
>  > used area. This would be even more flexible and brevity comes to its
>  > optimum, because you can define style repetitions starting at an
>  > arbitrary cell instead of being fixed to columns or rows.
>
> This actually is a request for an enhancement. We may consider this for a
> post 1.1 version of OpenDocument

Cell style assignments to whole rows/columns are not possible with the current 
spec as sheet dimensions between spreadsheet apps differ. But these should be 
included sooner or later. If we stay with this odd interpretation, that the 
@dcsn applies to the used area only, we have to add another attribute to the 
row/column (style) element and things will get messed up.
The proposed additional cell attributes could be used to apply a style to the 
used area only, while the @dcsn could be used for cell styles for the whole 
row/column. That was the idea behind the proposal. This would be more 
consistent as all other row/column (style) element attributes are used to 
render also the cells outside the used area (e.g. dimension, visibility). And 
as styles are THE render instructions par excellence, an exception for this 
attribute makes not much sense.
Further the transition to the proposed new attributes should (I don't know the 
code good enough) be not that hard for OO Calc. The style name has to be 
stored in a cell (often the first) instead of in the column/row element.
Also style storage implementations, that store the styles in rectangular 
regions, separately from the cell instances, will benefit from this approach. 
This storage implemention is at least planned for KSpread and is AFAIK 
already used in Gnumeric.

Just my two cents, but I saw, that your proposal was already 
discussed/accepted in the telecon on 2006-08-28.

Regards,
Stefan

PGP signature