OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members,

from my point of view the main use case for the "is-subtable" attribute 
is the case, when a certain table cell inside a regular table is splitted.

Think of a table consisting of two columns and 100 rows. If the user - 
for whatever purpose - splits a certain table cell of such a table 
vertically, it is in my eyes more sensible to reflect this split by a 
nested table with "is-subtable" attribute set. In my eyes the user 
doesn't intend to add another column to the table and set the col-span 
of 99 table cell from 1 to 2.

As Andreas J. Guelzow in his mail - see 
http://www.oasis-open.org/archives/office/200706/msg00115.html - already 
pointed out, the tranformation from a table containing a nested table 
with "is-subtable" attribute set to a table build up using row-span and 
col-span can be very 'painful'.


Regards, Oliver.

-- 
=======================================================================
Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - StarOffice/OpenOffice.org
20097 Hamburg
Germany
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
----------------------------------------------------------------------
      Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
                   D-85551 Kirchheim-Heimstetten
                 Amtsgericht Muenchen: HRB 161028
      Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
         Vorsitzender des Aufsichtsrates: Martin Haering

On 09/07/07, Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems


> Think of a table consisting of two columns and 100 rows. If the user -
> for whatever purpose - splits a certain table cell of such a table
> vertically, it is in my eyes more sensible to reflect this split by a
> nested table with "is-subtable" attribute set. In my eyes the user
> doesn't intend to add another column to the table and set the col-span
> of 99 table cell from 1 to 2.

What if your eyes were a problem to you?
If you were using access technology, and ODF said, it's a 'is-subtable' case,
so Oliver can't read it. No problem.

I think perhaps you would object.

If the visual presentation is as the author wants, and people using
access technology
can access the content, then why use a technology solution that only works
for some people?

I don't think ODF should discriminate Oliver. Do you?

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Hi Dave,

Could you elaborate a bit more on the reasons why a nested table is a
problem for access technology? From my (naive) point of view, it would
appear somewhat more confusing to navigate a lot of spanned cells rather
than entering a subtable.

For instance,

A1  C1   D1
A2  C2   D2
A3 B3 C3 D3

seems more confusing than

A1      B1     C1
A2      B2     C2
A3 B3.A1 B3.B1 C3

