From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Lawrence <richard.lawrence@berkeley.edu>
Subject: Re: Should wip-cite branch be merged to master?
Date: Wed, 25 Apr 2018 12:19:47 -0700
Message-ID: <87efj39jqk.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me>
References: <29b94436.a1e.162e54aa7c1.Coremail.tumashu@163.com>
	<871sf9f2ak.fsf@nicolasgoaziou.fr> <87in8jaywk.fsf@all.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45572)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <richard.lawrence@berkeley.edu>) id 1fBQf7-0004kq-C9
	for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <richard.lawrence@berkeley.edu>) id 1fBQf4-0003SM-5h
	for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:09 -0400
Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:53565)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <richard.lawrence@berkeley.edu>)
	id 1fBQf3-0003S3-RW
	for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:06 -0400
Received: by mail-wm0-x236.google.com with SMTP id 66so9140938wmd.3
	for <emacs-orgmode@gnu.org>; Wed, 25 Apr 2018 13:05:05 -0700 (PDT)
In-Reply-To: <87in8jaywk.fsf@all.hu>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: =?utf-8?Q?Andr=C3=A1s?= Simonyi <simonyi@all.hu>, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: tumashu <tumashu@163.com>, emacs-orgmode <emacs-orgmode@gnu.org>, John Kitchin <jkitchin@andrew.cmu.edu>

--=-=-=
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi everyone,

I don't have too much to add to this, though I do want to thank=20
everyone for their continued interest in citations, and the work=20
that has been done!

Since the question of syntax has come up again, I guess I want to=20
address one point that Andr=C3=A1s made:
=20
Andr=C3=A1s Simonyi <simonyi@all.hu> writes:

> From the citeproc-el/CSL point of view, the current syntax is=20
> perfect with the notable exception of the provided citation=20
> commands. Currently only `cite' and `(cite)' are supported,=20
> where the latter seems to be intended to provide the=20
> parenthetical version of a basic citation, e.g. in an=20
> author-date style `cite' would produce something like `Smith=20
> 2018` while `(cite)' `(Smith 2018)'. Now I think that for=20
> author-date styles `cite' should produce the parenthetical=20
> version and that `(cite)' probably shouldn't be among the=20
> commands at all. The main reason is that most citation=20
> processors (biblatex, CSL processors etc.)  support not only=20
> author-date citation styles but footnote-based ones as well, and=20
> the concept of a `parenthetical citation' doesn't really make=20
> sense for the latter.=20

I think this actually gets at one of the fundamental problems with=20
citations, namely, they resist attempts to separate 'content' from=20
'style'.  It is hard to insert citations into a document without=20
making any assumptions about how they will be rendered by the=20
citation processor.  And so it is hard to come up with a syntax=20
that is general enough to represent widely different citation=20
styles, in a way that makes those assumptions explicit in the=20
syntax of the unprocessed citation, so that the content of the=20
citation can be separated from how it will be rendered.  Thus we=20
see the huge proliferation of different citation commands in=20
e.g. BibLaTeX, natbib, and similar packages.  Andr=C3=A1s' proposal=20
would reintroduce some of the complexity of BibLaTeX citation=20
commands at the level of Org syntax.

Maybe having multiple citation commands is ultimately the best way=20
to go, but I want to point out that one of the goals of the=20
original discussion to come up with an Org syntax that is simpler=20
and does a better job of separating content and style.  Anyway,=20
that was one of my goals in synthesizing people's various=20
suggestions and needs into a concrete syntax proposal.  I think we=20
should try to avoid proliferation of citation commands.

If that is a reasonable goal, then I think there is really just=20
one distinction that deserves to be represented at the level of=20
citation commands: the distinction between 'in text' and=20
'parenthetical' citations, that is, the distinction between=20
'cite:' and '(cite):' in the current syntax in wip-cite.  That=20
brings me to this point:

> A more abstract characterization which is applicable to all=20
> styles is that normally references are not part of the main=20
> text, they are set off either by brackets or in a note. Since=20
> this is the most frequent, basic form, I think this the one=20
> which should be produced by the `cite' syntax, that is, when=20
> used in normal text `cite' should produce something like `(Smith=20
> 2018)' for author-date styles and a note with the reference for=20
> note styles.

I think Andr=C3=A1s' abstract characterization is exactly right: the=20
issue here is not really about whether the citation has brackets=20
around it.  Instead, it is about whether the rendered citation is=20
intended to be *read as part of the surrounding sentence*=20
('in-text'), or whether it is *grammatically independent* of the=20
main text ('parenthetical').  I disagree, however, that=20
'parenthetical' citations are the normal or usual case; I think=20
that depends completely on one's field, writing style, etc.  (In=20
my dissertation, for example, in-text citations outnumber=20
parenthetical citations roughly 3:2.)=20

The 'in-text' vs. 'parenthetical'/'out-of-text' distinction is=20
really the fundamental one that you can't abstract from as an=20
author.  And it seems to me that apart from this decision, most of=20
the other decisions about styling can handed off to the citation=20
processor, via a choice of CSL file, at least for the out-of-text=20
case: is it a note-based style, or a Harvard-like one? etc.

The in-text case is a little trickier because you need a way to=20
represent the different kinds of data that might be intended to=20
fit into the surrounding sentence (author name? year? both? just a=20
number? etc.).  But there are many many possibilities here, and=20
for that reason I think it is better to avoid making them=20
primitive citation commands.  Instead we should just stick to one=20
command for the in-text case, and have some extensible way to=20
represent the data that should be rendered, e.g. maybe like

[cite: @Jones2018 :year]

or (as I think was proposed at one point):

[cite:author @Jones2018]

Again, maybe it's worth having some shortcuts here for the common=20
cases, but I think in general we want to try to avoid=20
proliferation of basic citation commands.  So for that reason I=20
think we should just stick with the 'cite'/'(cite)' distinction as=20
the two basic commands, perhaps with a more=20
extensible/compositional syntax in each case for expressing the=20
variations on these two basic types of citation.

=2D-=20
Best,
Richard

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEgGDlsvLEBgbmTW4HmWlD4c9vpkYFAlrg1NMACgkQmWlD4c9v
pkbdiwf/U1YNCb3Eo+Kw5LSBR0LobHiS8W7yL9wo9vQQwWxkodniEXTVzaExhjy/
U+ISLZdffZ+2AiZD/hBRMlqTNYCZxjlv/PYA2IVu3f9fOXyisHuRdC/XI2A8pQaG
KcU4pSco6TTA1LyoFrxTsUQt9SBbYQ0g4tC+J5AN5qvDv1VEbRaboqnfoUdqTvye
vwP9ZSAYk4epXpwY3P/9Z/K+mBxZyJvTYKqtPAgYEgWixCA0bgnBDU23fZeqvBmO
a5k6nEbUdzraI02wQHXI5TxhLto+0x11FQBDQVhB8Yp8w9FL+mHVWgvbnTSj1BOt
k93LBUWhsbzSvsvzHKev8N6bavccZw==
=/VQD
-----END PGP SIGNATURE-----
--=-=-=--