This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook] DocBook Technical Committee Meeting Minutes: 18 Mar2003
- From: Yann Dirson <ydirson at fr dot alcove dot com>
- To: Jirka Kosek <jirka at kosek dot cz>
- Cc: Norman Walsh <ndw at nwalsh dot com>, Dave Pawson <dpawson at nildram dot co dot uk>,docbook at lists dot oasis-open dot org
- Date: Fri, 23 May 2003 15:41:40 +0200
- Subject: Re: [docbook] DocBook Technical Committee Meeting Minutes: 18 Mar2003
- References: <87of48wxm9.fsf@nwalsh.com> <87u1e2jhuu.fsf@nwalsh.com> <87of48wxm9.fsf@nwalsh.com> <5.2.0.9.2.20030318210126.0271e830@pop3.Nildram.co.uk> <87ptooi8vi.fsf@nwalsh.com> <3E78926A.EF67283B@kosek.cz>
On Wed, Mar 19, 2003 at 04:53:14PM +0100, Jirka Kosek wrote:
> 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.
I'd like to add another point of view. Currently the (X)HTML and CALS
table models may be similar enough in terms of power/flexibility that
it doesn't so much matter which one you chose, you'll be able to tag
your stuff in a similar way.
That is, it is highly possible that most people knowing (X)HTML will
not even look at CALS. So good for now.
Now consider that we may want to extend the table model used in
DocBook, for example to get rows grouping like I demonstrated in
xtable[1]. If we were to add such a feature and others to (X)HTML,
sooner or later that would not be exactly (X)HTML any more, and the
users would possibly get into false expectations. Obviously this
assumes that it is at all reasonable to extend (X)HTML tables within
the scope of DocBook, whereas it is an actively maintained standard
under the aegis of W3C...
Now the latter argument could also be applied the the CALS model. But
IIRC (please correct me if I'm wrong) we already saw an OASIS table
model, which is just the CALS model with a fix wrt "pernicious mixed
content model". This advocates to me that, under the aegis of OASIS,
we could continue to extend our own table model, which we possibly
can't do so easily with an (X)HTML-derived table format without
confusing users.
Then you may ask why not both allowing (X)HTML and an evolving OASIS
table model. But if most users elect to use (X)HTML over CALS/OASIS
for initial markup, then when they realize that their tables would
benefit from such extensions, they would have to do a great rewrite of
those tables, which they wouldn't have needed (or at least would be
far less painful), should they have written it in CALS/OASIS at first.
[1] http://savannah.nongnu.org/cgi-bin/viewcvs/alcovebook/xtable/
Regards,
--
Yann Dirson <Yann.Dirson@fr.alcove.com> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer (dirson@debian.org) Développeur Debian
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org