This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: doc domain vs. problem domain semantics


On Mon, Feb 11, 2002 at 07:41:23AM +0000, Matt G. wrote:
> 
> >3. The DocBook Technical Committee (TC) is actively maintaining
> >DocBook. If you have a construct for which there is no suitable tag,
> >and the problem domain you are working in is not too far afield,
> >chances are the TC will address the issue.
> 
> The problem is that this approach doesn't scale well.  That's what I'm 
> trying to address.
> 
> >4. If you need a new element and either can't wait for the TC to
> >consider it, are if the TC rejects your use case for some reason, you
> >can always add it yourself.
> 
> I'd like to see people start maintaining sets of application-specific 
> customizations + stylesheets, for DocBook.  Then, people could assemble 
> packages, which include these customization modules and their associated 
> stylesheet modules.  Of course, without namespaces, this approach won't 
> scale very well.
> 
> > >>The entire design of DocBook is geared to make it possible for
> > >>you to write customization layers that provide the exact markup
> > >>that you need.
> 
> I see this as the core competency of the TC.  If they do a good job with 
> document structure & meta info (and they have), then there can be 
> customizations for dozens of fields of every sort.

[stuff deleted]

Matt, it's my understanding that you are suggesting
that DocBook become a general purpose publishing system.
You'd like to see it structured in a way that permits
it to be adapted to many kinds of publications, not
just computer-related documentation.

There will be some resistance to this notion, because of
DocBook's origins.  It grew out of a consortium of computer
companies wanting a common source format for its
documentation. Those computer companies funded (and continue
to fund through OASIS) the development of DocBook to that
purpose.  It is not currently in the charter of the DocBook
Technical Committee to develop a general-purpose publishing
system.  

As often happens, though, a good tool can be put to new uses.
The DocBook developers did such a good job designing and
implmenting the DTD and the related stylesheets
that they can be used for purposes for which they
weren't intended.  The customization features that
were included to enable individual computer companies
to change or add elements to meet their specific
documentation needs also permit anyone to customize
DocBook for non-computer related needs.  Such customizations
are permitted and encouraged. 

But that's different from saying that DocBook should be
designed so that it can be adapted to all publishing
needs.  As you say, namespaces might be needed to keep
separate the various modules that could be added. But
namespaces considerably complicate the schema, toolset, and
authoring process.  The TC is starting the examine the use
of namespaces for tables, math, and graphics.  If those
problems are worked out, then adding other namespaces
would be enabled.

Perhaps DocBook should move in the direction of
general-purpose publishing, but I think that is a fundamental
question that the DocBook Technical Committee will have to
settle before it starts restructuring DocBook.  I'm willing
to take that question to the committee, however.

As Norm pointed out, DocBook can already be customized to
meet application-specific needs.  I agree that the process
could be better documented, and that perhaps a registry of
supported third-party customizations be made available.

I'd also point out that DocBook is not the only DTD out
there.  The Text Encoding Initiative (TEI) has a modular
DTD that can be mixed and matched to meet many publishing
needs, and contains no computer-related elements that I can
see.  8^)
TEI also has a set of XSL stylesheets that are modularized:
<http://www.hcu.ox.ac.uk/TEI/Stylesheets/teixsl.html>


Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]