Re: DOCBOOK: subsetting: excluding CALS table

[Paul Grosso <pgrosso at arbortext dot com>]

At 22:52 2003 03 03 +0100, Tobias Reif wrote:
>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 agree.  But the TC just decided against this.

>> 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 :)

But "including the XHTML table model" while not removing the CALS 
table model and still only having one DocBook DTD implies allowing
both kinds of tables in a document.  Which is just what I was
suggesting but that didn't make it through the TC.  So as things
stand now, it's not going to happen.

>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.

That's not an advantage for users, especially those with existing
docbook documents!  While I appreciate your point about tools and
implementors (I'm an implementor too), it is generally more important
to make users life easier, not implementor's lives.  That's why I
think we should allow both kinds of tables.

paul