[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: DOCBOOK: subsetting: excluding CALS table
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]