RFE 2791288: add quote to corpauthor and gui elements

[Norman Walsh <ndw@nwalsh.com>]

Hello world,

This RFE[1] makes the (quite reasonable, I think) suggestion that
<quote> should be allowed in <holder>. (I'm not sure I see the
relevance of <quote> in the <gui...> elements, but let's set that
aside for a moment.)

Nowhere are the quote characters forbidden, so I think it's reasonable
to assume that the quote element should be ubiquitous. (This is
especially true when you consider that quote characters vary by
language and locale, so being able to generate the appropriate
quotation character has real value.)

Reviewing the content model of holder, we find that it boils down to
the ubiquitous inlines, a limited form of phrase that can only contain
the ubiquitous inlines, replaceable, and text.

Recall that the ubiquitous inlines are:

  inlinemediaobject          (for non-unicode characters)
  remark                     (for comments)
  superscript and subscript  (for ... super and subscripts)
  link, olink, xref, anchor  (for linking)
  alt                        (for accessibility)

How much markup to allow in ubiquitious inlines (i.e. *everywhere*) is
a judgement call. The more stuff you allow, the more stuff processors
have to be prepared to support *everywhere*. (As a concrete example,
consider that xsl:value-of on an element that can contain inline
markup is *never* safe.)

That said, we've already let that particular cat out of the bag, so
there's proportionally less harm in going a little farther. (To mix my
metaphors.)

My current thinking is that we should treat the inlines in groups. If
you're going to allow some elements of a group, you might just as well
allow all the elements.

In fact, if we'd applied that rule when we first added superscript and
subscript to the ubiquitous inlines, we would never have received this
RFE because the quote element is in the same group: publishing inlines.

The publishing inlines are:

  abbrev
  acronym
  date
  emphasis
  footnote and footnoteref
  foreignphrase
  phrase
  quote
  subscript
  superscript
  wordasword
  firstterm
  glossterm
  coref

The abbrev and acronym elements can also include trademark, but like
<quote> that should probably be allowed anywhere (because the &trade;
character is allowed anywhere).

I think the natural proposal at this point is to say that we should
allow the publishing inlines (and trademark) into the ubiquituos
inlnes.

The only reservations I have are:

1. Allowing footnote (and to a lesser extent footnoteref) is a pretty
   substantial change. It means you could wind up with just about
   anything as a descendant of any element that allows ubiquitous
   inlines:

     <phone>+1-413-555-1212<footnote><para>In the United States, all
     phone numbers in the <quote>555</quote> exchange are reserved for
     use in examples. They will never be assigned to residential or
     business customers.</para></footnote></phone>

   But maybe that's ok. As I said, we've already let the cat out of
   the bag, and are there really any places where footnotes shouldn't
   be allowed?

2. Some of these elements allow *all* inlines. In order to keep them
   from being a complete escape hatch, we'll have to build limited
   forms of, for example, firstterm just like we have the limited
   form of phrase.

   But maybe that's ok, too. It's definitely work for the schema
   authors, but does it really matter to users? Well, only to the
   extent that it might be confusing that sometimes phrase can contain
   "envar" and sometimes it can't. But we've already let that cat out
   of the bag too with phrase.

                                        Be seeing you,
                                          norm

P.S. I'm not sure that coref belongs in publishing inlines, but if I
was going to move it, I'd move it to the linking inlines which are
already part of the ubiquitious inlines, so it makes no difference to
the issue at hand.

[1] https://sourceforge.net/tracker/?func=detail&aid=2791288&group_id=21935&atid=384107

-- 
Norman Walsh <ndw@nwalsh.com>      | The perfect man has no method; or
http://www.oasis-open.org/docbook/ | rather the best of methods, which
Chair, DocBook Technical Committee | is the method of no-method.--
                                   | Shih-T'ao

PGP signature