Do we have a clear policy on this? Does a change like this go in a 1.1
schema and spec, and do we create 1.1 variants of all 5000+ styles?
Notwithstanding details, I think this is the core issue I see.
If we come to consensus on this issue, the solution will probably be
backward compatible (i.e. the conditional logic of CSL 1.0.1 styles
will remain valid syntax). In that case, we can simply do what we did
for CSL 1.0.1:
- preannounce release of a new CSL version (e.g. 1.0.2), and create a
1.0.1 branch in the “styles” repository
- after a few weeks, formally release the new CSL version and start
accepting new version styles in the repository
This gives any developers who aren’t able to accommodate the new CSL
version some time to switch to the “1.0.1” branch until they’re ready
to switch back to “master”.
The even bigger change is probably caused by the ‘not:’ prefix (at least in the Ruby implementation that was the case).
Right. This is an example that conflicts with current design
foundations in CSL.
Yes, and I’m not happy with that proposal :).
Rintze
To clarify …
Bruce, I am in full agreement with your points regarding the design process.
The concerns you raised are very important (who does the change benefit and how? what are the costs? do the benefits outweigh the costs?) but the one on which most emphasis was placed in the discussion (or so it seemed to me) was the proposal’s alleged disruptiveness.
That’s what I wanted to draw attention to.
Or, more to the point: how exactly does the trailing ‘-all’ etc. make things more complicated in a meaningful way?
Currently we have something like: variable=“x y z” and a processor must:
- split the value into tokens
- fetch data from the citation item according to those tokens
- join the evaluated data based on the value of the ‘match’ attribute
Now, with variable-all=“x y z” the processor must:
- split the value into tokens
- fetch data from the citation item according to those tokens
- join the evaluated data using logical AND semantics
Why is that so disruptive as opposed to the current specification?
When I used the word “disruptive” in this context, I was meaning WRT
to compatibility, and therefore style and schema versioning. I realize
for developers, it’s not that big a deal.
That was my misunderstanding then, my apologies. I had the feeling, during the discussion, that the original proposal was marked as clearly introducing new practices (in particular the variable-all attributes etc.) when I really didn’t see how it differed from the current specification all that much.
I think versioning is a big deal for developers, because it’s extremely painful to support different versions (for example, to support CSL 1.0 ordinals with two different algorithms). This is exactly why I was in very much in favour of the proposal: it offered more flexibility and can be implemented with a single algorithm that still covers the current version – that’s a very big plus in my book, but it looks like we’re moving in a different direction now.
Do we have a clear policy on this? Does a change like this go in a 1.1
schema and spec, and do we create 1.1 variants of all 5000+ styles?
I think Rintze makes a good point there: by creating a 1.0.1 branch it is easy to retain all styles; it’s even possible to accept updates on that branch. Whereas new features go strictly into master and are not merged back to 1.0.1.