OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] DocBook SCs

Dave Pawson wrote:
> Mike Maxwell wrote:
>> I'll also mention that one of the things that bothers me about the
>> current DocBook is that it seems to be so oriented towards computer
>> documentation.
> Which is good, since that is just where it originated!

Sigh, because that's where it will stay unless it improves!

>   Of course one can pare it down, but I wonder why all
>> those computer-related tags in there in the first place, instead of in
>> one or more separate add-in modules?  In other words, I would like to
>> use DB for my purpose (grammar writing) by taking a bare-bones DB and
>> adding any modules I might need, rather than taking a "fat" DB and
>> modifying my local schema to omit all the tags I don't need.
> Then you need to persuade all the other docbook users that your usage
> is more important, better centre field etc, than the current set?

There is obviously a core set of concepts that are generic: book/ article/
report etc.; sections, paragraphs, itemized or numbered lists, pictures
etc.  But a concepts like 'hardware', 'classname', (EBNF) 'constraint',
'destructorsynopsis', just to take a few that leap off the page--these are
relevant only to software and/or hardware documentation.  I suspect
there's a large community of people out there who might use DB, but are
scared off by the need to wade through all this software documentation
"stuff" in order to find the core concepts.  As long as it isn't
modularized to put all that "stuff" somewhere, "all the other docbook
users" that you refer to are going to stay the same, and most of the
people who might otherwise use it are going to stay with Microsoft Word or
Open Office.  IMHO.

> I guess we all use docbook for different purposes.

Exactly my point; you don't want to see the linguistic tags that I use in
my grammars :-), and I don't want to see most of the software tags that
you use in your computer documentation, or all the publishers' tags.

> If you're bothered by the high tag count, you could create
> your own subset, removing those elements you don't want,
> for your own use.

As I mentioned in my original posting, this is what I have already done. 
But that probably makes my core subset different from someone else's core
subset, while they could (and I believe should) be the same.  Everything
else can and should be this or that module--a module for grammars, a
module for software documentation, including a way to use some of those
additional tags in more than one module.  (I use literate programming tags
in my grammars; I can imagine a software documenter wanting to do the
same, and our use of those literate programming tags should be the same.)

(BTW, I found Scott Hudson's comments on my earlier posting very helpful,
and it sounds like he and I are thinking along the same lines--I hope
Scott doesn't mind my saying that.)

   Mike Maxwell

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]