Re: [docbook] DocBook Technical Committee Meeting Minutes: 18 Mar2003

[Tobias Reif <tobiasreif at pinkjuice dot com>]

Jirka

I'll address your concerns, but since most has been said already, and 
since the discussion since some days has already evolved from 
"inclusion: yes/no" to "include the table model of XHTML Strict or that 
of Transitional", this will be my last post about "inclusion: yes/no".

I don't think it makes sense to repeat everything. At this point, we 
have to agree to disagree.

> I'm asking again. Is this mental gymnastics really so hard?

Hard enough to matter.

> I trained
> many people with former HTML knowledge to DocBook, and they hadn't
> problems with tables. Is it really so hard to absorb few easy rules?

Learning the CALS table model is described by you as sufficiently easy, 
but is very likely to be harder than learning the (X)HTML table model.

And since HTML is extremly popular and very widely used, many web 
developers getting started with DocBook wouldn't need to invest *any* 
time in learning how to use tables in DocBook. Zero.

This will help increase the further proliferation of DocBook.

> I personally think that allowing HTML tables together with CALS tables
> will confuse users. Ordinary users are always confused when they are
> supposed to make decision. Should we make this even harder for them?
> XML
> vs SGML, DSSSL vs XSL, lists inside para vs list between para, HTML vs
> CALS, ... I don't want to take part in this forking ride.

Exactly, forking is bad.

Many users want to use XHTML tables with DocBook. Creating yet another
additional version of DocBook would increase confusion and harm 
interoperability, as will forking done by users (locally extending the DTD).

Incorporating the XHTML table model will avoid these problems.

Regarding another point you raised in a previous post:
AFAICS, the question "Users vs. Implementers" doesn't pose itself.

Making life easier for users is top priority.

But in this case, there is no trade-off to be made. Why go with 
something that's easy to learn and write (which isn't really the case 
IMHO) and quite hard to process and implement, when there's a good 
alternative which is easy to learn and write, *and* easy to process and 
implement?
The designers of XML understood this, and the strategy pays off bigtime. 
If something is easier to implement it can grow faster, and more and 
better implementations are available sooner for less $s. And often, 
users need to become (ad-hoc) implementers themselves, for example when 
DocBook is to be converted to some in-house custom format. If something 
becomes easier to implement (eg SGML to XML, CALS tables to XHTML 
tables), users will profit, directly and indirectly.

Making life easier for users always is top priority.

If the XHTML table model would be included in DocBook, and the CALS 
table model would still be there, then users (companies, user 
communities, ad-hoc/in-house/beta tools, etc) could limit themselves to 
a proper subset, being DocBook (including XHTML tables) minus CALS tables.

> To sum it up just for the record (as it seems to me that everything
> indicate that HTML tables will be incorporated into DocBook): I'm
> against adding HTML table model to DocBook.

Alright, let's agree to disagree :)

Tobi

--
http://www.pinkjuice.com/