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: Re: [docbook-tc] DocBook for Commercial Publishing (expanding our worldview)


Wouldn't our charter extend to periodicals covering the areas of computer hardware and software, as O'Reilly's periodicals do?

Actually, I don't see any theoretical problem with the addition of a 'cover' element, since I see that as something that could also be used for a book.  And If I understand the use case for periodical; it's a collection of articles, the way a book is a collection of chapters.  If so, it seems like an extension that doesn't break any of our rules for cusomization.  My concern, as it is for most requests to add more elements to DB, is whether cover and periodical are considered  worthy of use  by at least a few people/organizations, before adding it to our extensive list of elements.  Despite our large collection of software/hardware-related elements, DocBook lends itself to be customized by non-computer-related authors and publishers because of its solid base of book and authoring elements. We need to keep that in mind in our roles as keepers/maintainers of core DocBook, knowing that many user will customize it for their own purposes. The cleaner we keep core DocBook, the easier it is for users to customize it, and for the TC to maintain it.  

I think that we are already doing the right thing in regard to some customizations in having a few of the more successful and widely-used customizations (e.g. slides)  have some space on the DB site. We might want to encourage others who are committed to maintaining a potentially popular customization by offering to add their customizations to the DB page as well, or to the sourceforge site.

The DITA TC has supported the creation of a number of specializations, and actively fosters their development, as long as the creators also maintain them.  That way, the DITA TC gets to focus on the core DITA capabilities, but the user community gets to share in useful additions.  This might be the way to think about periodical and its associated elements.

I'm conflicted on the subject of <topic>.  I don't think there's anything you can do with a <topic> intrinsically in DocBook that you can't do with a section.  Are we gong to define topic the way DITA defines topics, with all the associated class infrastructure?  If so, then we're reimplementing DITA, and I don't see any reason to do that. I see much more reason to interoperate with DITA than to copy it.  I have memories of our frequent discussions during the past several years about creating modular help-appropriate elements for DB, but now that someone has actually created a set of such elements for XML, I'm less than excited about replicating that work in DB.  In fact, given the choice between going in the commercial publishing direction, and going in the topic direction, I'd prefer, like Scott, to take a path that doesn't already have another TC clumping along on it.


"Bob Stayton" <bobs@sagehill.net>

10/30/2006 04:17 PM

"Scott Hudson" <scott.hudson@flatironssolutions.com>, "DocBook Technical Committee" <docbook-tc@lists.oasis-open.org>
Re: [docbook-tc] DocBook for Commercial Publishing (expanding our world view)

Hi Scott,
Actually, there is something in our charter about it:
"Most requests for enhancement that are not motivated by a requirement in
computer hardware or software documentation are considered out of scope. It
is not a goal of the Technical Committee to expand the scope of DocBook to
include additional, unrelated problem domains."


Bob Stayton
Sagehill Enterprises
DocBook Consulting

----- Original Message -----
From: "Scott Hudson" <scott.hudson@flatironssolutions.com>
To: "DocBook Technical Committee" <docbook-tc@lists.oasis-open.org>
Sent: Monday, October 30, 2006 7:58 AM
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=detail&atid=384107&aid=1440204&group_id=21935),
> 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

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