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

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

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

> > 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.
> 
> Sure, but currently no spreadsheet implements that, and certainly if one
> spreadsheet application implements such a feature, we can consider
> adding it to the ODF when that happens.

Suppose some spreadsheet implementation such as Gnumeric would want to
implement it, and Gnumeric were to use ODF as its default file format
(how unlikely that may be), then disallowing or removing subtables from
spreadsheet tables in ODF would force Gnumeric to use foreign elements
instead. I doubt that to be a better solution (in respect to
interoperability).

Andreas

> 
> Maybe my use of "disallow" was inappropriate.  How about exclude it from
> the RNG schema definition?
> 
> > 
> > > 
> > > 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.
> 
> Yes, but in what form exactly?  If I were to implement a subtable within
> Calc, for instance, I would have a hard-time deciding how such subtable
> should behave.
> 
> > 
> > >   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.
> 
> I think you are misunderstanding my point, and again, the term
> "disallow" may have bee inappropriate.
> 
> Haivng said that, certainly each application can its own extension
> feature, and use a foreign tag to implement it.  But the issue I'm
> raising is that the ODF spec currently is explicitly allowing a sub
> table within a table cell but silient about how it should be
> interpreted.  This leads to each implementation interpreting it
> differently, while each one claiming that it is ODF compliant.
> 
> We can at least defer including a sub-table in the spec until we have
> some idea or concensus of how it should be characterized.
> 
> > > 
> > > 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.
> 
> Is it really no different?  At least with foreign elements, we are
> implying that we don't define what foreign elements do.  But with the
> text-p elements, we are giving the spec reader the illusion that the
> spec explicitly defines what they do, but I'm just questioning whether
> or not that is really the case.

We do know what these mean in the context of a table in a word processor
document. They should mean exactly the same for a spreadsheet document!

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