`entry` type does not expose `container-title` to CSL

[trespaul]

When type is entry, it seems its parent's title doesn't get translated to CSL container-title. MWE:

#bibliography(
  full: true,
  style: bytes("<?xml?>
    <style class='in-text' version='1.0'>
      <info>
        <title>test</title>
        <id>none</id>
      </info>
      <citation>
        <layout>
          <text value='citation' />
        </layout>
      </citation>
      <bibliography>
        <layout>
          <group>
            <text value='Author: ' />
            <names variable='author' />
      
            <text value='; Title: ' />
            <text variable='title' prefix='[' suffix=']' />
    
            <text value='; Container-Title: ' />
            <text variable='container-title' prefix='[' suffix=']' />
          </group>
        </layout>
      </bibliography>
    </style>
  "),
  bytes("
    smith2018:
      type: entry
      title: Phenomenology
      author: Smith, David Woodruff
      date: 2018
      editor: Zalta, Edward N.
      url: https://plato.stanford.edu/archives/sum2018/entries/phenomenology/
      parent:
        type: reference
        title: The {Stanford Encyclopedia} of {Philosophy}
        publisher: Metaphysics Research Lab, Stanford University
        edition: Summer 2018

    test_entry:
      type: entry # works if changed to e.g. anthos
      title: Test Entry
      author: Me
      date: 2025
      parent:
        type: reference # this can be changed to book etc., still doesn't work
        title: The Reference Container
        editor: Also Me
  ")
)

I would expect any parent's title to be automatically put into container-title in almost all cases, so it's strange that there's an exception for entry.

[PgBiel]

Note that CSL has other title kinds, so Hayagriva has to decide which to use. In the reference case, I believe volume-title should work based on the code.

https://github.com/typst/hayagriva/blob/799cfdcc5811894f62949a63b155878e2f30b879/src/csl/taxonomy.rs#L384-L396

[trespaul]

Unless I'm mistaken, volume-title is not used for the title of the container. According to the spec:

Title of the volume of the item or container holding the item;

Also use for titles of periodical special issues, special sections, and the like".

I.e., one might want to reference an encyclopedia entry like so:

Author, M. 1997. Trains. In Editor, A. Encyclopædia Britannica, 10th ed., vol. 5: Methods of Transport. London: Britannica Ltd.

Here, container-title is "Encyclopædia Britannica" and volume-title is "Methods of Transport".

I'm building up a CSL style and have also been cross-referencing how Zotero translates their fields to CSL fields, and their encyclopediaTitle (publicationTitle) becomes container-title (and they don't expose volume-title at all actually).

I'm still busy with the more niche entry/record types, but I have not yet come across a type in which the container title is not to be put in container-title.

Besides, (if you'll bear with me getting a bit philosophical; this got a bit long, sorry) why does Hayagriva limit which fields can be on which record type? If I put a field on an entry, shouldn't it be up to the specific CSL style to determine which fields to display and which to ignore? I can't think of a different example in Hayagriva right now, but I (and many others) ran into a similar issue years ago because Zotero decided that chapters in books etc. cannot have their own DOIs, even if they do in the real world.

I would expect a reference processor to be entirely type-neutral. I don't see why the type of record would lead to any assumptions about its structure, except for assumptions that provide shorthand for users (like Hayagriva currently assumes a default parent type). Who's to say, e.g., my conference can't have an illustrator or translator or host? Or in the case something really doesn't make sense, like a video director on a dictionary entry, I would expect the director field to be rendered if the CSL style uses it, and if it shows up incorrectly in the bibliography, that's user error (and the answer to their support question would be straightforward: "oh, the director field is actually for film directors — use the X field for Y persons" as opposed to trying to explain that the processor has decided that actually your conference can't have an illustrator or translator, even though there were actually literally a live illustrator and live interpreter at your conference).

If there are hidden assumptions about which fields are valid, it should be documented thoroughly, because Hayagriva does not show all the available fields like in a GUI reference manager. But this would be tedious for users if they run into unexpected behaviour and have to open documentation to check if they've filled out the right fields for the record type. If behaviour is consistent for each record type, then a list of definitions for the fields (as currently exists) is sufficient.

[trespaul]

I suspect #300 and other similar issues may be the result of the same problem.