Closed bdarcus closed 1 year ago
Thoughts on this @denismaier?
I'm not so worried about the details of the types, so much as getting the basic model right, since it touches a lot of the internal code, and is also pretty outward-looking.
This introduces a basic "hierarchical model" talked about for Zotero from the beginning, but never implemented.
From the chicago examples file:
hutt:
type: chapter
issued: "2011"
author:
family: Hutter
given: Michael
title:
main: Infinite Surprises
sub: Value in the Creative Industries
parent:
type: book
issued: "2011" # currerntly required in both places
title:
main: The Worth of Goods
sub: Valuation and Pricing in the Economy
editor:
- family: Beckert
given: Jens
- family: Aspers
given: Patrick
publisher:
location: New York
name: Oxford University Press
pages: 201-220
The goal is ultimately to be able to do this, though I don't know how ATM:
title: chapter
parent: doe21
I also added the start of identifiers.
I had to close this because of a mistake. See #95.
I think this looks reasonable.
With this maybe even a relatedItem
feature might become feasible?
Yes.
Split input model into structural classes, much like the very first CSL implementation.
Closes: #93
TODO:
NumOrStr
type for use in locators, etc.This is a pretty major internal change.
Like the very first CSL implementation, almost 20 years ago, this splits
InputReference
into different classes. ABook
type, for example, is aMonograph
, while aJournalArticle
is aSerialComponent
.Aside: I want to allow parents to be referenced by citekey, but I haven't figured out how to do that technically. My suspicion is it will take another major internal change; changing bibliography to be an
IndexMap
and writing some custom deserialization code. So it's not worth the hassle ATM.This also addresses some other internal issues I was unhappy with.
For example, the
render
traits now returnOption<String>
, and surrounding code is updated to better handle missing data.