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,
--Scott
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
[email protected] <mailto:[email protected]>
----- Original Message -----
*From:* Eric Johnson <mailto:[email protected]>
*To:* DocBook Apps ML <mailto:[email protected]>
*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 it.
My first reaction was to think "That's completely crazy. This person
is obviously just a DITA cultist and seeing the world through tinted
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 start
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 DITA
which is built with the (almost) requirement that it be customized?
What is the cost of doing the customization?
One of the reasons my group adopted DocBook was that the schema did
not need to be customized. We had to create a few guidelines around
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
