[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] spreadsheet table:cell/table:table
Hi Michael, Thank you very much for this. And yes, this will provide necessary clarification for this ambiguity, while still leaving the possibility for future extension/amendment if needed. Best regards, Kohei On Thu, 2007-09-06 at 15:04 +0200, Michael Brauer wrote: > 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 > > > > > > -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <kyoshida@novell.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]