From mboxrd@z Thu Jan 1 00:00:00 1970 From: Melanie Bacou Subject: Re: Citation syntax: a revised proposal Date: Fri, 20 Feb 2015 00:27:24 -0500 Message-ID: <54E6C5BC.10906@mbacou.com> References: <87k2zjnc0e.fsf@berkeley.edu> <87bnkvm8la.fsf@berkeley.edu> <87zj8co3se.fsf@berkeley.edu> <87ioezooi2.fsf@berkeley.edu> <87mw4bpaiu.fsf@nicolasgoaziou.fr> <8761aznpiq.fsf@berkeley.edu> <87twyjnh0r.fsf@nicolasgoaziou.fr> <87oaopx24e.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOg7q-0001ua-Rg for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 00:27:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOg7n-00020C-Jx for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 00:27:42 -0500 Received: from plane.gmane.org ([80.91.229.3]:38986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOg7n-000204-AC for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 00:27:39 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YOg7l-00064g-Sb for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 06:27:38 +0100 Received: from c-69-136-235-188.hsd1.dc.comcast.net ([69.136.235.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2015 06:27:37 +0100 Received: from mel by c-69-136-235-188.hsd1.dc.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2015 06:27:37 +0100 In-Reply-To: <87oaopx24e.fsf@berkeley.edu> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Just want to point out RMarkdown/Pandoc implementation of bibliographies and citations here http://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html One useful option is a `csl: biomed-central.csl` option in the preamble. --Mel. On 2/19/2015 12:06 PM, Richard Lawrence wrote: > Nicolas Goaziou writes: > > >> I wasn't clear. Subtype should be interpreted by back-ends means it has >> no impact on syntax. However a user should be able to dictate what the >> back-end should do with it, much like `org-add-link-type'. >> >> A new library, e.g. "org-cite.el" would provide all the tools necessary >> to build custom handlers for subtypes. Thus, power users can do whatever >> they want with cite objects. > > Ah, OK, I think I see...so this is basically the second option, with > users interpreting subtypes via a separate protocol, instead of via > filters. Right? > > What about this concern, then? > >>> But that kind of situation is exactly what the extra-info part >>> of the syntax is for; in that case, >>> >>> [cite/my-subtype: ...] >>> >>> would just be an exceptional way of writing >>> >>> [cite: ...]{:type my-subtype} >>> >>> or whatever. I'm not totally convinced yet that the convenience of the >>> former is worth blurring the line between `stuff that definitely works >>> on all backends' and `stuff that might not work on all backends'. > > >>> We have already seen a couple of examples in this thread of properties >>> that one might want to specify in a backend-agnostic way: >>> - special-case capitalization >>> - user-defined type/command/label/etc. >>> >>> Other things one might want to do include: >>> - indicating when a citation should be placed in a footnote >>> - extracting arbitrary bibliographic field(s) >> >> I disagree. These properties should be associated to the subtype. >> Having two places to set them is asking for trouble. >> >> IMO, there is little incentive to define a set of options for a single >> use. Creating a dedicated subtype /once/ makes more sense. > > Hmm, OK. I agree in the abstract, but as far as I understand what a > `subtype' is, I am not sure how well that idea applies in this case. If > a subtype encompasses a set of options, and the only way to specify > those options is by specifying a subtype, then changing one option means > changing to a whole different subtype, even when you want all the other > options to stay the same. That will lead to a lot of duplication in > subtypes. That in turn could lead to a lot of author frustration: now I > have to remember exactly which subtype encompasses the set of options I > need for this particular citation. > > Look at the LaTeX citation commands. There, you have a different > `type'/command for every possible combination of options, and there are > many commands because there are many options to deal with special cases. > In my mind, that is the wrong abstraction to emulate. You end up making > trips to the manual to figure out exactly which one you need. > > To me, it makes much more sense to have a basic citation command, and > then a way to `answer some questions' to toggle various things related > to special-case behavior, like: > - should it be footnoted? > - should it have special-case capitalization? > - should it cite the volume? > - should it deal with brackets in a context-sensitive manner? > - should it use the genitive form of the author's name? > - ... > > I would guess that the answers to these questions *usually* have nothing > to do with one another, so it makes sense to be able to answer them > independently, and change your answer to one independently of your > answers to the others. That's why I would want to be able to write > > [cite: ...]{:footnoted t :capitalized t :author-title t ...} > > rather than > > [cite/footnoted-capitalized-author-title: ...] > > In the former case, if I later figure out I don't need the `:capitalized > t' part, that's easy to remove without changing the other options. In > the latter case, I need to remember what name I gave to the subtype for > footnoted-but-not-capitalized-author-titles, or whatever. > > I don't know; maybe this is not a very serious concern in practice. > Maybe, in practice, you generally only need one `special case' option at > a time, so the number of subtypes will be small. Still, I do not feel > comfortable declaring *in advance* that that is so; and the bewildering > array of LaTeX citation commands is at least some evidence that it > isn't. Thus, I am in favor of allowing the greater flexibility provided > by the former syntax. > > That's not to say that subtypes never make sense: you are quite right > that sometimes options *should* be grouped together into a subtype, > namely, when it makes sense to set or remove them *conjointly*. But > that means the two syntaxes above actually have different purposes, even > though for some range of cases either one would do the job. > > So although I would not be in favor of *only* allowing > > [cite/subtype: ...] > > I am basically OK with allowing this if we also allow the {:key val ...} > syntax. Still, the /subtype form is not needed if we also allow > > [cite: ...]{:type subtype} > > Best, > Richard > > > -- Melanie BACOU International Food Policy Research Institute Snr. Program Manager, HarvestChoice E-mail m.bacou@cgiar.org Visit www.harvestchoice.org