cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Walsh <>
Subject Re: [RT] latest wonderings around W3C land and surroundings
Date Thu, 30 Mar 2000 21:49:14 GMT
/ Mike Pogue <> was heard to say:
| Also, I'm not interested in a point by point rebuttal here, this is just 
| feedback, not an argument against Stefano or anybody else...'nuf said...

Right. I don't want to argue either. But I can't resist making a few
comments :-)

| 1) DocBook requires an O'Reilly book to decode.  And, it's a thick one. 
| It has a large number of
| 	element names (for many different and powerful purposes).  Most of
| 	the tags are used infrequently.  Of course, there's a reason for

I've tried to get O'Reilly interested in doing a quickref, maybe
that would help. Moreover, I should probably make a version of
TDG for the Simplified subset (which has 100 tags instead of 400 :-).

| 2) DocBook is more verbose, and therefore requires more effort, than the
| alternative.
| 	(Tags in DocBook tend to be longer, and more descriptive, as I recall).
| 	Both 1 and 2 argue for a *DocBook lite*, and that's where I went to,
| except
| 	for that pesky feedback I got:

Here I have little sympathy. Arguing for short tag names is like arguing
for short variable names.

| 3) Many of the DocBook tags are unfamiliar to writers, who tend to be
| familiar with HTML,
| 	and not with DocBook.  There doesn't seem to be much additional
| semantic
| 	advantage to choosing different tags, when an HTML tag is essentially 
| 	available that means the same thing.  (e.g. lists, tables, etc.)
| 	Training is less, if it looks a lot like something you already know.

Yep. The real question is what do you do when you need more
structure than HTML offers.

| 4) Most editors don't work with DocBook.  Sorry, but an emacs hack is
| not
| 	sufficient.  Writers (and programmers) tend to stick with a single

Hack? *sniff* :-)

| 5) Any publishing system needs to be able to handle many grammars.  I


| 	Level II view, which is that the whole point is that you can customize
| the
| 	grammar to be specific to *your* needs.  

This works fine until you want to get interoperability across
classes of documents. Then you begin to wish that they had a
common foundation.

| Stylebook (and Cocoon) are interesting to me, because they do NOT force
| an intermediate representation (or, at least they didn't in the past). 
| They associate an input format (grammar) with a processing pipeline, but
| they do not force everything into one format.

DocBook is a lousy choice if you want to model your data (which is what
I interpret "intermediate representation" to imply). Docbook is for
documentation, not modelling.

                                        Be seeing you,

Norman Walsh <>      | Man's sensitivity to little things                 | and insensitivity to the greatest
                                   | are the signs of a strange
                                   | disorder.--Pascal

View raw message