Re: DOCBOOK: XHTML tables

[Jirka Kosek <jirka@kosek.cz>]

Tobias Reif wrote:
> 
> Jirka Kosek wrote:
> 
> > Yes RNG is cool, but tool support is very bad. Yes there are free
> > validators, free converters from and to DTD and WXS, but no XML editors
> > capable of RNG guided editing.
> 
> I did not suggest to switch to RNG for the main normative schema. I

How then you want to distinguish between CALS/HTML model, if many
element names are same (table/tbody/thead/tfoot)?

> >>DTD is not very powerful; it always has to be combined with other means.
> >>
> > DTD has enough power to describe document based formats like DocBook or
> > HTML. DocBook is there for 10 years and DTD was sufficent for its use.
> 
> Then it sure will be no problem to add XHTML tables to the DocBook DTD.

Will be, as DTD doesn't have context aware content models feature of
RNG.
 
> > And these users are also familiar with HTML inline markup, with HTML
> > lists markup and ... If someone wants to use HTML, he can use HTML. If
> > some wants to use DocBook, he can use DocBook.
> 
> Many want to use Docook plus XHTML tables. Not very difficult to
> understand. Just as they want to use DocBook plus SVG (see the SVG
> Module [1] (also HTML Forms Module, MathML Module); would you tell them
> to use SVG instead of DocBook + SVG?

With respect this is quite misleading. There is no alternative for SVG
and MathML in DocBook. But there is very good alternative for HTML
tables in DocBook.
 
> AFAIK, CALS is very complex to write and process ("messy" in your
> terms), and has lots of presentational features, which don't belong in
> DocBook IMHO. Adding XHTML tables would make DocBook authoring and
> processing simpler; nothing messed up.

CALS - very complex to write and process? Sorry I don't understand. If
you stick to OASIS Exchange Table Model
(http://www.oasis-open.org/specs/tm9901.html) which is proper subset of
CALS proposed for future versions of DocBook you will get table model
which is almost equivalent to HTML tables. There is row instead of tr,
and entry instead of th/td. Trying to look at HTML and CALS from longer
distance it seems to me that row/entry is even much more selfdescriptive
then tr/td/th.

Only significant difference between CALS/HTML is a way in which colspans
are specified. In CALS you must name columns and then use namest/nameend
attributes on entry. This may seem at the first glance as a more
complicated than specifying number of columns to span via colspan. OTOH
namest/nameend is more robust when you are adding or deleting columns.
Number of columns will change, but labels will remain untouched.

I think that CALS (and I'm talking about their OASIS subset all the
time) aren't more
complex to write than HTML. On processing side there are ready to use
templates to get from CALS to HTML and FO (e.g. part of DocBook XSL).
What more you want?
 
> > If someone needs some capabilities of DocBook stylesheets (like
> > chunking) and he wants to use HTML at the same time, he create something
> > like HTMLBook. HTMLBook can contain elements like book, article and
> > chapters which can have almost same content model as body element in
> > HTML.
> 
> Now you are proposing to create a new language, which you rightfully
> argued is to be avoided.

I argued against forking DocBook as I'm quite involved in this document
type. But if someone wants features known from DocBook and at the same
time he wants utilize his HTML knowledge to maximum, why not create
something built on top of HTML? I will not use it, I'm quite happy with
current DocBook state. But I understand that many people know HTML, so
why they don't create their own DTD based on HTML?

<skipping> 
> You wrote
> 
> "And as there will be more and more WYSIWYG editing tools even in
> open-source and free shops, there won't be such loud noise against CALS
> in favor of HTML. "
> 
> which clearly labels all arguments for HTML tables as "noise".
</skipping>

> Many much-respected members of the XML and DocBook communities argued
> for inclusion of HTML tables in DocBook. (see quotes in the other posts)

I will say that many of them consider this, not argued. At least this
way I understand their words.

If I understand your point, you are proposing to add HTML tables because
they are easier to author than CALS ones? Then may I ask you, how many
people using DocBook do you know and how many people you trained in
using DocBook?

I'm doing commercial DocBook training and I'm also teaching basics of
DocBook as a part of my XML course at university. Till today I think
that I had something between 100-200 DocBook students. They had many
problems with DocBook markup and its "philosophy", with processing and
so on, but CALS tables wasn't problem at all. Just tell them, use <row>
instead
of <tr>, <entry> instead of <th/td> and surround it with <tgroup> with
column count. This is very easy to understand, I don't see any
complexity in CALS here.

If you are speaking from position of implementor who has some problems
processing CALS tables (yes, getting colspec from namest/nameend isn't
trivial) I'm sorry but I can't take this into account. Computers and
technolgies in general should serve to their users not to their
developers.
 
> Discussing the options, and listening to users and implementers is
> better than calling their arguments "noise", and doing nothing but
> hoping for this "noise" to stop.

Please stop this "noise" war. If you feel offended by my usage of word
noise, then please accept my hearty appologies. This wasn't mean that
way.

I perceive DocBook DTD as very fundematal and import thing. For reasons
which I tryed to explain in this and previous e-mails, I still see
adding HTML tables as contraproductive. And I think that it will bring
more confuse to users compared to profit of few users who don't want to
learn three new elements tgroup/row/entry. I always try to lower entropy
and disambiguate things as much as possible, but adding HTML tables goes
in a completely opposite effort.

Of course you may have different different opinion. This is you right.

<grin>But remember, I can always spend 250 USD reserved for holidays as
annual OASIS fee and vote against adding HTML tables!</grin>

					Jirka

-- 
-----------------------------------------------------------------
  Jirka Kosek  	                     
  e-mail: jirka@kosek.cz
  http://www.kosek.cz