From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iECECIxNO2Id+QAAgWs5BA (envelope-from ) for ; Wed, 23 Mar 2022 17:40:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 0CDhAIxNO2L58wAAG6o9tA (envelope-from ) for ; Wed, 23 Mar 2022 17:40:44 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 837F32A63C for ; Wed, 23 Mar 2022 17:40:43 +0100 (CET) Received: from localhost ([::1]:55164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nX42M-0006jv-3o for larch@yhetil.org; Wed, 23 Mar 2022 12:40:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nX3sj-0005Jp-B6 for emacs-orgmode@gnu.org; Wed, 23 Mar 2022 12:30:45 -0400 Received: from ciao.gmane.io ([116.202.254.214]:38216) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nX3sg-0000xk-U1 for emacs-orgmode@gnu.org; Wed, 23 Mar 2022 12:30:44 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nX3sX-00029K-61 for emacs-orgmode@gnu.org; Wed, 23 Mar 2022 17:30:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: citations: org-cite vs org-ref 3.0 Date: Wed, 23 Mar 2022 23:30:22 +0700 Message-ID: References: <87wngosqvm.fsf@nicolasgoaziou.fr> <871qytlf49.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US In-Reply-To: <871qytlf49.fsf@nicolasgoaziou.fr> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648053643; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=pE0rZCUTrp/5tVTOdvReSb+/KoSX5ZKi2sydRCxBiTA=; b=Dnf9Wnoa6AOJzhndXfPmQsj5rFckjVuMAaPixVa5kaR/j3SNeTOlU333kPH4SCWwYcd/5z 7UwdJaZUIN8v3Pt358rjbgocsyg/Zo+/uhtuKsNlk5NfHCgUw3IPqhuGcB0Wz5hs8A9zJ6 FCKfI1ovGzM3F/Enq9RjbkLXTuMU0O6E8ggM1ZyMIX0jl7oQXMBAs/GUEu/6p4OebKuxj9 ZTTgIm9+kfVRRe3jJ7CWDRRU0tVoOEZOZH1IQmT+2Xz9hLhISls3T3KAsnHcVKfcQ43/F8 u8Jn2pPqTiJJy2Ng3YFrU6jbLaITsl3NKwYXst7fNzVlTMP03dQUGDOcTlpDbQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648053643; a=rsa-sha256; cv=none; b=mHeYwf4DmgtZmlurCTgTbXDWw2H050aFdK6yGMl3GHYXQIbMHukJkp48TokhMUbP5D8kXl sgn0fuTlqbW8eIw7iZj/6098cNESefCLH30uiUphraIrdz625WIVlIf4OncPsEQ2AlmRqS 8IUG9c8jHLlDoNxel8KF34DJnu2exaKjMYy7lSfItKcWoc0R0DlItZhp8KcmSTX7k1Ta3K e9F78NjjlH4GpsFuhwa+FvAlZ/GwG5lGCYYNY7Lt90bFN8Gj/A5ogku5X9DJAcyp4kCiH1 JyqzRRj75QTkDomGjiayf65NWgCZdEtnOpEuhRO5t23S3/YsZBEqnYF5gO/gyg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 2.31 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 837F32A63C X-Spam-Score: 2.31 X-Migadu-Scanner: scn0.migadu.com X-TUID: KU+QyIvv+N3A 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.