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] OpenDocument TC coordination call minutes 2007-08-13

On Wed, 2007-08-15 at 10:37 -0600, Andreas J Guelzow wrote:
> On Tue, 2007-14-08 at 15:14 -0400, Kohei Yoshida wrote:
> > > 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.
> Suppose some spreadsheet implementation such as Gnumeric would want to
> implement it, and Gnumeric were to use ODF as its default file format
> (how unlikely that may be), then disallowing or removing subtables from
> spreadsheet tables in ODF would force Gnumeric to use foreign elements
> instead. I doubt that to be a better solution (in respect to
> interoperability).

I was referring to removing from the "specification", not from the
"application".  I think there is still a confusion here.

Of course the individual application can use whatever tags they want to
use to implement innovative features, going well beyond the spec.  But
IMO, the purpose of a specification is to ensure that what's specified
in the spec is followed by the spec-conforming applications (the common
denominators that are agreed upon between different implementations).  I
don't think it's the role of a specification to predict into the future
and try to be inclusive of any elements that may be implemented by some
application at any point in the future.

So, if Gnumeric wants to implement a sub-table, it can do that.  And
perhaps then, we will have a reference implementation for the concept of
subtables, which will allow us to work toward specifying it in the spec.

> > > 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.
> We do know what these mean in the context of a table in a word processor
> document. They should mean exactly the same for a spreadsheet document!

Then let's put that in text and make it explicit.  When I first read the
section, I had my doubt about this, and I am not alone; there are at
least few others (who are not on this TC) who share the same uneasiness
with such ambiguity of the spec, and are forced to read between the
lines to interpret the intention of the spec.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]