This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: subsetting: excluding CALS table
Paul Grosso wrote:
>> I think I'd like to disallow CALS, then allow for XHTML table
>> elements table, tr, td, etc, and allow for para, inline stuff,
>> etc inside td; but I'm not sure yet.
>>
> By doing this, you're making incompatible subsets. This worries me.
It should, but there are two separate things being discussed.
If I create an extended version of DocBook (not a proper subset, just
shares an intersection), then this has the obvious drawbacks of
extending languages locally; (other) tools won't know what to expect
etc. It would be a desparate workaround, a (hopefully) temporary hack.
As I wrote, the solution I want is to see the XHTML table model in the
official DocBook language/schmema (DTD).
The CALS table model could be kept for forwards-compatibility of older
content, or it could be dropped if there ever will be a non-compatible
major version, eg DocBook 5.
Elements are being added to DocBook with each version, AFAICS. The XHTML
table model could be added as well. It could be in it's own namespace,
or in DocBook's.
> I think the right answer is to have DocBook augment the DTD so that
> both CALS and HTML tables are allowed.
Fine with me!
(To clarify:
In thread "XHTML tables" I wrote
"I think I'd be much happier with a DocBook which includes the XHTML
table model.", and didn't request exclusion of CALS.
In the other thread I was talking about a local custom DTD for
experimental purposes (processing DocBook+XHTMLTables), where I do want
to disallow the use of CALS tables. (this would be a proper subset of a
hypothetical future DocBook+XHTMLTables))
> Then we avoid the
> incompatible subset issue, existing users can continue to use CALS,
> others can use HTML,
Sounds great! I really hope to see this in an official final DTD soon.
Then, regarding my DocBook to XHTML tool Doxy [1], I could simply write
"CALS tables are not supported, use XHTML tables", without ever having
to mess with some unofficial homegrown schema (DTD) (except perhaps one
that defines a proper subset).
And the code would be infinitely simpler than CALS to HTML code ;)
(just copy the elements with their attributes)
> and you can even mix a CALS table and an HTML
> table in the same document.
Nothing is too far out to be done by some, but I don't think I'd want to
do that :)
Put differently; I could live without this. (mixing both models in one
table)
> (This issue was discussed in the TC, and the rest of the TC
> disagreed with me here, but the fact that users are now pushing to
> make incompatible subsets raises my concerns even more.)
Simply include the XHTML table model in the next version of DoocBook,
and most will be happy I think :)
P.S.
Excluding CALS tables in some future version would have one advantage:
New tools could support 100% DocBook (including tables etc) without
having to deal with the complex CALS table model.
P.P.S.
On Wed Oct 17 2001 Eve L. Maler wrote
"I think DocBook should begin to allow HTML tables anyway..." [2]
and Norm replied
"Yeah. I think I'd be in favor of that, [...]" [3]
Later, Tim Bray said
"And I'm sorry, CALS tables are *right out*. Don't go there." [4]
Tobi
[1]
http://www.pinkjuice.com/doxy/
[2]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0021.html
[3]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0024.html
[4]
http://lists.w3.org/Archives/Public/spec-prod/2001OctDec/0027.html
--
http://www.pinkjuice.com/