Mendeley/Elsevier Donation

Hi Rintze, Sebastian,

Thank-you once again for your continued work on the project. Your
proposal sounds good to me and
I think you’re best placed to judge how to use it.

While development of
CSL has been quiet before the flurry of activity we expect once Zotero
starts revisiting its metadata model,

Is there any background info on this that you would recommend reading?
If changes to Zotero’s model filter down to CSL then it will likely
affect Mendeley as well and future interoperability
between documents authored with plugins from one tool or the other.


Perhaps it’s time to take up a more general, rigorous, forward-looking,
analysis of the CSL metadata model, as expressed in the JSON schema and CSL
variable matching? That way, different projects could propose
changes/enhancements based on their needs, but we have a process to resolve


PS - I’m fine with the funds proposal too.

The most visible collaboration on changes to the Zotero models and
potential CSL directions has been here:

Hi Robert,

that maybe needs clarification: we will never just "filter down"
Zotero changes to CSL. Before we make changes to CSL, we will propose
them here, will have a period for comments on spec changes and will
talk about a time-table for implementation.

Where Zotero comes in is mainly that it makes sense to think about
some changes in how they interact with a reference manager, if they
require changes there, etc. We’ve implemented some changes
significantly ahead of Zotero (dataset item type, the various
"original-" variable) and there’s little reason we couldn’t do that
again. So the Zotero item/field revamp is mainly a good opportunity to
take this on. See Avram’s link for details so far. The tags there
should help to distinguish items that are only relevant to Zotero from
CSL-related issues.
So, along the lines of what Bruce says, this really shouldn’t be a
"filtering down from Zotero" process at all. The main reason Zotero
comes up is that Rintze, me, and Frank are all most familiar with
Zotero, so we’re using that as a way to think about CSL changes. But
any other reference manager related input as to what is needed in CSL
is just as welcome.

For any changes in functionality that aren’t directly related to
reference managers (things like “idem” for example), we’d of course
work closely with implementers, and given that Frank’s citeproc-js is,
for all intents and purposes, the benchmark there, you’re in the front
seat anyway.

Hope that makes sense.


Further discussion on this topic should probably take place in it’s
own thread, but as for my opinion on the CSL development process
(apologies for the long ramble):

While there are known limitations in CSL 1.0.1, it’s been proven to be
a sturdy release, and having sporadic releases has its advantages. It
simplifies maintenance and distribution of our styles and locale files
(since we just maintain files for the latest CSL release), it makes it
easier to share styles and locale files between applications (since
they’re usually on the same version), and CSL processors become more
thoroughly tested and stable. If we had rolling releases there would
be all kinds of compatibility problems.

I personally haven’t minded the slow progress of development in the
past two years. It was a nice break, and allowed us to focus on
improving our CSL infrastructure and curating our repositories. Since
the release of 1.0.1, we’ve gained thousands of styles
(, we have created a workflow to
generate the majority of our dependent styles from spreadsheet data
we started using Travis-CI to get and keep our style and locale repos
in tip-top shape
(, created a
separate distribution style repo that only gets updated if Travis is
happy (,
we started keeping track of renamed styles
and we have a nice new validator
( In early 2013 I even checked
every style by hand (about 3000 at that time), adding ISSNs where
possible, and verifying that all the journals for which we had styles
were still active.

One reason for not implementing certain features in CSL 1.0 and 1.0.1
was that we couldn’t come up with an elegant solution, or weren’t
ready to commit to a certain design path. Frank Bennett’s forging
ahead with Multilingual Zotero has been an ongoing experiment and
playground for making certain extensions to CSL, and his user feedback
will be very valuable in directing future CSL development.

So, that said, I do think it’s getting time to start preparing for
another release. In this light:

I’m working to update the CSL primer and migrate it to Once that is done, I’m planning to
move the specification there as well. Since the contents of is automatically generated from the
reStructuredText sources, and supports versioning, this should make it
much easier to develop the CSL specification and having a rendered
copy of the “master” branch at all times.

I won’t deny that Zotero and CSL have a special relationship, for
which there are many reasons. Zotero was the first big project to use
CSL, Simon co-developed CSL in the early days, many other CSL
developers come from Zotero, the Zotero forums are one of the most
active places on the web to discuss CSL, Zotero’s open source nature
makes it easy to study the Zotero-CSL interface, etc. But we’re keenly
aware that CSL is in wide use, and I think everybody here is committed
not to give Zotero an unfair advantage by focusing purely on
Zotero/CSL compatibility.

We’ll continue our process of proposing every change to CSL on the
xbiblio list, and try to reach consensus on all changes. The way I
expect things to happen is that, once Zotero starts focusing on its
metadata model, most discussion will first take place on the
zotero-bits repo. Based on the conclusions draw there, we’ll propose a
neat list of changes to CSL here on this list, and ask for
comments/feedback/approval. There should be plenty of time for the
vetting process. Zotero has kept the same metadata model for years, so
we can take a few months. We’ll probably coordinate a CSL release
somewhat with Zotero, but give plenty of notice not to surprise
anybody. Of course, this doesn’t prohibit anybody from independently
proposing changes on this mailing list in the meantime. Everybody is
welcome to participate at the zotero-bits repo as well.

In relation to what Bruce said, I would like CSL to provide more
guidance on what the role is of the different item types, and which
metadata fields should be available for each type. If we do prepare
documentation and/or a schema for this, I expect we would take the new
Zotero/CSL mapping as a starting point, and try to create a canonical
version based on that.

As for other changes to CSL: I’m happy to continue managing the CSL
project, but I personally won’t be pushing as hard for further changes
to CSL as I once did a few years ago. So if anybody feels development
is too slow, feel free to bug me or the xbiblio list, or step up


Hi Rintze, Sebastian,

When I talked about changes from Zotero ‘filtering down’ to CSL, I
absolutely didn’t mean that in a negative sense.
The Zotero community have done a lot of important work in gathering
requirements for representing citation data and some of
that will translate into proposals for CSL as you describe.

Up until now Mendeley hasn’t done much in the way of similar exercises
but I think that may change in future.

Most recent work on our side has been cleaning up Elsevier’s own
styles to reduce a lot of needless duplication which doesn’t affect
the spec. As Carles will testify, that hasn’t been the most efficient
process though.

I basically just wanted to outline my thoughts on the near future of
CSL, so that interested parties know what’s up and can steer our
direction if they think we should do things a little differently.