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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

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

Subject: RE: [docbook-apps] DocBook Customization

I'd like to know more about he modular DocBook stuff. Are there any
early drafts of the proposal or information I could look at?

Will it make interop between DocBook and DITA easier?  

-----Original Message-----
From: Scott Hudson [mailto:scott.hudson@flatironssolutions.com] 
Sent: Tuesday, May 19, 2009 9:23 PM
To: Bob Stayton
Cc: Eric Johnson; DocBook Apps ML
Subject: Re: [docbook-apps] DocBook Customization

If you want to "start" with a simplified version of DocBook, you should
check out the Simplified DocBook DTD or the new Publishers schema. These
are "official" customizations that minimize the number of elements.

With the proposed Modular DocBook addition to the standard (likely
v5.1), there soon will be a way to more easily work at a topic level
while remaining in DocBook compliance.

I second Eric's opinion that there is no DITA XSL: The Complete Guide,
so the customization for DITA is much more challenging!

Best regards,


Bob Stayton wrote:
> Hi Eric,
> My impression is that many groups adopt DITA because they want to work

> in topics rather than chapters. Then they do whatever is needed to use

> DITA to write topics. I have been in contact with more than one group 
> that has adopted DITA without any DTD customization.  As you say, 
> people often do crazy things.  8^)
> One common DocBook customization practice is to cut down on the number

> of elements.  There are several reasons why:
> a.  When using an XML editor that presents a list of valid tag names, 
> the list can be quite long in many contexts (such as inlines).  Many 
> such elements are never to be used, so remove them from sight.
> b.  Reducing ambiguity in choosing among similar elements.
> c.  Reducing the complexity of a stylesheet customization. If you know

> you are only supporting certain elements you don't need to have 
> templates for all elements.
> d.  Reduce the complexity of the para element by removing block 
> element children (making it like simpara).
> It is possible to make a subset that still produces documents that 
> validate with the full DocBook schema. But of course not the other way

> around.
> In terms of the cost of customization, I have found customizing the 
> DocBook 4 DTD to be easier than customizing the DITA DTDs. In DITA's 
> DTDs, everything is a twice-removed parameter entity, and it is hard 
> to keep track of where an element is actually declared and what 
> children it can contain.  DocBook 4 uses parameter entities, but not 
> to such a complex degree.  DocBook 5's RelaxNG grammar is even easier 
> to customize, once you learn the grammar.
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net <mailto:bobs@sagehill.net>
>     ----- Original Message -----
>     *From:* Eric Johnson <mailto:EMJOHNSO@progress.com>
>     *To:* DocBook Apps ML <mailto:docbook-apps@lists.oasis-open.org>
>     *Sent:* Tuesday, May 19, 2009 5:11 AM
>     *Subject:* [docbook-apps] DocBook Customization
>     I was talking to someone last night and they mentioned that the
>     biggest use case, and the one that is causing everyone to flock to
>     DITA, for using DocBook is to take the schema and then customize
>     My first reaction was to think "That's completely crazy. This
>     is obviously just a DITA cultist and seeing the world through
>     lenses." Then the cynic in me piped up and said "People often do
>     crazy things."
>     Is this a big use case in the DocBook world? Do organizations
>     with standard DocBook and then tweak it around to make some
>     customized version of the schema that is no longer DocBook?
>     Why would an organization customize DocBook instead of adopting
>     which is built with the (almost) requirement that it be
>     What is the cost of doing the customization?
>     One of the reasons my group adopted DocBook was that the schema
>     not need to be customized. We had to create a few guidelines
>     using certain tags, but that was much easier than modifying the
>     schema. Perhaps in larger groups using the schema to enforce rules
>     is more desirable.

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