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

[Kohei Yoshida <kyoshida@novell.com>]

On Tue, 2007-08-14 at 12:29 -0600, Andreas J. Guelzow wrote:
> 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.

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.

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.


Kohei