Style Distribution; or What can we learn from package managers

CSL Development
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