From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Citation syntax and ODT Date: Mon, 23 Feb 2015 09:15:45 -0800 Message-ID: <87twycsg5a.fsf@berkeley.edu> References: <87zj85s1vf.fsf@berkeley.edu> <54EAC71A.6080502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPwcd-0003oh-DU for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 12:16:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPwca-0000vs-2z for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 12:16:43 -0500 Received: from plane.gmane.org ([80.91.229.3]:60857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPwcZ-0000vi-Oe for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 12:16:40 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YPwcX-0001tC-TW for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 18:16:38 +0100 Received: from c-67-169-117-151.hsd1.ca.comcast.net ([67.169.117.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 18:16:37 +0100 Received: from richard.lawrence by c-67-169-117-151.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 18:16:37 +0100 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 Vaidheeswaran writes: >> We haven't really discussed how styles should be specified (yet), or the >> formatting of bibliographies. But we have been discussing a syntax that >> lets you specify those formatting properties which commonly differ >> between individual citations. > > IMO, it is better to roll out the citation feature WITHOUT any > formatting properties. The specific formatting chosen is at the mercy > of capabilities of the export backend or citation engine it works > with. I still don't understand what it would mean for an exported citation not to have any formatting properties. If I write a citation like [cite: See @Doe99 p. 43] how should that be represented in an ODT/HTML/etc. document without any formatting? Just copy the text verbatim into the output...? According to the proposal we've been discussing, a citation like this is an in-text (as opposed to parenthetical) citation with a prefix and a suffix, and thus should render something like See Doe (1999, p. 43) or See Doe [1, p. 43] etc. where the choice between those options would depend on the citation style. I agree that there is an issue about those styles; it seems likely that Org will have to be fairly flexible about those, perhaps falling back to a default if the requested style is not available on a particular backend. (Probably it would be useful, too, to be able to separately specify styles for LaTeX vs. non-LaTeX backends.) But whatever style is chosen, I would still think that the fact that the citation is in-text rather than parenthetical, and that it has a prefix and suffix, should be represented in the output. Perhaps not all backends will be able to do even that at first -- that's fine -- but I think that should be treated as a bug to be fixed at some point, not as acceptable behavior. Do you disagree? > Do you think of a scenario where: > > 1. Org acts like a citation engine. (A self-contained Org-ecosystem) > > 2. Org-backends interfaces with a 3rd-party engine (like pandoc, > zotero, JabRef) > > If the current effort is to build (1), ODT backend will have no reason > to complain. > > If the effort is geared more towards (2), the ground reality is that > JabRef's style catalog is not as extensive or mature as, say Zotero's > or LaTeXs. The implication is that the PDF document produced via the > LaTeX document WILL DIFFER IN STYLE from the PDF document produced via > the ODT backend. Yes, that is inevitable, and fine, I think. But as far as I can tell, this is an issue of the document-level style selection (Chicago vs. APA vs. ACM...), not an issue of the more fine-grained differences between e.g. parenthetical and in-text, or having a prefix or not; these fine-grained differences are (mostly) independent of the style, and I think they should be represented in the output. > I am imagining something along a mix of (1) and (2), with more initial > thrust in favor of (2). Me too. I am guessing we will want to `bless' one or two external tools, both on the side of reference databases (perhaps Bib(La)TeX and Zotero, in addition to Org-bibtex) and on the side of formatting processors (perhaps Bib(La)TeX and citeproc-js or zotxt). We can then make it clear that exporting citations to a particular format requires these tools, much like exporting an Org document to PDF requires a TeX installation. > I am only saying that the people who work on the specification take > sufficient care to TEMPER what a user can reasonably expect when he > moves between different backends. > > My primary motivation is to draw the attention of people like you (who > are hammering out the syntax) to factor the case of a backend-like > ODT. I agree, this is important. Unfortunately, like I said, I don't personally know much about ODT, so I need to rely on people who know more about it (like you) in order to factor in the details. > My focus in not so much on syntax-richness but on quick roll-out of > citation support. ... My only suggestion is to MERELY TO TAKE > COGNIZANCE of the need for bells-and-whistles without the current > momentum being dragged down by an attempt to arrive at a consensus > that will keep all parties happy. That is fair enough, and I agree. I would just add that we've worked pretty hard to come up with a list of features that are important enough that they should be supported by all backends. While we might not be able to implement them all on all backends right away, my hope is that they eventually will be fully supported. But you're right, let's not have the perfect be the enemy of the good in the meantime. Best, Richard