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


 > In terms of the cost of customization, I have found customizing the
 > DocBook 4 DTD to be easier than customizing the DITA DTDs.

Talk about complex transforms: I've been using DITA recently, and the OT 
stylesheets look pretty intimidating to me - and no 'DITA XSL The 
Complete Guide' to help sort them out!


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



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