Re: [docbook-tc] Re: db5: info in HTML Tables?

["Bob Stayton" <bobs@sagehill.net>]

Hi Paul,
OK, the table cell argument is not a good one.  I guess I'm looking at 
DocBook's CALS table markup, and wonder how compatible that is to the CALS 
standard?  The current CALS table element in DocBook 5 contains info, alt, 
textobject, tgroup (or mediaobject), and caption.  Is the CALS table 
standard flexible enough to permit the addition of extra elements like 
this?

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


----- Original Message ----- 
From: "Grosso, Paul" <pgrosso@ptc.com>
To: "DocBook Technical Committee" <docbook-tc@lists.oasis-open.org>
Sent: Monday, November 06, 2006 4:24 PM
Subject: RE: [docbook-tc] Re: db5: info in HTML Tables?


I certainly do not object to adding this to the agenda.

However, I would point out that having non-HTML markup
*within cells* is very different from having non-html
markup elsewhere.  Every table model (and every table
editor UI) always allows "foreign" markup (from the
incorporating DTD) within the table cell, but not
necessarily elsewhere within the table model.

So the fact that other markup is allowed within the
table cell confers absolutely no strength to the argument
that non-HTML markup should be allowed elsewhere throughout
the table model markup.

I don't find the namespace argument particularly convincing
either.  If your basis for allowing other markup within
DocBook's HTML tables is that the elements are DocBook
elements--and therefore have no need to stick to the HTML
table model--then there is no point in saying they are HTML
tables at all.  Invent any markup you want.  But don't
call them HTML tables, and don't expect tools optimized
to work with HTML tables to work with them.

My understanding of the point of allowing HTML tables, as
well as CALS tables, in DocBook documents was three-fold:
(1) existing tables (many of which use such markup) could
more easily be incorporated into DocBook documents,
(2) existing tools/UIs that facilitate working with such
tables could be used to work with such tables in DocBook
documents, and (3) we would be leverage existing knowledge
of such common table models to simplify creation of
DocBook tables.

Changing the (non-table cell content) model of the HTML
table model does not help support either point 1 or 3
and potentially destroys point 2.

paul

> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net]
> Sent: Monday, 2006 November 06 02:14
> To: DocBook Technical Committee; Norman Walsh
> Subject: [docbook-tc] Re: db5: info in HTML Tables?
>
> [responding on the TC list]
> I think we should discuss this issue in the TC.  db.html.table cells
> contain markup that is not part of the content model for
> tables either.
> It is my understanding that DocBook doesn't contain HTML tables, it
> contains some DocBook table elements (in the DocBook
> namespace) that borrow
> local names from HTML tables.
>
> Would anyone object to adding this issue to this month's TC agenda?
>
> Bob Stayton
> Sagehill Enterprises
> DocBook Consulting
> bobs@sagehill.net
>
>
> ----- Original Message ----- 
> From: "Norman Walsh" <ndw@nwalsh.com>
> To: <docbook@lists.oasis-open.org>
> Sent: Saturday, November 04, 2006 1:15 PM
> Subject: [docbook] Re: db5: info in HTML Tables?
>
> / Scott Hudson <scott.hudson@flatironssolutions.com> was heard to say:
> | I noticed that info is not allowed inside the html.table and
> html.informaltable
> | models. Is there a particular reason for this? I think it
> would still be
> useful
> | to track metadata on html tables, even if there isn't any
> information you
> would
> | print from them as part of display.
> |
> | cals.table and cals.informaltable both allow info.
>
> They aren't allowed because they aren't part of the content model
> for tables in HTML.
>
>