Re: Expanding how the new cite syntax is used to include cross-references - thoughts?

[John Kitchin <jkitchin@andrew.cmu.edu>]

[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]

On Wed, Aug 11, 2021 at 10:32 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> On Wed, Aug 11, 2021 at 9:53 AM John Kitchin <jkitchin@andrew.cmu.edu>
> wrote:
>
> > > #+CAPTION: This is the caption for the next figure link (or table)
> > > #+NAME:   fig:SED-HR4049
> > >
> > > [[./img/a.jpg]]
> > >
> > > Or some other metadata on the target?
> >
> > I don't think metadata on the target helps with the cases described
> > above, you can reference a label in different ways at different times to
> > get different meanings.
>
> OK, this clarifies a key piece then.
>
> I agree then: target metadata alone isn't enough.
>
> So I see two options:
>
> 1. per my original response, allow optional typed internal links; e.g.:
>
> [[fig/foo:file]]
>

This is a bad idea to me. It is only a fuzzy link (what you call a typed
internal link) if no one has defined it as an external link. As soon as
that happens, then you will lose the export behavior defined for fuzzy
links, and get the behavior defined by the export function. The syntax for
these is the same (I guess a fuzzy link must be wrapped in [[ ]], but an
external link may also be wrapped that way). I don't see a  way to
differentiate these.

>
> To be clear, with this idea, I'm suggesting an alignment between
> external links (which already have similar types) and internal (which
> do not).
>
> IUC, org-ref is using *external* link types (not internal links) to
> make these distinctions?
>

Yes, org-ref uses external links, defined by org-set-link-parameters.


>
> 2. extend citations, per your idea here, which to me means the
> org-cite code would need to be revised and expanded to handle both
> cross-references and citations, but do so distinctly.
>

I don't think so. You only have to extend them where you want to have the
capability. org-cite can stay a citation only body of code, and if you want
cross-references too you just use my processors, or write one that does
what you want.


>
> E.g. an export processor like oc-csl would need to handle these
> cross-references in that code, but pass the citations per se to the
> citeproc-el backend, which should not need to worry about
> cross-references.
>

Again, not necessarily, this is handled in the export processor, and it can
differentiate which citations are sent to oc-csl and which are handled
differently based on the style.


>
> Likewise, as a front-end developer, I don't want to deal with
> cross-references at all, so I should be able to ignore them in my
> insert and follow processors, in the same way you would need to be
> able to include support for them.
>

You don't have to. Your processors should fail gracefully in any case,
because you just cannot control what people will do with the styles.


>
> And activate processors would need to be updated to distinguish them
> somehow.
>

Right now this just looks like

(when (org-ref-cite-ref-p reference) ...)

My activate processor just runs a bunch of functions and those functions
can do nothing if needed.


> Right?
>
> It seems to me 1 is the easier path, both practically and
> conceptually, unless I'm still missing something (which is certainly
> possible).
>

The biggest issue with 1 is I don't think it is possible to differentiate
internal typed links from external links because they use the same syntax.
It would be very difficult to support and troubleshoot a scenario where the
same syntax shows different behavior depending on whether an external link
is defined or not. Finally, it is so close to what org-ref already does, I
think it is too tricky to differentiate [[ref:label]] from [[ref/:label]],
etc.

Maybe these links would look different enough (as external links) that it
would be really clear you were not using org-ref.

ref/:@label
ref/eq:@label
ref/page:@label
ref/name:@label
ref/c:@label
ref/C:@label

 However, this doesn't support using prefix/suffix text, which is one of
the main reasons the cite syntax came to be.


> Bruce
>

[-- Attachment #2: Type: text/html, Size: 6077 bytes --]