OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi Lars,

On Tue, 2007-08-14 at 11:57 +0200, Lars Oppermann wrote:

> There are, as you should be aware of, technical possibilities of 
> constraining the schema as to disallow certain contents in certain 
> elements depending on their context. This was not possible when the 
> schema was still specified in a DTD.

(Please bear with me if this is a basic question as I'm certainly not an
XML schema expert.)

So, do I read from your above statement that, now that we are using
Relax NG as the schema language, it is now possible to constrain or
specify different sets of legal child elements of *the same element*
depending on the context?  (it would be great if it is.)

If yes, then I think we should work toward making it explicit in the
spec in some way.  Because in reality, the exact meaning and behavior of
table cells is unfortunately different between word processor and
spreadsheet apps, the spec IMHO should reflect this and be explicit
about this in text.

Even if it's 'no', then we should still put some note about possibly
different interpretation of the legality of the child elements of

On 14/08/07, Kohei Yoshida 

On Tue, 2007-14-08 at 11:24 -0400, Kohei Yoshida wrote:

> > Right now, the specification allows an implementation to place a table 
> > in a cell of a spreadsheet (anyone can see this by looking at the 
> > schema). No implementation that I am aware of currently does this. 
> 
> Right.
> 
> > Basically the specification is saying: "if you want to put a table into 
> > a spreadsheet cell, here's how you do it." or, "if someone has put a 
> > table into a spreadsheet cell, here's how you find it".
> 
> The problem that I see is that, once the table is found within a
> spreadsheet cell, what is the implementer supposed to do with it?


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.


> 
> For instance, in a word processor, such element may be interpreted as a
> sub-table, which IMO is appropriate.

Similarly, that may be appropriate in a spreadsheet program.

>   But in a spreadsheet application,
> as I'm not aware of any spreadsheet applications that allow a sub-table
> within a cell (as you correctly said), it may interpret 

On Tue, 2007-08-14 at 12:29 -0600, Andreas J. Guelzow wrote:
> On Tue, 2007-14-08 at 11:24 -0400, Kohei Yoshida wrote:
> 
> > > Right now, the specification allows an implementation to place a table 
> > > in a cell of a spreadsheet (anyone can see this by looking at the 
> > > schema). No implementation that I am aware of currently does this. 
> > 
> > Right.
> > 
> > > Basically the specification is saying: "if you want to put a table into 
> > > a spreadsheet cell, here's how you do it." or, "if someone has put a 
> > > table into a spreadsheet cell, here's how you find it".
> > 
> > The problem that I see is that, once the table is found within a
> > spreadsheet cell, what is the implementer supposed to do with it?
> 
> 
> 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.

Maybe my use of "disallow" was inappropriate.  How about exclude it from
the RNG schema definition?

> 
> > 
> > For instance, in a word processor, such element may be interpreted as a
> > sub-table, which IMO is appropriate.
> 
> Similarly, that may be appropriate in a spreadsheet program.

Yes, but in what form exactly?  If I were to implement a subtable within
Calc, for instance, I would have a hard-time deciding how such subtable
should behave.

> 
> >   But in a spreadsheet application,
> > as I'm not aware of any spreadsheet applications that allow a sub-table
> > within a cell (as you correctly said), it may interpret 

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).

Andreas

> 
> Maybe my use of "disallow" was inappropriate.  How about exclude it from
> the RNG schema definition?
> 
> > 
> > > 
> > > For instance, in a word processor, such element may be interpreted as a
> > > sub-table, which IMO is appropriate.
> > 
> > Similarly, that may be appropriate in a spreadsheet program.
> 
> Yes, but in what form exactly?  If I were to implement a subtable within
> Calc, for instance, I would have a hard-time deciding how such subtable
> should behave.
> 
> > 
> > >   But in a spreadsheet application,
> > > as I'm not aware of any spreadsheet applications that allow a sub-table
> > > within a cell (as you correctly said), it may interpret 

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.

Kohei