[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] spreadsheet table:cell/table:table (was: [office]OpenDocument TC coordination callminutes 2007-08-13)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]