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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


Subject: [Fwd: Re: [docbook-tc] DocBook for Commercial Publishing (expandingour world view)]



--- Begin Message ---
Scott wrote:

>I bring these items up because I'm finding DITA to be rather unfriendly
>towards traditional commercial publishing. I think we could gain some
>very powerful allies if we were to focus a bit on the needs of
>commercial publishing rather than restrict our scope so narrowly to
>software and hardware documentation

That's an excellent proposal. With as much hype as DITA gets these days, there's so much that DocBook can do that DITA simply cannot (at least not with the same flexibility and elegance). Expanding the standard's perspective to cover publishing is a natural and appropriate avenue for growth, IMHO.

Yours, 
Tony DaSilva, Deployment Project Manager- Outbreak Management System (OMS) 
Centers for Disease Control and Prevention 
Health Solutions Business Unit,
Science Applications International Corporation (SAIC) 
678-530-3676 (office), 678-463-3529 (cell) 
aod7@cdc.gov, antonio.c.dasilva@saic.com 


-----Original Message-----
From: Scott Hudson [mailto:scott.hudson@flatironssolutions.com] 
Sent: Monday, October 30, 2006 10:59 AM
To: DocBook Technical Committee
Subject: [docbook-tc] DocBook for Commercial Publishing (expanding our world view)

All,

According to TDG, "DocBook is a very popular set of tags for describing 
books, articles, and other prose documents, particularly technical 
documentation."

Unless there is something specific in our charter that says we should 
only consider tech pubs features when adding or modifying the DocBook 
standard, I'd really like to see us (the TC) approach new RFEs with a 
broader perspective, specifically commercial publishing.

You already are aware that O'Reilly has created a "DocBook Lite" variant 
in order to publish their document. They are not alone, and in fact, we 
do business with a number of large-scale commercial publishers at 
Flatirons. There are some issues with the current element set, that 
force us to create variants of DocBook in order to support commercial 
publishing needs, rather than being able to create valid subsets.

As for new features to support commercial publishing, here is a short 
list of items I've been considering adding as RFEs to DocBook:

1. Add a new <periodical> element to support regularly published 
material, such as a Magazine or Journal issue, blog, newsletters, and 
even topic, if that should also be added to DocBook. The <periodical> 
element will be a sibling of <book> and <article>. A whole new blog tool 
and infrastructure could be supported with the use of <periodical> and 
<topic>, assuming that <topic> were allowed to contain <section>. Of 
course, the same could be done with <article> as a child of <periodical>.

I think periodical was submitted and rejected back in March 
(https://sourceforge.net/tracker/?funcŪtail&atid84107&aid40204&group_id!935), 
but it is rather clunky to think of a magazine or newsletter or journal, 
etc. as a "book" for containment.

2. Extend <set> to include <periodical> in order to publish or contain a 
series of this type of content.

3. Add <cover> element to <book> and <periodical> as an optional 
element. There are a lot of variations in the type of content that could 
be included in a cover, including title, cover image, jacket text 
(perhaps sidebar could be used for this), etc. Instead of putting all 
this in the info element, this separate element would provide a clear 
distinction of what content should be included in the cover for the 
particular publication.

I bring these items up because I'm finding DITA to be rather unfriendly 
towards traditional commercial publishing. I think we could gain some 
very powerful allies if we were to focus a bit on the needs of 
commercial publishing rather than restrict our scope so narrowly to 
software and hardware documentation!

Software and hardware documentation blocks and inlines should be a 
separate module available in DocBook 5, as well as other domain-specific 
modules. Perhaps periodical-specific blocks and inlines could be 
separate modules as well!

 From the recent traffic on the list, there appears to be a fair amount 
of backlash against adding topic, and a call to "stick with what DocBook 
is best at". I think focusing on the needs of commercial publishing will 
continue to grow the DocBook user base and opportunities for DocBook to 
be implemented.

Thoughts?

Best regards,

--Scott
--- End Message ---
begin:vcard
fn:Scott Hudson
n:Hudson;Scott
org:Flatirons Solutions
adr:Suite 200;;4747 Table Mesa Drive ;Boulder;CO;80305;USA
email;internet:scott.hudson@flatironssolutions.com
title:Consultant
tel;work:303-542-2146
tel;fax:303-544-0522
tel;cell:303-332-1883
url:http://www.flatironssolutions.com
version:2.1
end:vcard



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