Style Distribution; or What can we learn from package managers

CSL Development
1

A sort of follow up to Towards a simpler and extensible CSL 2.0; or What can we learn from citeproc (hs) and djot? - #8 by Bruce_D_Arcus1

I’ve been thinking a bit whether we could simplify the style distribution model and make it more flexible: Currently, maintaining the styles repo takes a lot of time and energy. Maybe we could learn something here from package managers, and use a more decentralized approach. Scoop, for example, has the concept of buckets. Different kinds of applications go into different buckets. Maybe we could adopt a similar approach: a main bucket with the main styles, which would be actively developed and curated. Everything that goes in there has to be of high quality. Then another bucket for hack-free styles, but of minor importance, publishers, journals and such. Then, a third bucket for everything else. Zotero could then choose to only add certain repos by default.

Or, we could even allow arbitrary git repos as sources, as long as they conform to some directory structure. The official Zotero repo would then be the one with the strictest standards, but there would be others, e.g. institutional repos or so.

What do you think? Would that make sense?

1 Like
2

My original idea for CSL, way back around 2004/5, was distributed. It’s why styles are named by globally unique and addressable URIs.

I mainly had in mind that ideally different sorts of organizations would host such files; journals and publishers, scholarly societies, perhaps libraries.

I’ll also note that every successful new language I can think of in the past decade or two has had excellent package management. Think Rust, Go, etc. Those, like I imagine Scoop, work via centrally-indexed but distributed code.

Deno, OTOH, which I am using as the engine for my project, imports modules directly via URL.

One barrier to going more distributed, however, has been the high barrier-to-entry in creating high quality styles. Which brings us back to the other thread.

I have designed that code so that styles could be almost completely decomposed into modular components (not just templates, but also locales and options, including sorting logic), which not only (as I’ve mentioned before) can leave room for easier to use UIs for users, but I think may also facilitate this sort of distributed style distribution.

Like Scoop and others, you could imagine a curated index, and maybe a more wide-open one, with all of them reusing more centrally-managed components.

Think index entries something vaguely like (yes, there may be problems with this precise suggestion, given I just whipped it up; but just to give an idea):

name: APA
templateCollections:
  - csl:apa-templates # official CSL components, part of primary index
  - csl:core-templates # official CSL components, part of primary index
localeCollections:
  - apa:locale-apa # config component managed by APA, part of primary index
optionKey: apa:options # config component managed by APA, part of primary index
file: https://github.com/apa/style.csl/style.csl.json # style file hosted in an APA repo

So yeah, big thumb’s up from me!

1 Like