Re: DOCBOOK: Re: marking up keycaps according to their semantics

["Robert P. J. Day" <rpjday at mindspring dot com>]

  i didn't mean to make a big issue out of this; i'm satisfied
with the current proposal, but let me just try to explain what
i was talking about -- it might make sense, it might not.

  currently, a key cap is written as <keycap>x</keycap>.  this
seems to suggest that a keycap is, by default, of type "literal",
if i can call it that.  and its content is "x".  so far, so good?
(one might even go as far as to suggest that the above really
represents the element <keycap type="literal">x</keycap>, where
obviously i am *inventing* the mythical "type" attribute, and making
it the default.)

  so how would one represent a *non-literal* key?  extending
the above, perhaps as <keycap type="function">Escape</keycap>,
or something to that effect.  in writing it this way, i'm trying
to separate the *kind* of keystroke from its *content*, because i
see those two pieces of information as, in some way, orthogonal.

  now the above is pretty darn wordy, but one can condense it
by, perhaps, redefining keycap to not need any content at all:

  <keycap literal="x"/>
  <keycap function="escape"/>

this, at least, is a consistent definition of a keycap -- it has
to specify both a *type* of key, and its associated content (that is,
the attribute and its value).

  i also notice that the definition of a keycap, according to 
2.0.8, is "the *text* printed on a key on the keyboard" (my emphasis).
notice that this isn't strictly true anymore, since what might be
displayed could be something other than text.

  anyway, i realize i'm being thoroughly anal retentive, so i'll just
shut up now, and whole-heartedly support whatever gets added.

rday