when dealing with the question of whether to store JSON or XML, it suddenly hit me that storing these files in our database maybe isn’t the best way to do it at all.
We have had the citation style XML files in our database for a few select styles for a few years now. Having them in the database is not really the best solution, and also we are limiting our users to just those styles that are locally installed.
So I have an idea: I could create a module for npmjs that bundles all 2000 independent styles (turned into JSON) from the style repository with citeproc-js. In order to make the download size not too big, it would use dynamic imports to load a given style and locale before running citeproc-js on it. The package would be a wrapper around citeproc-js and would provide an API that is just about the same, with the addition that one can specify styles by their short title, like such:
new CSL.Engine(citeprocSys, 'AMR')
This will then first use a dynamic import to load the AMR style file and then initiates citeproc-js onto it. The syntax can be slightly different so developers don’t get confused on whether they are initiating citeproc-js or the wrapper.
The advantages of this approach would be:
The JSON version of the styles will not be user facing at all. Currently I cannot guarantee that someone running their own server is looking at the JSON in the database.
Possible collaboration with other projects to improve the bundling over time.
But before I start on this, I wanted to ask you if there is anything fundamentally wrong with this approach. Or maybe this has been done before? Of course all the various licenses have to be respected so there will need to be some kind of large disclaimer about where it all comes from, who wrote the various parts, etc., but beyond that it would be good to know if you people would prefer for such a package to be named something close to citeproc-js so people will associate it with that, or whether you’d prefer for it to be named something very different so that there is no association.