Re: [docbook-apps] Please respond: adding generic sibling to high-level book components

["Michael(tm) Smith" <smith@sideshowbarker.net>]

Scott Hudson <scott.hudson@flatironssolutions.com>, 2007-02-15 11:49 -0700:

> In DocBook 4.5, ackno has inline-level content and can
> only appear at the end of article. I have seen a need
> for an acknowlegements element in books, as a sibling to
> chapters.

Seems to me like a legitimate need. Many existing books and
articles -- including books and articles on computer software and
hardware -- have a section that is expliclity titled Acknowledgements.

> The proposal for DocBook v5.0 is to remove the ackno element,
> add an acknowlegements element, and give it a content
> model like that of dedication.  Also allow that element
> in article.

That all sound very reasonable to me.

> A straw poll on the TC showed 6 in favor and 1 opposed (Norm thinks it 
> is a bad idea).

Is there a record in the minutes of why Norm thinks it's a bad
idea? If not, maybe Norm can reply and say. I expect he must have
had a pretty good reason and it should be recorded somewhere if
the change does get made in spite of him finding it to be a bad idea.

> Some of the front matter materials have very specific semantics 
> (dedication for example), so I would not advise overloading that element 
> and using a role attribute (e.g., <dedication role="acknowledgements">). 
> The same situation occurs with preface. What if you need a preface, 
> foreword and introduction? Do you overload preface?

What happened to the option of just adding an Acknowledgements
element? Or is that what Norm was opposed to -- the option of
adding Acknowledgements instead of a more general element?

> Another consideration was a more general element that could use
> a class attribute to distinguish between them. For example,
> class="dedication" and class="acknowledgements" and perhaps
> others.

What would the others be? Have there been RFEs proposed for
any other new front-matter or back-matter elements to be added? Or
can we think of any other classes of front matter or back matter
that we should consider adding markup for?

> In this way, we could potentially consolidate some of these existing 
> front and back matter elements,

What would the value of that consolidation be?

> while providing a generic structure to meet future needs

I guess I would question what's going to change in the future that
would change the needs. I don't see the publishing industry
inventing new classes of front or back matter that don't exist now
and that we'd need to model. If there are other needs, I think
now would be the time to figure out what they are and add them.

> without having to adopt new elements.

As I've said in other messages, I think it's very misguided to
avoid adopting new elements by instead adding one new element with
multiple class values -- especially if the newly added element is
has some coined/invented name that's not going to be a familar
term to users.

  --Mike