Re: Citation syntax and ODT

[Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>]

On Tuesday 24 February 2015 04:55 AM, Richard Lawrence wrote:
> Vaidheeswaran C<vaidheeswaran.chinnaraju@gmail.com>  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
>
>