Re: [office] spreadsheet table:cell/table:table

[Michael Brauer <Michael.Brauer@Sun.COM>]

Hi Kohei,

we have discussed the topic in the last work call, and the 
recommendation was to add information about the fact that spreadsheets 
are not expected to support nested tables to appendix D, which lists 
which parts of the specification are expected to be supported by typical 
applications.

If you name other cell content that may not be supported by typical 
spreadsheet applications, then I think it would be possible to extend 
the note we add to appendix D accordingly.

Best regards

Michael


Kohei Yoshida wrote:
> On Tue, 2007-08-21 at 16:14 -0400, Florian Reuter wrote:
>> I'll take a look at the formula spec.
>>
>> I just want to make sure that we all have the sme understanding of the semantic of tables-in-tables and sub-tables for spreadsheets. 
> 
> That's essentially been my argument as well.  If the element is in the
> schema, then the spec should give at least a rudimentary description of
> what it does, and what it represents, to avoid allowing the implementers
> incompatible interpretations of the same construct.
> 
> As Lars said, there has already been a discussion of using <table:table>
> inside a <table:table-cell> to represent, for instance, in-line matrices
> (which I think is a little stretch BTW, but I won't discuss it here),
> while other people may use the same construct to represent something
> else such as embedded sheet within a cell if an application implements
> such a feature.  And these two applications can be considered
> ODF-compliant because the ODF spec *intentionally* doesn't specify how
> the nested-table is represented.  BTW, the schema suggests that the
> nested tables are recursive.  How would that be used to represent
> matrices?
> 
> And I picked the nested table issue just as an example.  There may be
> similar cases with other elements.  I was just suggesting that we go
> through those elements that are allowed inside <table:table-cell> to
> make sure there aren't any other similar pitfalls like this.
> 
> If the goal of the ODF spec is simply to provide the schema and leave
> out the specifics up to the implementers, then I can't argue with that.
> But I would expect a little more than that from a file format
> specification.
> 
> Just my opinion.
> 
> Kohei
> 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

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