suppbook, incommentary, inlexicon portability

[denismaier]

Is there a way to make these types more portable between styles? I know SBL wants special formatting for these cases, but what happens if you switch to a different style that doesn't know those types? Could using @inbook with a field subtype be an option. In other styles, those entries would then just fall back to @inbook.

[jjmccollum]

For the sake of completeness, I would add to this the @inreference category. Handling special processing by reading the subtype field would probably work without any trouble for @inreference, @incommentary, and @inlexicon, and it would definitely trim some otherwise redundant lines of code in publ-imp-sbl.mkvi. The @suppbook category would be a bit trickier, however, as it doesn't require title or pages fields (both of which are required for the other categories mentioned here), and its typesetting for list entries is thus fundamentally different. Even with a subtype field, I'm not sure how compatible this type of entry would be with other styles.

But more to the point, there is an even more fundamental obstacle to portability. In an effort to simplify category definitions and the handling of "nested entries" (e.g., an article in a book in a multivolume collection) more elegant, I replaced fields like booktitle, bookauthor, bookeditor, maintitle, mainauthor, maineditor with cross-reference fields (bookxref, incollectionxref, collectionxref). This means that (at least at this stage of development) @inbook entries that work for other renderings will not work for the SBL rendering and vice-versa. Ensuring backwards compatibility would certainly make things more convenient, but I think it would also demand more time and effort than I am able to give right now.

[denismaier]

The @suppbook category would be a bit trickier, however, as it doesn't require title or pages fields (both of which are required for the other categories mentioned here), and its typesetting for list entries is thus fundamentally different. Even with a subtype field, I'm not sure how compatible this type of entry would be with other styles.

I'd assume people having these like regular inbook entries in their databases and a subtype would then change the formatting. I'll have to take a deeper look into the code to see if that is possible. (Honestly, I think this rule is quite bizarre and those entries should be just regular in book entries, but who am I to decide....)

I replaced fields like booktitle, bookauthor, bookeditor, maintitle, mainauthor, maineditor with cross-reference fields (bookxref, incollectionxref, collectionxref). This means that (at least at this stage of development) @inbook entries that work for other renderings will not work for the SBL rendering and vice-versa

Why do you use different xref fields for each case? Can't you use a generic xref field? (I don't know about context, but in biblatex you can define inheritance schemes per type.)

Also, can this special behaviour for nested entries be made optional?

[jjmccollum]

For @suppbook, maybe I could do this: add supptype field to the @inbook category, make title an alias for the set { title, suppbooktype} in this category, and make pages an alias for the set {pages, suppbooktype}. Since both sets are still required, we need to have either a title and pages combination or suppbooktype. Would that make sense?

I specify distinct xref fields because some categories have multiple required cross-references, and most have multiple optional cross-references. The @review category, for instance, has two required cross-references: one to the book or volume being reviewed (bookxref = {bookxref, incollectionxref}), and one to the journal publishing the review (journal = {journalxref, journal, journal}; here, I did allow backwards compatibility for users specifying the journal within the lower-level entry, but the preference is still for a cross-reference to a @journal entry).

It looks like biblatex does have related and relatedtype fields that could come close to serving this function, but presently, biblatex doesn't allow us to specify different relatedtype values for each tag in the related list (https://github.com/plk/biblatex/issues/475).

[denismaier]

I see. FWIW, biblatex uses crossref for inheritance and related for relationships, say crossref would get data from the parent entry, related would point to the item being reviewed.

[denismaier]

make title an alias for the set ``

What do you mean with "set?

[jjmccollum]

Sets are used in category definitions in the .lua files for specifications. Here's the explanation in publ-impl-sbl.lua (and the corresponding files for other specifications):

-- A set returns the first field (in order of position below) that is found
-- present in an entry. A set having the same name as a field conditionally
-- allows the substitution of an alternate field.

[jjmccollum]

Looking over Appendix B of the biblatex documentation (https://ctan.math.illinois.edu/macros/latex/contrib/biblatex/doc/biblatex.pdf), I found the following mappings that would be useful for our purposes:

• in @inbook and @suppbook (which I realize now is a native category in biblatex) entries with a crossref to a @book, the author and title fields of the book get mapped to the bookauthor and booktitle fields;
• in @book entries with a crossref to a @mvbook, @mvreference, or @mvcollection, the author and title fields of the multi-volume book get mapped to the mainauthor and maintitle fields

Assuming that ConTeXt implements the biblatex inheritance rules (and I don't know for sure if it does), then I could at least make some field name changes to support this convention. Doing this for @inbook-@book inheritance wouldn't be too hard. Same for @book-@mvbook inheritance, although I'd have to rename some categories (I followed the convention of other ConTeXt specifications, which don't support @mvbook, but seem to call it @collection instead). But it doesn't look like a similar inheritance mechanism is in place for the @review category, so I'm not sure what to do about that.

[jjmccollum]

Okay, a brief update on this, as I've had a chance to make some significant updates in this direction today:

• I've collapsed the @incommentary and @inlexicon categories to the @inreference category, which is native to biblatex (I've added an entrysubtype field to the category to allow for values like incommentary and inlexicon, but at the moment, such distinctions are not used anywhere.)
• I've changed all instances of bookxref, incollectionxref, and collectionxref fields to crossref (or xref) to support the biblatex cross-referencing convention. This occurs in the usual relationships (e.g., @inbook to @book, @incollection to @collection), but I've also included it for similar relationships seemingly not covered by default in biblatex (e.g., @review to @book, though this might be better encoded through the related and relatedtype fields; I can revisit it as needed).
• I tentatively plan to leave the @suppbook category in place, as it is natively supported by biblatex.
• I intend to add support for several native biblatex categories not currently supported, such as @reference, @mvreference, @mvbook, and @mvcollection, although many of these will likely just be implemented as aliases of existing categories.

[jjmccollum]

With today's commit, I've added support for the remaining basic biblatex entry types used by biblatex-sbl. I consider this issue closed for now.