RE: [docbook-tc] Recommendation for elements dropped from v5

["Rowland, Larry" <larry.rowland@hp.com>]

I think command being used for action would be confusing.  The action is
something that happens (according to The Definitive Guide) in response
to a menu-item or other GUI interaction.  While sometimes it is
implemented via commands, I don't think it is necessarily always a
command.  There are also formatting considerations.  Command has
distinctive formatting, while action does not.  I will probably use
<phrase remap="action"> to preserve the original intent.

I think medialabel may map more appropriately to a citetitle with a
pubwork of "dvd" and might add more pubwork enumerations to handle tape
and CD.

Larry Rowland 

-----Original Message-----
From: Richard Hamilton [mailto:rlhamilton@frii.com] 
Sent: Tuesday, February 14, 2006 4:54 PM
To: DocBook Technical Committee
Subject: [docbook-tc] 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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php