This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: [docbook-tc] DocBook Technical Committee MeetingMinutes:17 Dec 2002
- From: Paul Grosso <pgrosso at arbortext dot com>
- To: Jirka Kosek <jirka at kosek dot cz>
- Cc: docbook at lists dot oasis-open dot org
- Date: Wed, 18 Dec 2002 18:00:50 -0600
- Subject: Re: DOCBOOK: Re: [docbook-tc] DocBook Technical Committee MeetingMinutes:17 Dec 2002
- References: <87k7i9ssc9.fsf@nwalsh.com> <87k7i9ssc9.fsf@nwalsh.com><4.3.2.7.2.20021218093308.02031cf0@172.27.10.30>
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