Re: DOCBOOK: Re: [docbook-tc] DocBook Technical Committee MeetingMinutes:17 Dec 2002

[Paul Grosso <pgrosso at arbortext dot com>]

At 23:43 2002 12 18 +0100, Jirka Kosek wrote:
>Paul Grosso wrote:
>
>> Done:
>> http://lists.oasis-open.org/archives/docbook-tc/200212/msg00003.html
>
>> Both models have <thead>, <tfoot>, and <tbody>.  In the HTML case,
>> the content model for each is (tr+) and in the CALS case, the content
>> model for each is basically (row+).  So the content model in the union
>> DTD module for all three is basically:
>>
>>  (tr+ | row+)
>>
>> So that is one point of ambiguity where someone could mistakenly have,
>> say, a thead in a CALS table containing tr+ instead of row+.  I believe
>> this is really the ONLY point of potential content model mixing.
>> 
>> ...
>> 
>> I still feel we would be doing DocBook users a service to allow them
>> to have both CALS and HTML tables in a document, and I do not feel
>> the above issues--which we would prohibit via the documention but
>> could not prohibit via the DTD--are so problematic as to cause us to
>> forbid the use of HTML tables.
>
>The problem is that tr/row ambiguity will confuse also XML editors. They
>will offer you both elements as possible content of thead/tbody.

Well, insofar as the tools don't know/do anything special given
that we're talking about tables, you're right.  But the reason to
use CALS and HTML (as opposed to some arbitrary model)--and one
big reason to allow HTML tables--is because there are tools that
know about these table models.  And if they know about these models,
then they wouldn't get confused.

>Currently there is only one element which many editors will insert
>automatically for you. This is mostly tool issue, but quite important
>IMHO. I'm also not sure whether WYSIWYG editors like Epic and XMetal are
>able to dynamically recognize between CALS and HTML table models.

Epic 4.3 already can handle both CALS and HTML tables in the same
doctype/document, and the table editor does the right thing depending
on what model the current table uses.

>What about adding HTML tables as module similar to SVG/MathML/HTML forms
>module?


The key use case is that people have existing DocBook documents (perhaps
with some CALS tables) but now they have to cut-n-paste some HTML tables
into that document.

Granted, there is no perfect solution in the realm of DTDs, but I think
in the long run, we do users a service by allowing these even if it is
not possible to catch all invalid documents via the DTD.  I expect there
to be tools that do the right thing anyway (as Epic already does).

paul