Re: [docbook-tc] DocBook for Commercial Publishing (expanding our worldview)

[Nancy P Harrison <nancyph@us.ibm.com>]

Hi,


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.

Nancy

"Bob Stayton" <bobs@sagehill.net>

10/30/2006 04:17 PM

To	"Scott Hudson" <scott.hudson@flatironssolutions.com>, "DocBook Technical Committee" <docbook-tc@lists.oasis-open.org>
cc
Subject	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."

http://www.oasis-open.org/committees/docbook/charter.php

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


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