[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Re: [docbook-tc] DocBook Technical Committee MeetingMinutes:17 Dec 2002
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC