RE: [oic] Re: Potential Header Rows/Columns Advisory

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

If you know how to do it in BNF, you know how to do it in RNG also.  The cure is not unlike the cure to the dangling-else problem in ALGOL 60, Pascal, and some other languages.

The current schema for patterns table-columns-and-groups and table-rows-and-groups is clearly junk.  RNG allows ambiguity that make no difference, and some of the ambiguity in the patterns doesn't matter (e.g., where a table-rows-no-group ends and an immediately-following table-rows-no-group begins in the case where there are <table:table-row> elements that could be in either pattern).

That the schema allows multiple occurrences of <table:table-header-rows> and <table:table-header-columns> practically everywhere is simply silly and while it requires care to fix, it can be fixed.  And a schema-validation assessment tool can check it.

There are some very odd statements in the ODF 1.0 specification, as if they came from documentation for a non-XML format.  

There is mention of overlaps that are not possible.  It might also be a confusion with the usual way that header rows are identified in page layout / print ranges dialogs, since those don't know about grouping, just rows.  (If you look at Format | Print Ranges | Edit | Rows to repeat, you'll see what the incorrect inference of header print range is for the Customize and UnspanTest of my little test files for CalcGroupHeaders.  These are not carried anywhere.  In those documents, it was inferred from where <table:table-header-rows> <table:row> children were found.  

An obvious remedy would be to say that such header-rows or header-columns should be treated as if they are merely table-rows/-column elements if headers are not supported or headers are not supported where the header elements appear.  Also, the consideration of that particular dialog should not creep into a definition of the file structure as produced.

That seems like appropriate clean-up for the ODF TC.  An advisory could anticipate that, of course. 

 - Dennis

-----Original Message-----
From: oic@lists.oasis-open.org [mailto:oic@lists.oasis-open.org] On Behalf Of Andreas J. Guelzow
Sent: Saturday, October 08, 2011 09:01
To: dennis.hamilton@acm.org
Cc: oic@lists.oasis-open.org
Subject: [oic] Re: Potential Header Rows/Columns Advisory

On Sat, 2011-10-08 at 08:59 -0600, Dennis E. Hamilton wrote:
> I think the note on schema precedence means what it says. In cases
> where there is contradiction between the text and the schema, the
> schema is considered authoritative.  It has to do with a determination
> required in the case that there are separated files in the way ODF has
> the schema separate from the text.
> 
> Let's assume that the text has precedence over the schema.
> 
> Then it strikes me as odd that the schema is so complicated and
> convoluted when a rule is that any specified header rows/columns must
> be contiguous, however they are contained in groups, is easy to
> specify in the schema.

Really? I don't know a lot about writing schemas but I would think that
this is anything but easy.
> 
> It is also probably important to specify that any headers must be for
> the first rows/columns of the table, something that is not said in
> either the schema or the specification, if that is intended.  This
> makes the schema even simpler to specify.

None of the existing spreadsheet applications requires the headers to be
at the beginning of a table, so that is surely not intended.
> 
> It should be possible to specify the schema quite precisely, if that
> is indeed the intention of the specification.

I do not see how that would work.

> 
> It should also need to be said, if that is also the intention, that
> the headers become the headers on all pages independent of their
> contribution from within groups.

That is in fact said:
"If a table does not fit on a single page, table rows that are included
in a <table:table-header-rows> element are automatically repeated on
every page."
No conditions on where those <table:table-header-rows> elements are
given is included in this statement.

> 
> In that case, row groups do not introduce subheadings the way it would
> be in a text document where subheadings change depending on the
> subgroup that the top non-heading row on a page belongs to.  Column
> groups are to be treated similarly, even though it would be meaningful
> to vary the column headings on a row depending on the column-group
> membership of the first non-heading cell in that row on a particular
> given page.

I believe that the use for column and row groups is suppose to be
independent from any header considerations. So header rows/columns are
allowed to be in those groups only because some rows/columns may have
multiple purpose.

> 
> It would seem that the ODF TC should fix this to the extent that the
> behavior is not to be implementation-dependent.  An advisory (not
> 00007) could well express those considerations.
> 

Andreas
-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta


---------------------------------------------------------------------
To unsubscribe, e-mail: oic-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oic-help@lists.oasis-open.org