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 1.0.0.1 at the end of the week. As discussed
earlier ( http://sourceforge.net/mailarchive/message.php?msg_name=s2j188351851005020129r10fad3e6yb9a37c8abc3d5a37%40mail.gmail.com),
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:
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.
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 1.0.0.1”). 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 1.0.0.1 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
preference).
Of course, I’m open to suggestions on how we can do this differently.