Unsupported entry types

[moewew]

See https://tex.stackexchange.com/q/434281/35864 and force11/force11-sciwg#48 (comment). It seems that the label "unsupported" for the entry types of §2.1.3 Unsupported Types causes some confusion.

• Should that section be renamed?
• And if so, what would be a better adjective to describe these types?

[plk]

Probably "optional" types?

[moewew]

The name suggested in the TeX.SX question was 'non-standard' which sounds better than 'not-supported-by-the-standard-styles types'.

[plk]

Yes, that's better. I'm a bit absent at the moment for various reasons, you may have realised.

[moewew]

OK. I'll change the docs to 'non-standard' and will see if we need to lose a few more words about this.

Luckily there are no pressing issues at the moment, but there were a few things where a second opinion or pair of eyes would be appreciated once you are more available.

[moewew]

Done in df4444b comments are appreciated.

[katrinleinweber]

How about a "call-to action"-like sentence to funnel updates to the styles and drivers? What's 1, 2 or 3 resources that people who are interested to help expand those should go to?

[moewew]

What exactly did you have in mind? Unfortunately, there are not many "beginner's guides to biblatex style coding" that I know of. There are some decent introductions into using biblatex (https://tex.stackexchange.com/q/13509/35864) and some of them cover slightly more involved topics (I'm thinking of Dominik Waßenhovens second article in DTK 4/2008 - it's in German and about ten years old, so while its shows the general approach pretty well, details will have changed - mainly things got easier - I hope) but I think most people learn how to code biblatex styles by reading existing code and experimenting.

The thing is that updates to the standard styles are dangerous. We can't have something that is backwards incompatible (OK, we have had our fair share of backwards incompatible changes, but I'd really like and try not to have too many more - at least not in a way that could affect many users or high-level features).

The established stance has always been that we are sort of fine with the design decisions taken by PL and with the set of standard entry types. We might consider adding "interesting" new things if they need novel features. See for example #388. In the particular case of @standard things are even more complicated because people sometimes expect it to work quite differently from other more mundane entry types. And at least I don't want to have to decide the standard output for @standard.

[josephwright]

As @moewew says, the problem is that any 'beginners' stuff never takes people that far: you are basically doomed to get 'But I only want to change XXX', where XXX is something far from trivial/general.

Entirely agree on sticking if possible close to PL's original ideas, and really trying to avoid changing established styles.

[moewew]

biblatex 3.12 has been released. The changes discussed there have thus become official. @software and friends are now listed as Non-standard Types and the accompanying text hopefully clarifies their status. Just to reiterate: As far as biblatex's standard data model is concerned these types are absolutely fine, the standard styles just don't have a dedicated driver set up for these types, but that is not something normal users have to worry about.

[katrinleinweber]

[…] and really trying to avoid changing established styles.

I'm assuming this means the "standard styles". Would journal-specific styles be included in those "untouchable" ones?

Because if yes, would a software-specific "citation stack" like CFF need to take up the baton, so to speak?

[moewew]

I think Joseph was referring to the standard biblatex styles, but let's look at the wider picture. If you count the standard styles as a group on their own, there are three types of biblatex styles

1. The standard styles.
2. Styles that follow a specific style guide (APA [biblatex-apa], CMS [biblatex-chicago], IEEE [biblatex-ieee], journal styles).
3. Styles that don't follow a prescriptive style guide to the letter and instead implement what the style author likes often with ample options for customisations (biblatex-philosophy, biblatex-dw).

If one doesn't want to regard the standard styles as a type of its own, they would fall into the last category.

Note that most styles in category 2 are not official in that they were normally not commissioned by the entities behind the style guides. What's more since most publishers can't deal with biblatex submissions in their workflow, many 'journal styles' are not actually (and can not be) used for submissions to those journals (take biblatex-ieee as an example).

Changes to the standard styles have to be well-considered. They are usually the first style users come into contact with and it is fair to assume that many people use them in one way or another. Since biblatex's philosophy allows for simple modifications to be applied in the preamble, many people are using the standard styles together with a few custom modifications. That means that changes to the styles should be done in a way that is as backwards compatible as possible and negatively affects as little users as possible ('affect negatively' includes 'the output looks different than before'). Additionally, the standard styles should serve as code examples and as an entry-point into customisations. As such there is an obligation to keep the code as simple and clean as possible, but at the same time it makes sense to move with the times and use new features where useful (and backwards compatible). Changing the output of entire entry types significantly is more or less out of the question (the changes to standard.bbx fit on one page and the only change to field output is #687, which I could accept with a bit of reluctance).

Changes to styles that implement prescriptive guides are more tricky. For changes in output adherence to the style guide probably trumps stability and continuity (what if the style guide changes, though?). On the one hand I can imagine that you would have a hard time convincing someone to implement support for @software when the guidelines they implement have nothing to say about that. On the other hand they may be happy to implement a best guess. But that probably depends on the maintainer and their philosophy and there is no definitive answer until you hit them with a specific request.

Changes to styles in the last group have fewer constraints, but most (all?) LaTeX developers are aware of the need for backwards compatibility and stability of output, so it might be hard to lobby for changes that change the output of often-used types significantly.

---

Let me repeat that for the specific case of @software citations I don't really see a lot of room for improvement in the biblatex standards styles (and by extension in most well-written contributed styles, though I can't say I checked them thoroughly). I think I demonstrated this before for slightly different specifications, but all required fields of the CFF (https://citation-file-format.github.io/1.0.3/specifications/) should be covered by what @software can do at the moment already. The only interesting thing missing as far as I can tell is the license (that is not something I think is particularly important for bibliographies, but no doubt useful).

[moewew]

Small update: 95ca156 'promotes' @software to the regular types section in the documentation and makes the type alias explicit to avoid a warning. Other than that the output will remain unchanged.