emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: citations: org-cite vs org-ref 3.0
Date: Wed, 23 Mar 2022 23:30:22 +0700	[thread overview]
Message-ID: <t1fhv0$798$1@ciao.gmane.io> (raw)
In-Reply-To: <871qytlf49.fsf@nicolasgoaziou.fr>

On 23/03/2022 06:52, Nicolas Goaziou wrote:
> Max Nikulin writes:
> 
>> Another point is more serious. Besides citations there are internal
>> cross-references. Org supports them but only in a rudimentary form.
>> Actually cross-references are similar to citations in the sense that
>> they can have style, prefixes and suffixes, and their appearance
>> depends on target properties. Another feature is grouping. However
>> cross-references should not be handled by citation backends, they
>> require different handlers. Unfortunately there is no way to define
>> custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]".
> 
> There is too little information here for me to understand what
> cross-references (or grouping) are, or why they would require different
> handlers. In any case, if such thing are deemed necessary in Org Cite,
> one can always start a new thread.

Frankly speaking, for me it was enough just to use available LaTeX 
commands. I never thought about corner cases, but feature request 
requires such analysis.

By grouping I mean the existing feature of org-cite: several keys with 
common prefix and suffix, items within such group may be sorted.

Citation handlers obtain information necessary for formatting from a 
bibliography database. For cross-references such additional info should 
be pulled from other parts of the same document. There is no point to 
mix the code for both cases withing the same handler, it is better to 
combine independent handlers and to allow each type to have alternative 
implementations. I agree with those who say that cross-references and 
citations are rather independent when implementation is considered.

Judging from the description, org-ref (with org-refproc as an optional 
addition) does the job taking advantage of multiple custom link types 
for the same actual standard internal link target.

Sphinx has a feature that is an interesting border case between internal 
cross-references and external links (almost citations). Readthedocs 
sites host mapping tables for python packages. It is possible to fetch a 
file that associates e.g. anchors and section names. In generated docs 
anchors (similar to custom_id values) are replaced by section names and 
link target points to particular location in the external file.

Nicolas, concerning a new thread, I have an impression that you are busy 
with over activities since you are participating in discussions not so 
frequently. So I am unsure at which moment it is appropriate to raise 
such question that otherwise may just be buried in the list archive. 
Sometimes I am in doubts if an idea deserves a dedicated thread or 
initial feedback may be received from a related rather generic topic.

>> To assign additional properties, info "(org) Links in HTML export"
>> https://orgmode.org/manual/Links-in-HTML-export.html recommends usage
>> of "#+ATTR_HTML", but such technique has several issues:
> 
> This is a different issue. Citations are not link, and have a fixed set
> of properties.

Outside of Org, citations are links. Along with cross-references they 
worked before appearance of the web. To be recognizable on paper they 
may have a bit special form. An author may choose what will appear in 
the text: page number, section number, or section text. For HTML links 
page number option is not meaningful.

Within Org citations look like generalized links: a citation may have 
multiple targets, they have more properties: prefixes, suffixes 
(including common ones), style, and locators. However there is no 
description.

Internal links in Org (built-in ones without additional packages) are 
more limited than full-fledged cross-references. When exported they have 
the same form.

I consider fixed set of properties as a problem. At first I tried to 
draw attention to additional link attributes. Then I realized that 
block-level elements may have arbitrary attributes. It would be a great 
feature to have some syntax construct to assign attributes for 
particular inline object. People actively use link types as an 
additional property, but it gives just one degree of freedom. Sometimes 
more parameters are required and abusing link types means combinatorics 
explosion. Encoding extra properties inside link targets sometimes is 
enough (as in org-ref) but some times it is inconvenient.

Advantages of arbitrary attributes for inline objects for links:
- Within the same paragraph only part of links may be marked as 
"nofollow noopener" during exporting to HTML.
- Each link may have its own title.
- Link types similar to org-ref cross-references ("pageref", "nameref", 
"eqref", etc.) becomes an extra attribute while link type and link 
target remains the standard one for Org (heading text, custom id, name 
attribute).

For citations some values may be passed to specific citation backend 
overriding default value derived from style. It should be similar to 
babel header arguments specific to particular language or export options 
for particular format.

