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:
CSL 1.0 Specification Update 2010-05-30 - Citation Style Language
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