RE: DOCBOOK: Re: On the size of DocBook...

[Peter Ring <pri at magnus dot dk>]

IMHO, at least three different issues are at stake here:

 - how to make DocBook easier to learn initially
 - how to make DocBook applicable for a wider audience
 - how to keep development of DocBook and DocBook applications manageable

The DocBook DTD is already a prime illustration of how parameter entities
can be used to model classes of elements, and how to make a large DTD
customizable. And TDG is pretty explicit about how different elements relate
wrt. how they should be used.

When we talk about 'useful subsets of DocBook',  my primary concerns would
be:

 - how to make the first 30 minutes with DocBook a pleasure
 - how to make development of new appliations (say, another/better CSS) less
daunting

Proper subsetting and extending will, IMHO, require some form of
architectural forms, some formal concepts about how and why e.g. an element
is a specialization of some other elements. Look to DITA [1] for
inspiration.

Subsetting for "success within 30 minutes" and "easier application
development" could be done in lot less ambitious fashion; it's not
inherently tied to how the elements architecturally relate.

When Samuel Morse wanted to find out how to optimally encode letters, he did
so by counting the number of letters in sets of printer's type. The exercise
of presenting an 'optimal' initial subset of DocBook is similar. 

If we measured the frequency of different elements in different genres of
DocBook documents, we'd get a pretty good indication of the sequence in
which a novice might need to learn these elements. And the sequence in which
an application developer must provide useful results.

[1] http://www-106.ibm.com/developerworks/xml/library/x-dita1/

kind regards
Peter Ring


-----Original Message-----
From: Norman Walsh [mailto:ndw@nwalsh.com]
Sent: 7. september 2002 01:04
To: Adam Turoff
Cc: docbook@lists.oasis-open.org
Subject: DOCBOOK: Re: On the size of DocBook...


/ Adam Turoff <ziggy@panix.com> was heard to say:
|On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote:
|> Quite. Hard that is. And it would introduce N! different "DocBooks".
|> How easy would that be to explain?
|
|I thought it would be difficult.  How would I explain N! DocBook DTDs?
|Well, they're all subsets of the main DocBook DTD.  :-)

Suppose there are subsets A, B, and C of DocBook, D. You might want

 D
 A
 A + B
 A + C
 A + B + C
 B
 B + C
 C

Actually, now that I consider more closely, I guess it's (N-1)! because
if A is the core then we'd really get:

 A
 A + B
 A + C
 A + B + C

it wouldn't make sense to have B or C w/o A and presumably D is A + B + C.

| I suspect it wouldn't be difficult at all.  Most of that work is
| already done in TDG.  Identifying the most important core 25-50
| elements might be a little tricky,

I tried to identify the core 25-50 elements, I wound up with more than 100.
Start with 'article' as the only root and give it a whirl.

| but identifying the 25-50 related
| tag groups (<gui...>, <func...>) shouldn't be *that* hard.  :-)

If the sets must be strictly non-overlapping, that's going to be
tough. If they're allowed to overlap, that's harder to customize.
|
| Basically, there are a bunch of people who understand HTML and the
| idea behind XML that still find the concepts behind DocBook too
| daunting.

Which concepts of DocBook would be made simpler by the modularity you
suggest?

| Most of the hard issues *are* editorial.  I don't use authoring
| tools, but I'd expect that someone who wants to use a particular
| 75 elements that describe the content in their document want to
| necessarily ignore the other 325 or so that aren't useful.

How does having them in the DTD have any bearing, though?

| I don't know about that.  Structured authoring with a 14 element DTD
| doesn't really compare to structured authoring with a 100 or a 400
| element DTD.  People know how to use HTML now, and the good ideas behind
| XML are rather well entrenched.

HTML has a good deal more than 14 elements, even if most people don't
use most of them. Which is sort of the point, I think.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | There is no spoon.
http://www.oasis-open.org/docbook/ | 
Chair, DocBook Technical Committee |