Quotes

I’m wondering whether it makes sense to have some kind of attribute to add
quotes around fields. I say this because in the Chicago note style, the
subsequent citation is currently defined as:

There are two obvious problems with this. The first is that the title isn’t
italicized and has no quotes around it, and the second is that the pages
aren’t there.

Without some attribute, we would need:

No the nicest thing to look at. With an attribute:

(I can leave off the period, which actually belongs in the suffix attribute
of .) Or, in the , I could define:

Which would fix the substitution issue I spoke of earlier and this issue at
the same time. Then, in the section, all we’d need is:

Another alternative would be to define some attribute exclusively on
, in which case we could solve this problem and the problem I
mentioned earlier without implementing conditionals at all (although they
still might be useful).

The primary issue here, I think, is that the attribute might be hard to
implement (since it involves looking ahead to determine where the close
quote ought to go, or looking back once the close quote is generated).
Still, the convenience is probably worth the additional programming
complexity.

Simon

Am in a bit of a hurry, but let me see if I can zero in on something …

    <titles prefix="&#8220;" suffix=".&#8221;"/>

No the nicest thing to look at. With an attribute:

So are you just not aesthetically-pleased with the entities, or is
there something more fundamental?

If the former, then you should in any case be using curly quotes,
which you can enter directly as unicode characters: prefix=""" suffix
""".

Also, I don’t think it makes sense to load up additional attributes to
get around an aesthetic problem.

OTOH, if there is some something I’m missing, just tell me, and I’ll
look at it later.

BTW, I didn’t get an answer on how to implement the conditional.

Bruce

Am in a bit of a hurry, but let me see if I can zero in on something …

    <titles prefix="&#8220;" suffix=".&#8221;"/>

No the nicest thing to look at. With an attribute:

So are you just not aesthetically-pleased with the entities, or is
there something more fundamental?

If the former, then you should in any case be using curly quotes,
which you can enter directly as unicode characters: prefix=""" suffix
""".

Also, I don’t think it makes sense to load up additional attributes to
get around an aesthetic problem.

The issue is that putting quotes around a title is more like italicizing it
than it is like adding a comma after it. Most conspicuously, the following
punctuation mark needs to go before the close quote, even if it belongs to
the following field. 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.

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.

OTOH, if there is some something I’m missing, just tell me, and I’ll
look at it later.

BTW, I didn’t get an answer on how to implement the conditional.

I’m still partial to the first option you presented, although I don’t think
it’s a good idea if you’d have to switch everything to generic fields. Why
not either a) leave it unvalidated (if no such field exists, the conditional
is always false) or b) enumerate the fields separately in the schema as
possible values for the attribute (a pain, I know).

Simon

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?

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.

OTOH, if there is some something I’m missing, just tell me, and I’ll
look at it later.

BTW, I didn’t get an answer on how to implement the conditional.

I’m still partial to the first option you presented, although I don’t
think
it’s a good idea if you’d have to switch everything to generic fields.
Why
not either a) leave it unvalidated (if no such field exists, the
conditional
is always false) or b) enumerate the fields separately in the schema as
possible values for the attribute (a pain, I know).

It’s not THAT big a deal; more it seems less-than-ideal from a design
point. But it’s likely the best option. Will think on it some more and
make an executive decision.

Bruce

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

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.

Yes, one possibility.

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.

It’s not that easy actually. For one thing, we’re talking plain text
generally, which typically does not have any such markup. For another,
proper markup in XML languages (including XHTML) would encode the
semantics: xxxx. And in fact, I
suspect with data from vendors and such would more typically use
xxxx. Have actually seen that in some RIS data.

Not saying we need to worry about it that much now; just that it’s a
related issue we may need to tackle (later).

If we don’t add explicit support for quotes, how do we handle
particular
situation?

I’m not arguing against it; just wanted to clarify. I’m fine with
adding it. Either add it yourself, or post your suggested RNC fragment
here and I’ll do it.

And, while I’m complaining about formatting specifics, it seems that
et-al
needs to be configured separately for first and subsequent citations.

It already can be. Use the position attribute. :wink:

Bruce

Just a note to say that it would be great to ensure that the
’punctuation inside quotes’ thing is configurable (and per locale,
rather than style). It’s a strange one, but writing in, say
Australia or the UK, and using the Chicago citation format one would
still place the punctuation outside the quotes. Not strictly
compliant perhaps but stylistically correct (punctuation inside
quotes is almost entirely a US thing, in my experience).

The proposals below all seem to make that configurable, so that’s
great. Pardon my unfamiliarity with the code, is there a 'locale’
configuration (for dates, and other curious aspects like this
punctuation inside/outside quotes?)

–J

(punctuation inside
quotes is almost entirely a US thing, in my experience).

I bet Simon screams “dammit!” at his screen when he sees this!

The proposals below all seem to make that configurable, so that’s
great. Pardon my unfamiliarity with the code, is there a 'locale’
configuration (for dates, and other curious aspects like this
punctuation inside/outside quotes?)

At this point, only for strings (the “locales” directory), and I worry
a lot about making it more complex than it already is. Starting to look
like my original decision to have style locale-specific might have been
better.

But if people have reasonable suggestions, let’s hear it.

Bruce

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.

It’s not that easy actually. For one thing, we’re talking plain text
generally, which typically does not have any such markup. For another,
proper markup in XML languages (including XHTML) would encode the
semantics: xxxx. And in fact, I
suspect with data from vendors and such would more typically use
xxxx. Have actually seen that in some RIS data.

Not saying we need to worry about it that much now; just that it’s a
related issue we may need to tackle (later).

We’re talking about plain text for now (because as far as I know, all of the
CSL parsers that have been written only support plain text input), but if
someone wants to write a parser that handles HTML input, it would take a
single line of code to solve the italicization problem.

(punctuation inside
quotes is almost entirely a US thing, in my experience).

I bet Simon screams “dammit!” at his screen when he sees this!

I think this is even more of a reason to have an attribute. Without an
attribute, British users have to rewrite all of the prefixes and suffixes
(and remove all the conditionals to deal with punctuation inside the
quotes), or else the application has to offer to run a regular expression
over all the output. With an attribute, it’s completely configurable
behavior.

The proposals below all seem to make that configurable, so that’s
great. Pardon my unfamiliarity with the code, is there a 'locale’
configuration (for dates, and other curious aspects like this
punctuation inside/outside quotes?)

At this point, only for strings (the “locales” directory), and I worry
a lot about making it more complex than it already is. Starting to look
like my original decision to have style locale-specific might have been
better.

But if people have reasonable suggestions, let’s hear it.

Well, it’d certainly be really annoying to have two English versions of each
style (en-US and en-GB), and it’d be equally annoying to have two copies of
locales.xml. I say we leave it up to parsers to offer this as a configurable
option.

Simon

So you’re suggesting just adding:

attribute quotes { "true" }?

… and be done with it? Details up to the implementation (not in the
locales files), and maybe revisit later if we need to?

I’d be fine with that, FWIW, though I could also see terms like:

… and so forth. Doesn’t address the punctuation, though, and so might
require it’s own structure?

Bruce