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

[Paul Grosso <pgrosso at arbortext dot com>]

At 21:32 2002 09 05 -0400, ed nixon wrote:
>Paul Grosso wrote:
>>At 15:36 2002 09 05 -0400, ed nixon wrote:
>>>Paul Grosso wrote:
>>>><snip/>
>>A big problem for me is that I still have not seen a satisfactory
>>explanation of the user requirement(s) that is(are) driving this
>>discussion.
>
>You are right, of course. I think the people who read this list regularly become aculturated to the "atmosphere" of an exchange. For example, the implicit, assumed goal that I saw immerging is two-fold:
>1. significantly accelerate the learning curve of new and inexperienced users of the DocBook schema

I understand the desire to reduce the learning curve, but I'm not
convinced reducing the size of the DTD does that.

Reducing the number of tags in the DTD to N doesn't make it any easier
for a user to learn the M < N tags s/he wants to use.  You can make
it easier to learn by just learning the ones you need, you don't have
to reduce the number in the DTD.

>2. further reduce the support overhead of this and the APPS list significantly for a certain class of question by simplifying and/or compartmentalizing. I detected that in the wind over the past months; I assume there are others who have developed the same impression. Perhaps not.

Most people ask "what tag do I use to do X?"  I don't see how
removing tags so that X can no longer be done reduces the
overhead.

>><snip/>
>>What user requirements do "bolting or unbolting components
>>of a per application basis" address?
>
>Are there significant and identifiable "genres" of DocBook application? For example, is there a significant delimitable difference between the markup required for software versus hardware documentation? Are there other types of publication that lend themselves to a segmentation exercise of some sort?

I believe splitting up the DocBook app into genres just adds 
yet another complication to learning it.  (Which genre do I
learn, and what if it turns out the way the DocBook committee
split things into genres doesn't work for my app?)


>>Personally, I see three disadvantages of that:
>>1.  someone has to do the bolting for a given application;
>>2.  the tools have to support bolting/unbolting;
>>3.  as soon as you bolt together one setup, someone is
>>    going to want/use/expect a tag you didn't bolt in.
>
>Yes. And that's what I meant by the difficult challenge of what to do, how and when. But the DocBook direction has always been toward customization. Is there an easier way, or a more generic way of doing it?
>
>>Or, put in terms of user requirements, I see your suggestion
>>accrues negative rather than positive points in the corresponding
>>three (plus) user requirement areas:
>>1.  I can use the off-the-shelf DocBook application with no extra work.
>
>Could you please list them for me? I gather Epic makes the claim and there are one, perhaps two of the under $100 editors. Are there a significant number of others? Using current, XML versions of DocBook? I use XMetaL and it is, unfortunately, a fair amount of work just getting something into the editing area that looks half-decent. Getting to a really smooth and robust editing environment for a MSWord convert is a tremendous amount of work.

I'm saying the statement #1 above is a user requirement (or perhaps
"user goal" would be more accurate).  I'm not saying it is necessarily
currently a true statement.  I have to admit I haven't done a survey 
lately, but I do believe there are tools out there.  Even if you're
just talking about using XSLT, you can point your XSLT processor to 
the DTD and stylesheets on the web right now without touching them.
If you require bolting, you can no longer do that.

>>2.  I can find lots of tools that handle my application with little or
>>    no configuration.
>
>Lots? Same as above?

Same as above.


>>3.  I can expect all of DocBook to be available; I can use TDG as a
>>    reference with no surprises; 
>
>All of DocBook and the "general, newbee, somewhat doubtful about this new markup and controlled editing thing" freezes in his tracks, confounded by a wealth of (to him) meaningless choice.
>
>No surprises? This is clearly not the case, Paul, otherwise there would be significantly less traffic on this list. Every day there are surprises and inconsistencies because it is all a living, breathing, evolving system.

There would be more surprises if someone found a tag in TDG that they
thought did what they want and they tried to use it but are told that
tag doesn't exist.  Right now, the list never hears about those that
used TDG, found a tag, tried it and liked it.  Once you have different
DTDs, people are going to find that DocBook isn't just DocBook, TDG
doesn't really document their application, and someone on the list will
say "you should use to FOO tag" but the user will then find their genre
doesn't include the FOO tag, and we will have a much bigger mess.

paul