Add support for parent refid

[bdarcus]

I didn't initially know how to do this, but one possibility is to somehow access the parent via the Processor.bibliography field hash map.

But the wrinkle is the render methods are attached to the InputReference.

PS - some experiments with this and indexmap.

https://gist.github.com/bdarcus/aa667efd28266191c64093a86ba7b7f3

[denismaier]

Hmm, what about using a pre-processing step? Say, you have this initial input data:

doeArticle:
  author: 
    family: Doe
    given: John
  title: A very important book chapter
  pages: 1-20
  container:
    id: editedVolume

editedVolume:
  title: A edited volume
  editor:
    family: Smith
    given: Jane
  publisher:
    name: Whatever Press
    location: Wherever

Then, after a preprocessing step the data from the parent entry will be merged with the contained entry so that all data is in fact inline:

doeArticle:
  author: 
    family: Doe
    given: John
  title: A very important book chapter
  pages: 1-20
  container:
    id: editedVolume
    title: A edited volume
    editor:
      family: Smith
      given: Jane
    publisher:
      name: Whatever Press
      location: Wherever

editedVolume:
  title: A edited volume
  editor:
    family: Smith
    given: Jane
  publisher:
    name: Whatever Press
    location: Wherever

Now, you should be able to just use the methods attached to InputReference. Right?

With biber you can define some very sophisticated preprocessing steps and inheritance rules.

You could go even further and extract arbitrary pieces of data and make them reusable:

doe:
  author: 
    family: Doe
    given: John

smith:
  editor:
    family: Smith
    given: Jane

whatever:
  publisher:
    name: Whatever Press
    location: Wherever

doeArticle:
  author:
    id: doe 
  title: A very important book chapter
  pages: 1-20
  container:
    id: editedVolume

editedVolume:
  title: A edited volume
  editor:
    id: smith
  publisher:
    id: whatever

[bdarcus]

Yes; that's what I can't figure out.

The current code automatically parses the input, based on the model. I don't know how to tell it to resolve the references while doing so.

[denismaier]

Obviously, I don't know enough about Rust to help here, but isn't that a typical example of pipeline code where you load some data into a preliminary data structure, run some manipulations until you arrive at the data structure that you'll finally need? I'd assume something like this: In the raw input types, allow for parents with id or spelled data. Then, a function rawData -> expandedData will fetch the data from the parents (and change the types accordingly). Or do you mean something else?

[bdarcus]

The internal Rust modeling is just confusing me.

An issue with Rust, compared to lisp, perl, or javascript, is it's a strongly-typed language. So I have to account for every little detail. And article.author and book.author are not currently the same from the compiler POV, even if their contents are.

Citeproc-rs actually has custom deserialization code, which I'm trying to avoid too much of.

I'm sure there's a solution; just isn't apparent ATM.