Proposal: CSL (specification update)

Dear all,

In the last two weeks some small changes to the CSL 1.0 specification have
been made. Barring any further feedback/comments/objections/requests, I
would like to release CSL at the end of the week. As discussed
earlier (,
a 1.0.0.x release means that changes are restricted to the specification (we
stick with the same old CSL 1.0 schema). To give people a chance to look
things over, the proposed modifications concern:

the line-spacing and entry-spacing attributes:

the position condition:

et-al abbreviation:

the positioning of name suffixes:

the role of the match attribute on cs:if and cs:else-if


Hi Rintze,

sorry if I jump in a discussion that maybe already reached a consensus
over the way of handling updates and releases, but I do really find it
confusing the tagging of the language when only the documentation was
actually amended.

Since there is a schema, the specification is not a normative document
(the language specification, so to speak). Any change should be
reflected in the version number of the documentation itself, and not
of the language. That specific use of version numbers (the four digit
indicating a documentation change) seems not to be a common practice
to me, and using it for a programming language - sort of - doesn’t
seem to be the best marketing strategy.

As I said, this is just my reaction to the proposal: I didn’t entirely
read the thread where you discussed about revision numbers (thread
that you mentioned), so I may understand you already rejected this
kind of argument in the light of other more compelling needs. If this
is the case sorry for the noise.


For me, there are two major points:

  • the schema logic does not (and can not) describe CSL in its entirety.
    There are multiple reasons for this, including limitations in RELAX NG and
    the wish to keep the schema readable. In CSL 0.8, some gaps were filled by
    annotations in the schema. For CSL 1.0, many schema annotations were
    scrapped in favor of the specification, which now forms an integral part of
    CSL. As such, the specification also carries a normative role.

  • any versioning scheme of the schema and the specification should at least
    do two things: make it possible to a) indicate which version of the CSL
    schema corresponds with which version of the specification, and b) provide a
    clear way to indicate compatibility of CSL processors with specific versions
    of CSL (e.g. “citeproc-js 1.0.10 supports CSL”). As the schema and
    the specification are linked, I think its a given that we should keep the
    versions of both aligned. The tricky part is that sometimes (as for the
    proposed update), changes are made to the specification (changes
    that affect how CSL processors should operate) that don’t require changes to
    the schema. Here I see two alternatives: either increment the version of the
    CSL schema whenever such specification updates are made (even though the
    schema in such a case doesn’t change), or reserve a digit solely for
    specification updates, which eliminates the need to retag the schema (my

Of course, I’m open to suggestions on how we can do this differently.


Today the update to the CSL 1.0 specification has been released:
Instead of a fourth digit (CSL, we decided to use
for specification updates. No changes have been made to the schema.