Re: [office] OpenDocument TC coordination call minutes 2007-08-13

["Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca>]

On Tue, 2007-14-08 at 11:24 -0400, Kohei Yoshida wrote:

> > Right now, the specification allows an implementation to place a table 
> > in a cell of a spreadsheet (anyone can see this by looking at the 
> > schema). No implementation that I am aware of currently does this. 
> 
> Right.
> 
> > Basically the specification is saying: "if you want to put a table into 
> > a spreadsheet cell, here's how you do it." or, "if someone has put a 
> > table into a spreadsheet cell, here's how you find it".
> 
> The problem that I see is that, once the table is found within a
> spreadsheet cell, what is the implementer supposed to do with it?


Just because current spreadsheets do not use these possibilities, we
really should not prohibit them. There are people putting pictures
graphs and many other widgets on a spreadsheet. The ability to include
tables inside table cells seem to be a quite natural extension of a
spreadsheet.


> 
> For instance, in a word processor, such element may be interpreted as a
> sub-table, which IMO is appropriate.

Similarly, that may be appropriate in a spreadsheet program.

>   But in a spreadsheet application,
> as I'm not aware of any spreadsheet applications that allow a sub-table
> within a cell (as you correctly said), it may interpret <table:table>
> within <table:table-cell> as an embedded spreadsheet object, or
> something else (like merged cells), or completely ignore it.  If it's
> ignored, should that sub-table element be discarded, retained, or
> alternate text be displayed etc?
> 
> Or, another implementer may convert such sub-table into a simple stream
> of text.  That may be fine too for going one-way, but then we would lose
> round-trip fidelity there.  In the end, this type of broad
> interpretation will lead to degrading interoperability (sorry the magic
> word again ;-).

THe sam issue applies to any otehr feature whether in a spreadsheet of
text document that only some implementations implement.

> 
> My personal opinion is to explicitly disallow sub-tables within a cell
> in the spreadsheet application, instead of leaving how to deal with it
> up to the implementer.  We can then allow it again once we have a more
> concrete definition of what a sub-table should be in the spreadsheet
> context.

Well, explicitly disallowing sub tables within a cell in a spreadsheet
will make pretty much sure that spreadsheets cannot use odf as their
natural format since it would prohibit any innovation on this part. 

> 
> Here is another potential issue that I see.  Because the spec says the
> <table:table-cell> element allows a full set of "text-p" pattern,
> anything that can go into <text:p> can be a valid content of
> table:table-cell.  This means that
> 
> 1) There may be some elements under the "text-p" pattern that need to be
> interpreted differently depending on the application context, and
> 
> 2) when the text-p pattern is expanded to allow more features in the
> word processor context (a likely scenario), it will also affect the
> spreadsheet context too (and vice versa).  But is this side-effect
> expected or desired?

desired...

this is really no diffenrent than allowing foreign elements.


Andreas
> 

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