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 ™
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 <[email protected]> | 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
pgpfDLQs7zC3k.pgp
Description: PGP signature
