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] | [Elist Home]

Subject: DOCBOOK: Re: doc domain vs. problem domain semantics

>From: Bob Stayton <bobs@caldera.com>
>To: "Matt G." <matt_g_@hotmail.com>, ndw@nwalsh.com
>CC: docbook@lists.oasis-open.org
>Subject: Re: DOCBOOK: Re: doc domain vs. problem domain semantics
>Date: Tue, 12 Feb 2002 11:00:02 -0800
> > >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.

Yes, easy to write, but not maintain.  Without namespaces, multiple 
customization modules may not be compatible.  Worse yet, a customization 
module may not be compatible with a newer version of DocBook, due to element 
name collisions, or there may be similar incompatibilities between future 
versions of different customization modules.  I realize that the core 
DocBook elements need not have a namespace, in order for these other 
components to use them, but it's a nice mechanism to formalize subdivision 
of the vocabulary, and it provides more flexibility, in the future.  Another 
advantage to splitting up the core vocabulary into categories in separate 
namespaces is the ability it provides for users to more cleanly replace some 
subset of it.

> > 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.

Extensibility is the primary benefit of the cleaner modularity I'm 
proposing.  However, I think there are many benefits that come along with 
partitioning the vocabulary, such as addressing the complaint that DocBook 
has too many tags.  Subdividing them allows users to more easily focus on 
the tags provided for the task at hand.  I'd advocate that the reference 
part, in TDG, be structured this way, even if the different tag sets aren't 
put into different namespaces or available as separate distribution modules.

Furthermore, existing DocBook users will certainly benefit from more 
widespread reuse, of the core vocabulary, by others.  These benefits are 
likely to include improvement in tools, documentation, and support.

Among other things, I'm concerned that LaTeX is still seeing widespread use, 
when it's clearly inferior, in nearly all respects, for most applications.  
I fear that, if the modularity, extensibility, and processing tools, of XML 
DocBook don't all improve, that the opportunity to succeed LaTeX may be lost 
(and perhaps to something inferior).

>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

I think the move is even justified by only those benefits that are in line 
with the charter.

>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

I was asking how close it was to being appropriate for all publishing needs. 
  I'm not proposing that anyone should actually try to do this.  What I am 
proposing is that the vocabulary be modularized to improve manageability and 
extensibility.  I would be happy if people were using DocBook as a 
foundation for all sorts of technical and scientific literature.  For this 
to happen, I believe that substantially more opportunities for reuse must 

In other words, DocBook clearly isn't a good fit as a foundation for many 
publishing needs, but it should be a reasonable foundation for many TOPICS 
about which documents are written.

>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.

I'd encourage the TC to consider hacks, to help smooth the transition and 
retain interim compatibility with non-namespace aware tools.

For example, a transitional DTD could be written to include a namespace 
abbreviation in the element names of elements not in the core namespace.

>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.

As I said, I'm not very concerned about the PUBLISHING end of things, as 
support for different TOPICS (what I call the "problem-domain").

>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.

As stated above, if you want to mix customizations, there is serious 
potential for collisions.

I think it would be valuable for *someone* (not necessarily the TC) to 
provide tools and documentation to facilitate the development, packaging, 
and documentation of extension modules + stylesheets.

>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:

I've heard of it, but haven't looked at it, much.  Not that there's not room 
for TEI and DocBook to co-exist, but I think that whichever makes it easier 
for users to pick and choose (or develop) modules that naturally fit 
whatever they'd like to document has the best chance for long-term survival.

The nice thing about DocBook is that it tries to capture the structure of 
print publications.  Since this is orthogonal to the more specialized 
elements, I assume it's possible for one group to develop and maintain a 
single customization layer that works for both the main DocBook vocabulary, 
as well as the website version (is this Norm's, or an official TC product?). 
  It might also be nice to replace the core document structure elements, to 
create a forms markup language, while retaining most or all of the other 
groups of elements, including most extension modules.

Anyhow, perhaps I haven't made a very compelling case for subdividing 
DocBook, but I'd like to hear what other ideas people have for improving the 
manageability of the vocabulary without handicapping it.

One last thought: I'm not sure I can exactly characterize this, but I just 
get this uncomfortable feeling about technologies that aren't moving forward 
to scale beyond their current scope.  It's almost like they feel dead.  I 
understand your point about the interests of DocBook's sponsors, but it 
seems so short-sighted and artificial to me to limit the scope of DocBook, 
here.  It's not yet quite a 100% solution, but it feels like something with 
so much potential.  And then there's part of me that wonders: "why do so 
much work, only to stop this short of something so big?".

I appreciate the thoughtful reply.

Matt Gruenke

Join the world’s largest e-mail service with MSN Hotmail. 

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

Powered by eList eXpress LLC