Feature freeze CSL 1.0.1

Dear all,

I would like to announce the feature freeze of CSL for the upcoming 1.0.1
release. My plans/suggestions for the next few weeks are:

  • Now is the ideal time to go over the drafts of the release notes (
    http://goo.gl/mD2Ez) and specification (http://goo.gl/r5gkH). It’s not too
    late to raise objections (and even have new features pulled), or to suggest
    (small) changes. One point of attention could be the naming of new
    attributes and new values. Once introduced, it’s hard to change those, so
    if you come up with better descriptors, let me know.

  • Unless anybody objects, I will create a “1.0” branch in the “styles” and
    "locales" repositories within the next few days. Parties who aren’t ready
    for CSL 1.0.1 styles or locales can then switch to those branches until
    they’re ready to upgrade to 1.0.1. The “master” branches will upgrade to
    CSL 1.0.1 at release. (we had some recent discussion about branching
    models, but I would like to keep things simple for now; this is a topic we
    can revisit later)

  • Once ready for release, I’ll “tag” the latest commit to the "schema"
    repository as “1.0.1”.

  • I would like to have some kind of announcement ready for the
    citationstyles.org blog when we release 1.0.1. I have a draft available at
    https://docs.google.com/document/d/1jolrrtU6ZkDGF2zIhAEE9cGJq8HxDBUpoabUU-Nq8VQ/edit#.
    Any suggestions regarding the contents are more than welcome.

Does anybody need more time than 2 weeks to review the changes? Otherwise I
would like to put a deadline for feedback in place for Friday August 24th.
Depending on the amount of feedback I get I could release soon after.

Rintze

P.S. there are still a few loose ends I’ll take care of. They include

  • updating csl-date.json and csl-citation.json. I need to add a few item
    types and variables to these JSON schemas. Since there are only additions I
    don’t foresee any compatibility issues with versioning.
  • render HTML copies of the specification and release notes and put them
    online. I’m planning to condense the final release notes somewhat by
    stripping out all the links to the GitHub tickets, which should be of
    little concern to the average reader.
  • as you might be aware, Frank forked CSL for Multilingual Zotero (MLZ). He
    has his own forked schema, but I thought it better to created an MLZ
    extension schema that builds onto the official CSL schema. My version is
    pretty much complete, but I still need to assure that it works with the
    latest draft of the official schema. See
    https://github.com/rmzelle/schema/blob/master/csl-mlz.rnc
  • I already mostly prepped the CSL 1.0.1 locale files (they’re in the
    temporary “1.0.1” branch right now). Following release we need to encourage
    translators to translate any new terms, and to take advantage of the
    improved localization of ordinals (which may include gender-specific
    ordinals).
  • Following release we’ll need to update some documentation. Most
    importantly the documentation on validating styles.

P.P.S. Let me know if I missed anything.

Hello Rintze,

From the introduction: “With minor exceptions (discussed below), CSL
1.0.1 is a backwards compatible release,”

Can you call out these exceptions more clearly in the release notes?

At the risk of bikeshedding, and please forgive me if this has already
been discussed, the scope of the changes feels quite large for a patch
(x.y.z) release.
I would normally expect that notable new features are reserved for x.y releases.

Regards,
Rob.

From the introduction: “With minor exceptions (discussed below), CSL
1.0.1 is a backwards compatible release,”

Can you call out these exceptions more clearly in the release notes?

Sure. I think the exceptions are limited to:

  • line-spacing=“0” is no longer allowed
  • 1.0.1 CSL processors will have to support both the old and the new scheme
    for ordinal terms, unless it is certain that the CSL processor will never
    encounter CSL 1.0 locale files
  • the “page-range-delimiter” term should have a default value of an
    en-dash, unless it is certain that the CSL processor will never encounter
    CSL 1.0 locale files
  • “verb” and “verb-short” are no longer allowed as values on the “form”
    attribute on standalone cs:label elements (which doesn’t really make sense)
  • cs:if and cs:else-if elements now require at least one condition

I have mostly been using the “master” branch for validating the styles in
the “styles” repository, so all CSL 1.0 styles in there already validate
against the 1.0.1 schema. But users might have old or custom versions
installed that will validate against 1.0 but fail against 1.0.1. That
should only affect a small fraction of users, though.

At the risk of bikeshedding, and please forgive me if this has already

been discussed, the scope of the changes feels quite large for a patch
(x.y.z) release.
I would normally expect that notable new features are reserved for x.y
releases.

The rationale is explained here:


There are also a couple of xbiblio forum threads about it. Calling this
release 1.1 would be inconvenient because we want to keep the value on the
“version” attribute on the cs:style and cs:locale root elements as “1.0”.

RintzeOn Thu, Aug 9, 2012 at 5:00 AM, Robert Knight <@Robert_Knight>wrote:

The rationale is explained here:
http://citationstyles.org/2010/05/30/csl-1-0-specification-update-2010-05-30/
There are also a couple of xbiblio forum threads about it. Calling this
release 1.1 would be inconvenient because we want to keep the value on the
"version" attribute on the cs:style and cs:locale root elements as “1.0”.

I think this is among the reasons why we need some language on
conformance: we’re having to come up with complicated solutions to
work around aligning different versioning priorities. Ideally, we can
redefine what “backward compatible” means so that this becomes easier
to manage going forward for everyone.

Bruce

Looks all good to me.

I will be traveling a lot in the next 2 weeks, so please apologize for the lack of response. I don’t have anything to add to this process, it looks like it makes sense, and I can’t wait to be able to submit a few new styles with the 1.0.1 goodies.

Charles

Thanks for the great work Rintze!

One quick question about the input format: are you still planning to allow EDTF as an option for date input?

signature.asc (203 Bytes)

I haven’t really studied the issue, but we probably should (it seems like
EDTF 1.0 is close to being finalized). If supporting EDTF only affects the
input (JSON) data format, we can add support independently of a CSL schema
release, though.

RintzeOn Sat, Aug 11, 2012 at 3:32 PM, Sylvester Keil <@Sylvester_Keil>wrote:

Rintze,
I didn’t get a chance to look over these - I assume they’re fine, but
is the deadline in effect? I wouldn’t squabble over features,
just want to check of the specs if I notice something, let me know if
that’s still useful.
Best,
Sebastian

Please do, and just let me know when you’re done.

Rintze

I went through all of this best I could.
I think the State of the Union is lovely.
Everything else is - as usual - great. The only thing I noticed is
that everything described as an example is actually valid CSL, with
the eception of the two “examples” under cs:citation and
cs:bibliography - I’d suggest using valid CSL for those, too - like







Alternatively, call it a template and not an example.

Great work Rintze!
Sebastian