Re: [office] OpenDocument TC coordination call minutes 2007-08-13

[Kohei Yoshida <kyoshida@novell.com>]

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
<table:table-cell> between different application contexts.

But I'm certainly open to discussions about this.

> 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?

For instance, in a word processor, such element may be interpreted as a
sub-table, which IMO is appropriate.  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 <table:table>
within <table:table-cell> as an embedded spreadsheet object, or
something else (like merged cells), or completely ignore it.  If it's
ignored, should that sub-table element be discarded, retained, or
alternate text be displayed etc?

Or, another implementer may convert such sub-table into a simple stream
of text.  That may be fine too for going one-way, but then we would lose
round-trip fidelity there.  In the end, this type of broad
interpretation will lead to degrading interoperability (sorry the magic
word again ;-).

My personal opinion is to explicitly disallow sub-tables within a cell
in the spreadsheet application, instead of leaving how to deal with it
up to the implementer.  We can then allow it again once we have a more
concrete definition of what a sub-table should be in the spreadsheet
context.

Here is another potential issue that I see.  Because the spec says the
<table:table-cell> element allows a full set of "text-p" pattern,
anything that can go into <text:p> can be a valid content of
table:table-cell.  This means that

1) There may be some elements under the "text-p" pattern that need to be
interpreted differently depending on the application context, and

2) when the text-p pattern is expanded to allow more features in the
word processor context (a likely scenario), it will also affect the
spreadsheet context too (and vice versa).  But is this side-effect
expected or desired?

Again, the <table:table> and <text:p> are just two examples I can think
of right now.  There may be other elements that need to be considered as
well.

Kohei