Versioning of CSL and the CSL spec

[Bruce_D_Arcus1]

This has come up again, so I want to revisit.

@Rintze_Zelle1

1.* changes: used for backwards-incompatible changes in the CSL schema.
These are changes that require a style upgrade (using XSLT), like moving
cs:et-al from being a child element of cs:names to being a child element of
cs:name. With each upgrade, the required value of the version attribute on
cs:style is incremented (e.g. from “1.0” to “1.1”).

So they change the CSL model as represented in the csl.rnc file in ways that require style files to be modified to properly run.

What about adding a new element that processors can ignore?

Because it doesn’t require style changes, I think we might make the reasonable argument that they can go in a 1.0.x release, so long as we say something about this (how processors handle unknown elements and attributes) in the spec.

@Rintze_Zelle1

1.0.* changes: used for backwards-compatible changes in the CSL schema. An
example is the addition of the new delimiter-precedes-et-al option, which
offers more flexibility but isn’t required in CSL 1.0.0 styles. With
backwards-compatible changes, the value of the version attribute on cs:style
doesn’t change (it stays “1.0”).

+1

But: what about new variables and types, which is the most frequent request we get?

I vote they go here.

@Rintze_Zelle1

1.0.0.* changes: used for changes in the specification that don’t require
changes to the CSL schema. An example are the recently discussed
instructions on the delimiter the CSL processor should use between names and
et-al.

+1