... because the latter example gives you the context information so you
don't lose the subtable semantics. Especially if there are more than
just 3 columns (see Andreas' example).

It would be much appreciated if you could explain the reasons for the
first representation _always_ being preferable to the second.

Oh, and please don't suggest that we want to discriminate just because
we discuss different options in order to find a good solution. This kind
of polarization isn't helping at all. Thanks.

Dave Pawson wrote:
> If the visual presentation is as the author wants, and people using
> access technology
> can access the content, then why use a technology solution that only works
> for some people?
> 
> I don't think ODF should discriminate Oliver. Do you?


-- 
Sun Microsystems                Lars Oppermann 

On 09/07/07, Lars Oppermann 

On 09/07/07, Lars Oppermann 

On Mon, 2007-09-07 at 18:23 +0100, Dave Pawson wrote:
> On 09/07/07, Lars Oppermann 

On Mon, 2007-09-07 at 17:41 -0500, Richard Schwerdtfeger wrote:
> Lars,
> 
> The bottom line is a blind user is navigating a spreadsheet and when
> you drop in a subtable the reference to the cells does not match the
> underlying header. Blind users use the grid structure and headings to
> maintain a point of reference. When that is not consistent the user
> gets lost. We ran into this problem working with freedom scientific
> and our ODF 1.1 support by the Notes 8 Productivity Editors. The JAWS
> developer, who is blind, got lost and asked that we correct the
> issue. 
> 
> Please see section 3.3 of this document. It is pretty self
> explanatory. Here you will see the use .B2.B1 under a row header of
> C1. The user is lost.

If this is a problem, then the right solution is for the _interface_ to
fix the numbering however is appropriate. 

On the other hand if you drop into a cell that is part of an array
formula in a spread sheet (say the right cell of a pair of cells
containing the result of a LINEST calculation), it is very useful to
know that one is inside an array result, specifically in which cell of
that array one is located. A blind user should probably be warned by the
interface in those circumstances that one is entering a subtable. In
fact every user shoud probably be advised of that fact. Most interfaces
currently let the user guess which cell area makes up the subtable. OOo
for example doesn't even indicate anywhere in which cell of the array
one is currently located.

Andreas

-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

On Mon, 2007-09-07 at 16:15 +0200, Lars Oppermann wrote:
> Hi Dave,
> 
> Could you elaborate a bit more on the reasons why a nested table is a
> problem for access technology? From my (naive) point of view, it would
> appear somewhat more confusing to navigate a lot of spanned cells rather
> than entering a subtable.
> 
> For instance,
> 
> A1  C1   D1
> A2  C2   D2
> A3 B3 C3 D3
> 
> seems more confusing than
> 
> A1      B1     C1
> A2      B2     C2
> A3 B3.A1 B3.B1 C3
> 
> ... because the latter example gives you the context information so you
> don't lose the subtable semantics. Especially if there are more than
> just 3 columns (see Andreas' example).
> 
> It would be much appreciated if you could explain the reasons for the
> first representation _always_ being preferable to the second.

I think we should also point out that the implementation specific
display of split cells in OO creates more problems: If one splits B2
vertically, then moving down from C1 one moves to cells C1->D2->C3->...
That will confuse everybody. But of course the implementation specific
display has little to do with the file format specific storage, which in
my mind should preserve context.

Andreas

-- 
Andreas J. Guelzow, Professor
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

On Monday 09 July 2007 14:30:01 Oliver-Rainer Wittmann - Software 
Engineer - Sun Microsystems wrote:
> Dear TC members,
>
> from my point of view the main use case for the "is-subtable" attribute
> is the case, when a certain table cell inside a regular table is
> splitted.
>
> Think of a table consisting of two columns and 100 rows. If the user -
> for whatever purpose - splits a certain table cell of such a table
> vertically, it is in my eyes more sensible to reflect this split by a
> nested table with "is-subtable" attribute set. In my eyes the user
> doesn't intend to add another column to the table and set the col-span
> of 99 table cell from 1 to 2.

First of all; the user doesn't notice this col-span thing. But he *does* 
notice the sub-table being created as it behaves slightly different, 
especially with regards to cell borders and a11y.
In light of that concept I'm not sure I agree to your assertion. I think 
that if you ask 100 users that you show the resulting document if they 
like the effects of one better than the other, they will not care there 
are 99 rows with a cell that spans 2 columns.
Or, in other words, the internal data-representation of colspans are 
completely irrelevant to users as that is not going to be visible to them 
anyway.  As we can see from KWord1.x and html editing applications like 
Dreamweaver. Which do the colspan thing.

> As Andreas J. Guelzow in his mail - see
> http://www.oasis-open.org/archives/office/200706/msg00115.html -
> already pointed out, the tranformation from a table containing a nested
> table with "is-subtable" attribute set to a table build up using
> row-span and col-span can be very 'painful'.

Naturally, but this is a different thing. Convertion v.s. not creating 
this state in the first place.

Lets be clear;
a) The user action of splitting a cell *can* be completely implemented by 
the ODF-implementation to do col-span / row-span.  And the effect is a 
table that is better for accessibility and give better compatibility with 
other word processors.  The latter because things like borders are rather 
weird and cumbersome to apply and render when using a subtable. Html 
can't do it, for example. How about MSWord?

b) I heard there are valid use-cases for a sub-table (Sudoku!). It doesn't 
have to go away.

So, in the end, any application that aims to be interoperable and friendly 
for accessibility should do splitting of cells based on cell-spanning.
-- 
Thomas Zander