Just a new thread for an idea I had, didn’t want it to get buried in the weeds.
I would add that it’s easy to determine which styles people care about seeing GUI fields for: there’s already a list of styles you care about in Zotero settings! I wonder if that would end up showing a lot by default. I think if done right, the idea generally strikes an OK balance complicating the spec and flexibility. The actual work for implementors is miniscule; every implementation already tests variables and checks conditions. You just parse 2 extra nodes, schema:-prefixed variable names, and make the possibilities a little more dynamic. So I wouldn’t say there is undue burden or unnecessary complication. The complications saved and flexibility gained for authors and users far outweighs any implementation difficulty. I also think people who are bound by absolute compliance to style guides but don’t want to format all their references themselves deserve a bit of a break.
Some misc other benefits, which I will proceed to exaggerate a little:
- It moves the decision of whether to add something to CSL proper away from the people who would be annoyed if you said no.
- It lets people use free software in a way that works for them, without requiring their opinionated approaches to affect everyone else.
- It enables collecting information about what kind of hacks the community finds necessary, whereas before this is hidden in 2 ways:
- Hacks by misusing fields (not sure how prevalent this is on the main repo, I suspect it’s policed a little)
- People using local overriding versions of styles that misuse fields or use notes to set overrides (I know I do this constantly)
- The rampant abuse of the Extra/notes field by every single implementation or downstream user of CSL, without exception, tells us that people really do need the functionality it brings, and that it’s worth formalising. The negatives of that approach shouldn’t colour this solution, which is structured, easier to use, and actually viable for permanent non-spec-addition hacks for various styles. I would have no trouble with forever using the schema for my idiotic style guide to do the annoying bits.
- You can also avoid the the four hundred million different formats there are for information embedded in Extra. I will ultimately have to, but really don’t want to, implement that stuff.
- It can encode many of CSL-M’s extensions just fine (not eg institutions, but the variables yes)
It would be under a
custom-schemas feature flag for a good while, and would probably require users to opt in before they can use the feature. Styles should generally still do best-effort rendering if their custom variables are not set, not render nothing and break for people who aren’t using the tweaks they offer.