[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Citation syntax: a revised proposal
From: |
Richard Lawrence |
Subject: |
Re: [O] Citation syntax: a revised proposal |
Date: |
Fri, 27 Feb 2015 08:35:03 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) |
Hi Stefan,
Stefan Nobis <address@hidden> writes:
> Aaron Ecay <address@hidden> writes:
>
>> I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
>> biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
>> are quite esoteric, of course, but they are all provided.
>
> There are many commands (and even more private commands are possible)
> in order to help reproducing all the various citation styles out there.
>
> The critical question for org and org users is: How many different
> citation commands are needed in a single document (or needed by a
> single author within all her documents)?
These are very different questions. I think we need to answer the
second, since the syntax for citations will be common to all documents.
> If no single author ever needs more than about a dozen different
> commands (including variations like the genetive versions), the
> [cite:subcommand ...] syntax should suffice.
Yes, I don't disagree. But how do we know that no single author ever
needs more than a dozen different types/commands, across all her
documents, now and in the future? I for one do not feel comfortable
making this judgment a priori. As Aaron said, it's an empirical
question.
>> By way of illustration, Biblatex (AFAICT) doesn’t provide a
>> possessive citation command, which was mentioned by someone in this
>> thread (or its predecessor) as a desideratum. I’d expect a savvy
>> latex user to put in their preamble:
>
>> \newcommand{\citeposs}[1]{\citeauthor{#1}’s (\citeyear{#1})}
>
> This is what the subcommand is for. An author may define "poss" as a
> subcommand and use [cite:poss ...]. Then all the nice gimmicks will
> still work.
If I understand correctly, Aaron and I have two worries about this
approach. First, doing things this way potentially leads to a lot of
redundancy in the code you have to write when defining subtypes, which
is a maintenance hassle and an extra burden on users. Second, it means
that an author who has to deal with a lot of `uncommon' commands has to
remember a lot of subtype names, which are likely to be very similar,
because they represent overlapping groups of options.
Look at, e.g., the commands required in BibLaTeX to support citing
multi-volume works. There are 24(!) of them, because every one of them
is simply a multi-volume version of other combinations of options that
BibLaTeX supports (multi-cite or not? parenthetical or in-text?
footnoted or not? etc.).
For my part, if I were citing multi-volume works a lot, I would
appreciate being able to express all those options using orthogonal
distinctions. Then I could just add
{... :volume 2 ...}
at the end of a citation that already expresses most of those options in
the [cite: ...] part of the syntax. I would personally prefer *not* to
have to write
[cite/SUBTYPE: ...]
and remember which, among those 24 command types, I need to use (and
define) here.
(Also, note that this syntax does not have a way to pass additional
arguments like the volume, so it *can't* say "cite volume 2", even if
with a subtype label it can say "cite this multi-volume work". Citing a
volume in a multi-volume work seems like it might require some ugly
hacking on the subtypes approach, but I have no idea how often people
actually use such citations.)
On the other hand, Tom says that he prefers the latter way of working,
even if it requires a lot of subtypes. This is because it makes the
subtype easy to find-and-replace when changing a document from one
citation style to another. Also, it is simpler to write custom handlers
that dispatch just on the subtype, rather than on a plist of options.
So there are considerations on both sides. In the end, I prefer the
[cite: ...]{:key val ...}
syntax because:
1) it supports both styles of working (subtypes can be represented
like `:type fvolcites')
2) it allows passing additional arguments (e.g., volume number)
3) something like this is needed anyway elsewhere in Org
but I recognize there are some drawbacks to this over the simpler
approach of subtype labels.
Best,
Richard
- Re: [O] Citation syntax: a revised proposal, (continued)
- Re: [O] Citation syntax: a revised proposal, Samuel Wales, 2015/02/21
- Re: [O] Citation syntax: a revised proposal, Samuel Wales, 2015/02/21
- Re: [O] Citation syntax: a revised proposal, Aaron Ecay, 2015/02/25
- Re: [O] Citation syntax: a revised proposal, Richard Lawrence, 2015/02/25
- Re: [O] Citation syntax: a revised proposal, Nicolas Goaziou, 2015/02/25
- Re: [O] Citation syntax: a revised proposal, Richard Lawrence, 2015/02/26
- Re: [O] Citation syntax: a revised proposal, Thomas S. Dye, 2015/02/25
- Re: [O] Citation syntax: a revised proposal, Aaron Ecay, 2015/02/26
- Re: [O] Citation syntax: a revised proposal, Thomas S. Dye, 2015/02/26
- Re: [O] Citation syntax: a revised proposal, Stefan Nobis, 2015/02/27
- Re: [O] Citation syntax: a revised proposal,
Richard Lawrence <=
- Re: [O] Citation syntax: a revised proposal, Rasmus, 2015/02/27
- Re: [O] Citation syntax: a revised proposal, Melanie Bacou, 2015/02/20
- Re: [O] Citation syntax: a revised proposal, Richard Lawrence, 2015/02/20
- Re: [O] Citation syntax: a revised proposal, Vaidheeswaran C, 2015/02/24
- Re: [O] Citation syntax: a revised proposal, Richard Lawrence, 2015/02/24
- Re: [O] Citation syntax: a revised proposal, Vaidheeswaran C, 2015/02/25
Re: [O] Citation syntax: a revised proposal, Tory S. Anderson, 2015/02/15
Re: [O] Citation syntax: a revised proposal, Rasmus, 2015/02/15