# Syntax proposal: conditions

**URL:** <https://discourse.citationstyles.org/t/syntax-proposal-conditions/1168>\
**Category:** CSL Development\
**Created:** [April 15, 2013, 3:41pm UTC](https://discourse.citationstyles.org/t/syntax-proposal-conditions/1168 "2013-04-15T15:41:39Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [April 28, 2013, 3:18pm UTC](https://discourse.citationstyles.org/t/syntax-proposal-conditions/1168/21 "2013-04-28T15:18:00Z")

</div>

> 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

---

<div class="post-metadata">

**Author:** ![Sylvester\_Keil](https://avatars.discourse-cdn.com/v4/letter/s/85e7bf/32.png) [@Sylvester\_Keil](https://discourse.citationstyles.org/u/Sylvester_Keil)\
**Post date:** [April 28, 2013, 7:14pm UTC](https://discourse.citationstyles.org/t/syntax-proposal-conditions/1168/22 "2013-04-28T19:14:58Z")

</div>

> 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.

[Previous page](https://discourse.citationstyles.org/t/syntax-proposal-conditions/1168.md?page=1)