The issue is that putting quotes around a title is more like
italicizing it
than it is like adding a comma after it.
OK.
Most conspicuously, the following punctuation mark needs to go before
the close quote, even if it belongs to the following field.
OK. But is this a real practical problem? I guess if that following
field isn’t there, then you have spurious punctuation?
One way to solve this problem is to use a conditional every time
different punctuation marks could come after a quotation mark. Another
is to add an attribute to the schema and make the processor handle the
the punctuation.
So have explicit quote support and define rules about what that means
for processors?
Well, either the style authors or the style processor will have to think
about the position of quotes, and I think explicit support makes more sense.
Right now, in the Chicago style, we have:
There are some major problems here. If you don’t have any of the fields
after the quote, you get:
Margaret Bard, Miriam Newhouse, and Peter Messaline, ³And Do You Have
Anything Else?: Audition Pieces from Canadian Plays,² .
In fact, try to use conditionals to make the style work with any of the
fields empty, and one ends up with:
The condition is intentionally left out; it would need to be “if title or
container title or date or access.” With the quotes attribute, this becomes:
The output is the same. Without the quotes attribute, we have to decide
whether our styles should be 100% correct or easy to read. If it’s possible
to create a style that’s 100% correct and still entirely readable, why not
do that?
A more general approach would be:
We could theoretically allow { “quotes” | “braces” | “brackets” |
“parentheses” }, although I’m not sure this generality is actually
necessary, since, as far as I know, only in the case of quotes does the
punctuation belong to the left of the closing mark.
If you can come up with a solution to the following problem (if we have a
way to create conditionals), I can commit a version of the Chicago style
that fixes everything without a quotes attribute. It won’t necessarily be
simple or readable, but it is possible.
I admit that this issue is much less of a deal when working with author-date
bibliographies, since they nearly always use periods after titles, although
it still rears its ugly head in author-date citations.
A related issue is that of double quotes within an article title (see
17.157
in the Chicago Manual of Style), which should be replaced by single
quotes
when the title is enclosed in double quotes. Only the latter approach
can
properly solve this problem.
Well, this issue is really the problem of markup within fields, which I
have not addressed. Examples include not just titles-within-titles
(your example), but also things like Latin phrases, math markup, etc.
I tend to think from the perspective of semantics then. It’s not
“quotes”; it’s “titles-within-titles” etc.
This approach would solve only one problem, and rely on using certain
plain text markup rules.
The only other rule I know of is that if there’s italicized text within an
italicized field, the italicization is simply inverted. Because everything
italicized has font-style=“italic”, that’s easy.
If we don’t add explicit support for quotes, how do we handle particular
situation? Short of some find/replace attributes (or forcing people to
change the way they enter their titles, or adding some processor-specific
replace rules), how can we format (to steal the Chicago example):
“'Tis a Misfortune to Be a Great Ladie:” Maternal Mortality in the British
Aristocracy, 1558-1559
As:
Judith Lewis, “'‘Tis a Misfortune to be a Great Ladie:’ Maternal Mortality
in the British Aristocracy, 1558-1559.”
And, while I’m complaining about formatting specifics, it seems that et-al
needs to be configured separately for first and subsequent citations. I ran
into this today while looking over the Chicago guidelines. This is probably
a much simpler change than either of the above.
Simon
