MHonArc v2.5.0b2 -->
docbook-tc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Recommendation for elements dropped from v5
Here is the write up for my action item to describe how
authors should handle elements that have been dropped in
DocBook v5.
The dropped elements are: action, beginpage, highlights,
interface, invpartnumber, medialabel, modespec, structfield,
and structname. For each, there's a recommendation and
a justification. Once the TC is happy with the recommended
disposition of these elements, I'll be glad to extend the
current write-up in the DocBook v5 how-to to cover these
elements.
Dick Hamilton
rlhamilton@frii.com
-------------------------------------------------------------------
Element Recommendation/justification
==================================================================
action: Use <command>.
The content model is the same, the attributes
are the same, and I think it's not much of a
stretch to call an action a command.
beginpage: Remove
Since this is advisory, and tends to cause
some confusion anyway, I'd suggest removing
it completely. Where it's really needed,
maybe the right thing to do is replace it
with a processing instruction (or would that
be a "non-processing instruction":).
highlights: Use <abstract>
Highlights has a broader content model, but
since both allow the para family (formalpara,
para, and simpara), I think anything highlights
allows can be put into an abstract, inside a
para. Also, highlights is allowed in a few
places that abstract is not, in particular:
answer, qandadiv, qandaset, question,
revdescription, and sidebar. It's not clear
to me that we should restore abstract to any
of these. The most likely ones, qandaset
and sidebar, include info and info includes
abstract. The rest seem to me to be unlikely
places for either highlights or abstract.
interface: Use the appropriate gui* element.
Interface is already flagged as obsolete,
to be replaced by the gui* elements.
invpartnumber: The db4-upgrade script currently maps this
to <biblioid class="other" otherclass="invpartnumber">
I think it's also reasonable to suggest
<productnumber> as an alternative where
there's no collision with other uses.
medialabel: Use <label>
Using label for medialabel would require us to
broaden the definition of label, allowing it in
more places than is currently the case. Or, if
that's too much of a stretch, we could use:
<biblioid class="other" otherclass="medialabel">.
modespec: No longer needed?
It seems like the current processing model
for olink renders modespec unnecessary and
it's not clear very many people were using it
anyway (the last reference I could find in
google groups was 2002)
structfield: Use <varname>
structname: Use <varname>
For both of these, it looks like varname is
the closest match
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]