Leaving groups aside, attributes for inline objects may be a convenient 
extension.



  reply	other threads:[~2022-03-23 16:40 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal
2022-03-20 13:19 ` Nicolas Goaziou
2022-03-20 14:08   ` Vikas Rawal
2022-03-20 14:38     ` Bruce D'Arcus
2022-03-21  0:31   ` John Kitchin
2022-03-21  1:39     ` Timothy
2022-03-21  8:16       ` Dominik Schrempf
2022-03-21 11:51         ` Bruce D'Arcus
2022-03-21 12:34           ` Dominik Schrempf
2022-03-21 12:52             ` Bruce D'Arcus
2022-03-21 13:05               ` Dominik Schrempf
2022-03-21 13:24                 ` Bruce D'Arcus
2022-03-23 21:27                 ` Nicolas Goaziou
2022-03-23 21:53                   ` Bruce D'Arcus
2022-03-23 22:04                     ` Nicolas Goaziou
2022-03-23 22:47                       ` Bruce D'Arcus
2022-03-24 10:04                         ` Dominik Schrempf
2022-03-21 12:19       ` John Kitchin
2022-03-21 12:42         ` Bruce D'Arcus
2022-03-21 14:06           ` John Kitchin
2022-04-19 22:37             ` Bruce D'Arcus
2022-03-21  3:27     ` Vikas Rawal
2022-03-21 11:51       ` John Kitchin
2022-03-21 17:20         ` Vikas Rawal
2022-03-25 15:53         ` Max Nikulin
2022-03-27 15:33           ` John Kitchin
2022-03-27 15:44             ` Vikas Rawal
2022-03-25 17:10         ` Max Nikulin
2022-03-26 12:41           ` Bruce D'Arcus
2022-03-27 19:40           ` John Kitchin
2022-03-28 12:34             ` Max Nikulin
2022-03-28 13:16               ` Bruce D'Arcus
2022-03-29 15:22                 ` Max Nikulin
2022-03-29 16:14                   ` Bruce D'Arcus
2022-03-30 13:50                     ` Denis Maier
2022-03-31 15:10                     ` Max Nikulin
2022-03-31 17:27                       ` Bruce D'Arcus
2022-04-02 11:41                         ` org-cite, CSL styles and space before citation Max Nikulin
2022-03-30 21:43                   ` citations: org-cite vs org-ref 3.0 John Kitchin
2022-03-21 12:59     ` juh
2022-03-22 13:03       ` indieterminacy
2022-03-23 21:06     ` Nicolas Goaziou
2022-03-27 17:00       ` John Kitchin
2022-03-27 23:17         ` Bruce D'Arcus
2022-03-21 14:40   ` Max Nikulin
2022-03-21 15:19     ` Bruce D'Arcus
2022-03-21 17:00       ` John Kitchin
2022-03-25 15:21         ` Max Nikulin
2022-03-22 14:41       ` Max Nikulin
2022-03-22 17:20         ` Bruce D'Arcus
2022-03-23 12:44           ` Max Nikulin
2022-03-23 14:39             ` Bruce D'Arcus
2022-03-23 15:26               ` Eric S Fraga
2022-03-23 17:17               ` Max Nikulin
2022-03-23 22:50                 ` Bruce D'Arcus
2022-03-26 19:08               ` M. Pger
2022-03-22 23:52     ` Nicolas Goaziou
2022-03-23 16:30       ` Max Nikulin [this message]
2022-03-23 23:04         ` Nicolas Goaziou
2022-03-25 16:30           ` Max Nikulin
2022-03-27 15:38           ` John Kitchin
2022-03-27 23:18             ` Bruce D'Arcus
2022-03-20 13:32 ` Bruce D'Arcus
2022-03-20 13:42 ` Ihor Radchenko
2022-03-20 18:12   ` Thomas S. Dye
2022-03-20 20:13     ` Dominik Schrempf
2022-03-20 20:30       ` Vikas Rawal
2022-03-20 20:34       ` Bruce D'Arcus
2022-03-20 22:10         ` Dominik Schrempf
2022-03-20 19:44   ` Bruce D'Arcus
2022-03-20 21:14     ` chris
2022-03-21 14:21       ` John Kitchin
2022-03-21 14:10     ` John Kitchin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='t1fhv0$798$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).