Re: wip-cite status question and feedback

[Denis Maier <denis.maier.lists@mailbox.org>]

Hello,

Am 25.04.2020 um 18:19 schrieb Nicolas Goaziou:
> Hello,
>
> I cannot answer all open questions as the thread would spread too thin.
> So, I'll try to subsume where Org is at the moment, and what need to be
> decided.

Thanks for the suggestion. Looks like a pretty solid approach.

> There is a limitation for prefixes and suffixes: they cannot contain
> semicolons or closing square brackets. I'm not sure it is worth
> implementing some character escape mechanism, tho.

What about using quotes if someone needs this, like so [cite: "common 
prefix; still common prefix"; pre @key post; pre @key2 post; common 
suffix] ?


>
> Now with styles:
>
>    [cite/style: ...]
>    [cite/style/substyle: ...]
>    [cite/mycitationprocessor/fullcite: ...]
>    [cite/foot/text: ...]
>    [cite/style/substyle/subsubstyle/OMG: ...]
>
> The forward slash separator gives us local citation style and a name
> space. There's no limit on the depth of sub-styles. However style
> strings are limited to alphanumeric characters only.

Good solution.

> I assume [cite:...] is the default citation style, defined at the
> citation processor's level. Styled citations override locally the
> default style. Again, a processor not handling a given style is expected
> to fallback to default style.
>
> As a consequence, there is no special syntax for "author-in-text" style.
> But we can suggest one for back-end processors. We might want to stick
> to the most complete one, BibLaTeX, IIUC, and /require/ processors to
> support, at least:
>
>    [cite/text: ...]
>    [cite/paren: ...]
>
> With this bare minimum, we ensure documents are somehow portable between
> processors, and, therefore, export back-ends.
>

> Hopefully we can
> move onto the next step: how should we interface citation processors and
> Org?
>
> First, I think we agreed on the BIBLIOGRAPHY keyword, with the following
> syntax:
>
>    #+BIBLIOGRAPHY: file
>    #+BIBLIOGRAPHY: "file"
>
> There can be multiple BIBLIOGRAPHY keywords in a document (and
> equivalent node properties). Also, I think Org should support a global
> variable, e.g., `org-citation-default-bibliography'.
>
> I also think we defined a keyword to insert a bibliography:
>
>    #+PRINT_BIBLIOGRAPHY: ... options ... (may be specific to citation processors)

Looks good.

>
> - Export ::
>
>    In this case, we may want to allow multiple processors for various
>    export back-ends. I thought about declaring active processors in
>    a document with a keyword, e.g.,
>
>      #+CITATION_PROCESSOR: org-ref :default-style foo :back-ends (latex)
>      #+CITATION_PROCESSOR: citeproc :default-style bar
>
>    and with a global variable, e.g., `org-citation-export-default' which
>    could be, e.g.,
>
>      '((default :defaut-style "authoryear" :back-ends (latex)))
>
>    but could become, with appropriate libraries
>
>      '((org-ref :defaut-style "authoryear" :back-ends (latex))
>        (citeproc-org :default-style "style-file.csl" :back-ends nil))
>
>    where more specialized back-ends are used first. Note that `latex'
>    would mean `latex' and derived back-ends, e.g., `beamer'.
>
> Well, that's all for now. Again, I am not a citation specialist, so
> I need feedback. Let's keep the ball rolling!

Does that mean you'll be able to have the same or different processors 
for different backends? (Like biblatex for latex and citeproc-el for 
ODT/HTML/etc.; or when you need identical output you can use citeproc-el 
even for latex?)

Again, thanks for all your work here.

All the best,

Denis