jjmccollum / context-sbl

Society of Biblical Literature (SBL) style files for ConTeXt
2 stars 0 forks source link

suppbook, incommentary, inlexicon portability #2

Closed denismaier closed 3 years ago

denismaier commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

make title an alias for the set ``

What do you mean with "set?

jjmccollum commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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

jjmccollum commented 3 years ago

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.