Changing csl-data.json schema to allow additionalProperties

CSL Development
1

Hi all,

I was unable to validate citeproc+json from CrossRef against the
schema [1] because of additional fields at the top level that were not
valid. After some discussion with others about this issue, it seemed
the best thing to do would be to change additionalProperties to false.
This would allow additional properties at the top level.

I have a pull request pending:

https://github.com/citation-style-language/schema/pull/116

to change the top-level additionalProperties of the csl-data.json
schema to true. This will allow citeproc+json from CrossRef to
validate. (Rintze Zelle has told me that Mendeley also allows
additional properties.)

I’m curious if a) anybody thinks this will cause problems and b) if it
won’t, should additionalProperties also be allowed in other elements,
such as names? This would allow, for instance, orcids to be stored in
citeproc+json, as Martin Fenner does here [2].

best, Erik

  1. https://github.com/citation-style-language/schema/blob/master/csl-data.json
  2. http://blog.martinfenner.org/2013/07/30/citeproc-yaml-for-bibliographies/
2

The only downside is not really a technical problem: people inventing their
own, incompatible, properties, rather than going through a standardization
process. But I don’t see that as a big problem in practice.

Bruce

3

This has come up before (e.g.
http://sourceforge.net/p/xbiblio/mailman/message/31972432/).
citeproc-json definitely needs an extension mechanism.

The question, of course, is how to keep it from becoming another mess,
like with the proliferation of MarkDown formats, for example. Maybe a
GitHub repo where folks could register their own extensions would be a
good idea. I am not familiar enough with json schema to know if it is
modular, so that extensions could import the base and then change things.–
Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 4AN36D-12
301-594-2842

“Erik Hetzner” wrote:

4

I am all for extending Citeproc, but I agree with Chris that it is important to have a good process in place so not to create a big mess. As others have said before, I would start with documenting the Citeproc format a bit better in human-readable form, to correspond with what the JSON Schema validator does. The Citeproc JSON Schema uses JSON Pointer (http://tools.ietf.org/html/rfc6901), and this could be further extended for additional properties, and to modularize the schema. For things like ORCID support for names I would prefer a consensus, rather than an optional extension mechanism.

Best,

MartinAm 22.08.2014 um 22:57 schrieb Maloney, Christopher (NIH/NLM/NCBI) [C] <@Maloney_Christopher>:

5

Hi Martin,

I was going to say that it’s already a bit of a mess, but it does seem
that the only processor generating invalid citeproc+json that I can
find is CrossRef, so perhaps it is best to correct the issues there
and keep the (un)official schema locked down with
additionalProperties: false. It is easy enough for this to be changed
by downstream users of the schema if necessary.

best, ErikAt Mon, 25 Aug 2014 10:44:49 +0200, Martin Fenner wrote:

6

I would start with documenting the Citeproc format a bit better in
human-readable form

We could start by adding a “description” field (see this example:
http://json-schema.org/examples.html) into the .json schema files
themselves (GitHub - citation-style-language/schema: Citation Style Language schema)
copy-pasting text from the CSL spec appendix IV
(Redirecting…
es).

I just opened #118
(Add description fields into the JSON schema · Issue #118 · citation-style-language/schema · GitHub) to suggest
this.–
Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 4AN36D-12
301-594-2842