From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vaidheeswaran C Subject: Re: Citation syntax and ODT Date: Tue, 24 Feb 2015 10:04:35 +0530 Message-ID: <54EBFF5B.30009@gmail.com> References: <87zj85s1vf.fsf@berkeley.edu> <54EAC71A.6080502@gmail.com> <87twycsg5a.fsf@berkeley.edu> <54EB6D6F.7060005@gmail.com> <87fv9wrz0s.fsf@berkeley.edu> Reply-To: vaidheeswaran.chinnaraju@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQ7Ak-0004SG-I7 for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 23:32:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQ7Ah-00028P-Bo for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 23:32:38 -0500 Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:39412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQ7Ah-00028K-0I for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 23:32:35 -0500 Received: by pablf10 with SMTP id lf10so32998797pab.6 for ; Mon, 23 Feb 2015 20:32:34 -0800 (PST) In-Reply-To: <87fv9wrz0s.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: Richard Lawrence Cc: emacs-orgmode@gnu.org On Tuesday 24 February 2015 04:55 AM, Richard Lawrence wrote: > Vaidheeswaran C writes: > >>> 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. >> >> 1. When you choose 'style' (Chicago etc.) wouldn't be one of in-text >> or parenthetical already chosen for you? Stated other way, is the >> choice between parenthetical or in-text document-wide or is it that >> one could intermix the two styles in the same document. > > These could be intermixed in the same document. The document-level > style determines how each type ultimately looks, but the choice of style > is (mostly) independent of using parenthetical vs. in-text citations. Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. >> 2. Citation processor like JabRef just takes a cite-key. It doesn't >> take a pre or post-note. So, the pre and post notes should be >> spliced in to the exported document by the elisp module that >> interfaces with the citation processor. > > Right. That's what I'm thinking, anyway. > >> If we are going to interface with a citation-processor, the best >> course of action would be to have someone first 'gauge' the >> capabilities provided by the citation processor and let that >> experience inform what Org should aspire to do. > > Yes. Other people have more experience with this than me. But based on > what Pandoc is able to do, I am pretty confident that everything that > has been proposed could be handled by a CSL processor like citeproc-js > (or Pandoc's own). The possible exceptions are the common prefix and > common suffix in a multi-work citation, which I imagine would be easy > enough to add to the output of the citation processor. In case of JabRef or bibtex2html, it is the 'command line' that is used for interfacing. In case of pandoc (I could be wrong here), the nature of interface is most likely to be a post-processing step on the produced document. This post-processing could happen as part of elisp hook or the document may be pipelined through a pandoc provided command-line tool. The point is that the choice of the citation processor will determine the nature of investments that need to be made in to the export module. JabRef or bibtex2html are really very poor cousins when compared to modern tools like Zotero. They would continue to remain poor cousins. So, I can imagine a scenario where JabRef or bibtex2html is relegated to the background (i.e., a contrib/ Org-module) while Zotero/Pandoc takes the prime-time (i.e., a lisp/ Org-module). In so far as zotero is concerned, there 'used to be' no standalone JS command-line environment or the toolchain was cumbersome. ---------------------------------------------------------------- I am reluctant to invest my time in citeproc-js or pandoc related integration work (so far as it concerns ODT exporter). Part of the reason for this relucatance is that setting up of the toolchain would involve more than a simple 'apt-get ...'. (My Debian is a bit old.) I am reluctant to work on JabRef integration unless I get an apriori commitment from the maintainers that it will be part of the Emacs distribution. > Best, > Richard > >