Scott,
Good points.
I'm a firm fan of DocBook and think it can do anything
that DITA can (and more). But, if anyone on the list has
the chops to do a DITA XSL: The Definitive Guide, let me
know; I think it's needed and I'd like to publish it.
Dick Hamilton
---------------------------------
XML Press
XML for Technical Communicators
http://xmlpress.net
(970) 231-3624
> -----Original Message-----
> From: Scott Hudson [mailto:]
> Sent: Tuesday, May 19, 2009 7: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,
>
> --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
> > <mailto:>
> >
> >
> >
> > ----- Original Message -----
> > *From:* Eric Johnson <mailto:>
> > *To:* DocBook Apps ML <mailto:>
> > *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:
> For additional commands, e-mail:
>
>
>
