OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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]