On May 13, 2013, at 5:53 PM, Rintze Zelle wrote:

> On Mon, May 13, 2013 at 11:44 AM, Sylvester Keil <[email protected]> wrote:
>> For example, ordinals and conditions: if we have a script that updates 
>> locales and styles to the new syntax, we could drop the old syntax from a 
>> 1.1 release.
> 
> If the latest proposal for conditionals is adopted, I'd strongly
> suggest keeping the old syntax around, since it's more compact and
> will suffice for most conditionals.
> 
> Also, if law styles are the main benefactors of this change, we could
> also just keep CSL as it is for the short term, since Frank already
> maintains a fork (CSL-m). (he has expressed the desire to have his
> CSL-m modifications merged back into CSL, but that's going to be a
> long road, regardless)

Just to put my earlier posts in context:

I'm very much for more expressive conditionals. Like most others, it seems, I 
like the current compact syntax and I am therefore reluctant to add nested 
elements instead. However, having seen the American Law Style I understand why 
you would want to add them.

I find that supporting two different syntax variants for conditionals long term 
adds unnecessary complexity to both specification and implementation. The added 
overhead is simply not justified by the luxury of simple styles (even though 
they are the majority) being more compact – actually, for simple conditions the 
proposed syntax doesn't become unwieldy exactly.

I would prefer to keep an extended compact syntax; if beasts like the American 
Law Style leave us no choice but add nested elements to manage their 
complexity, so be it. In that case I would drop the compact syntax though (even 
though I do like it). It would be OK for me to not drop it right away, but 
deprecate it and drop it only with a major release (more on that in a moment) – 
but I think it should be made very clear that the nested conditional syntax is 
the new standard.

This is only my opinion, though, and at the end of the day, I think that CSL 
benefits from the improved conditionals. I do have my reservations stated above 
– but I would not want these reservations to block the conditionals being added.

As far as versioning is concerned, I realize now that Rintze and I are probably 
of the same opinion, but that I was not aware that the plan was to drop 
incompatible legacy features (like the old ordinals) with the next major 
release – because of the way the spec reads right now I was under the 
impression you wanted to retain the old ordinal scheme for good:

http://citationstyles.org/downloads/specification.html#ordinal-suffixes

I think the best approach in such cases is to mark the feature as deprecated. 
So in 1.0.1 it could say that the old ordinal scheme has been deprecated; 1.0.1 
processors still must support the 1.0 scheme (preferably, in my opinion, by 
checking the version number instead of the feature detection used here) and 
that it will be dropped in the future. The upshot of utilizing the version 
numbers for this purpose is that we do not need to come up with suitable 
feature detection mechanisms like in this instance.

I think that there should be a version of the schema for each release 
available. This is currently the case on GitHub using tags – that works very 
well. A style and locale should be allowed to specify exactly which version of 
the spec it is built for – including minor releases. This way a cite processor 
can adapt its processing routines (e.g., which ordinal algorithm to use) and 
the test suite knows against which schema to validate the style or locale.

Sylvester


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Reply via email to