CSL 1.0.1 release

Hi all,

I just released CSL 1.0.1.

Updated specification:
http://citationstyles.org/downloads/specification.html
Release notes: http://citationstyles.org/downloads/release-notes-csl101.html
Blog post:
http://citationstyles.org/2012/09/03/citation-style-language-1-0-1-update/
Tweet: https://twitter.com/rintzezelle/status/242790154576736257
CSL 1.0.1 schema:
https://github.com/citation-style-language/schema/tree/v1.0.1

I created 1.0 branches for the styles and locales repositories (
https://github.com/citation-style-language/locales/tree/1.0 and
https://github.com/citation-style-language/styles/tree/1.0 ). Anyone who
wants to avoid CSL 1.0.1 styles and locale files for now can use those
branches, or just stop pulling updates from Github. Further development and
maintenance will occur in the “master” branches. The master branch of the
locales repository already contains CSL 1.0.1 locale files, and from today
onwards we will accept CSL 1.0.1 styles in the master branch of the styles
repository. All the CSL 1.0 styles currently in the repository validate
against the CSL 1.0.1 schema.

CSL 1.0.1 styles require CSL 1.0.1 locale files to function optimally, so
please start shipping CSL 1.0.1 locale files to your users when possible
(CSL 1.0 locales don’t cover new terms, such as “available at”, and use a
now out-dated scheme to define ordinal suffixes (see
http://citationstyles.org/downloads/release-notes-csl101.html#localization-of-ordinals)).

citeproc-js should already support most, if not all, CSL 1.0.1 features.

There is still some documentation that has to be updated (e.g. on
citationstyles.org, the Zotero wiki, and the CSL GitHub wikis), and I hope
to update some of that in the next few days. Let me know if I missed
anything.

Cheers,

Rintze

Frank just reminded me that citeproc-js does not yet support the new scheme
for ordinal suffixes, so Zotero/Mendeley/etc. should probably wait with
distributing CSL 1.0.1 locales until that situation changes.

Rintze

Congratulations and thanks for the great work you put into this release, Rintze!

I’ll look into updating the test suite to use the new schema for 1.0.1 styles. Incidentally, if I remember correctly, you mentioned that styles will keep using ‘1.0’ as their version string – if that’s the case, is there any straightforward way for processors to distinguish between 1.0 and 1.0.1 styles? I realize that this should not be necessary in practice, since a 1.0.1 processor will work just fine with 1.0 styles, but for validation purposes it may be useful to tell the difference; or would you prefer to validate all styles using the 1.0.1 schema?

Best,
Sylvester

signature.asc (203 Bytes)

Thanks very much for the detailed release notes, Rintze. This should be very useful in adapting our engine as well.

I am still way behind on my email and other ‘todos’. I just moved from California to France and took a week off in the middle. With the kids going back to school today, and a half-empty house, I’ll be struggling for a while!

Thanks for all the work!

Charles

I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is
there any straightforward way for processors to distinguish between 1.0 and
1.0.1 styles?

No.

would you prefer to validate all styles using the 1.0.1 schema?

Yes. All current styles in the repo validate against both the CSL 1.0 and
1.0.1 schema, but that will of course change once we start committing CSL
1.0.1-only features.

Rintze

Just for the record …

I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is there
any straightforward way for processors to distinguish between 1.0 and 1.0.1
styles?

No.

I still th

Sigh … disregard previous. What I meant to say is …

I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is there
any straightforward way for processors to distinguish between 1.0 and 1.0.1
styles?

No.

I still think this issue of versioning and validation is a problem.

Bruce

Feel free to open a ticket to express your thoughts. I generally agree that
it would be good to have some more discussion about this, but I didn’t want
to delay this release any further.

Rintze

That’s fine. This isn’t so much aimed at you, as the whole dev community here.

Frank just reminded me that citeproc-js does not yet support the new scheme
for ordinal suffixes, so Zotero/Mendeley/etc. should probably wait with
distributing CSL 1.0.1 locales until that situation changes.

Rintze

I finally got on the stick and implemented CSL 1.0.1 ordinals in citeproc-js.

There is a test fixture:

https://bitbucket.org/bdarcus/citeproc-test/src/4a67f523ac07/processor-tests/humans/number_NewOrdinals.txt

If anyone wants to check out the new ordinals behaviour in a word
processing environment before the new locales appear in Zotero and
elsewhere, I have installed the CSL 1.0.1 locales and updated
citeproc-js version in MLZ:

http://citationstylist.org/tools

Cheers,
Frank

I have updated csl-ruby to use the 1.0.1 schema for validation and also updated the test environment in the master branch of the styles repository. All tests pass on my computer and travis. Everyone using the test suite, please pull from the master branch and run

$ [sudo] bundle install

again to fetch the latest version and make sure the 1.0.1 schema is used for testing. If there are any problems, please let me know, I’ll be glad to help.

Also, Rintze and I are currently working on adding tests and validation to the locale repository as well – the tests are already in the locale repository but need a little more work.

Best,
Sylvester

signature.asc (203 Bytes)

Frank, I tried the latest mlz release with a style which re-defines ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
-when gender variants are defined in the ordinal suffix terms , there is no output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]

Cheers,
Gracile> Date: Wed, 5 Sep 2012 08:52:51 +0900

Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.

I haven’t implemented that one yet, so no worries there.

-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]

That’s not good. Thanks for the report, I’ll take a look.

Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.

I haven’t implemented that one yet, so no worries there.

-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]

That’s not good. Thanks for the report, I’ll take a look.

Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.

Is that really necessary? The example I wrote up for the specification
doesn’t define a genderless “ordinal-01” term.

Rintze

I was wondering, too. Gracile explained that there is no genderless term in this case and Rintze suggested to generally fallback to the feminine version when looking up terms since that is the more common case in the languages we looked at.

Note: I haven’t worked out a general algorithm for gender lookups yet that considers all these fallbacks.

Sylvester

signature.asc (203 Bytes)

Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.

I haven’t implemented that one yet, so no worries there.

-when gender variants are defined in the ordinal suffix terms , there
is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]

That’s not good. Thanks for the report, I’ll take a look.

Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.

Is that really necessary? The example I wrote up for the specification
doesn’t define a genderless “ordinal-01” term.

Rintze

It may not be necessary in logical terms (and shouldn’t be, since
French doesn’t have a neuter gender). I’m just trying to get a fix on
the cause of the failure reported by Gracile.

Gracile: can you send me a copy of the style you used for the test?

Frank

Date: Wed, 5 Sep 2012 20:20:50 +0900
From: Frank Bennett <@Frank_Bennett>
Subject: Re: [xbiblio-devel] CSL 1.0.1 release
To: development discussion for xbiblio
xbiblio-devel@lists.sourceforge.net
Message-ID:
CAJgpGgDW8qf58mrAsZohP40Wemk_GwuURq--gJ38JpAAJu9=8w@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.

I haven’t implemented that one yet, so no worries there.

-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[??
??]

That’s not good. Thanks for the report, I’ll take a look.

Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.

See the latest locales-fr-fr.xml: https://github.com/citation-style-language/locales/pull/37
I didn’t define a default term for the reason Sylvester explained.

Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.

I haven’t implemented that one yet, so no worries there.

-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]

That’s not good. Thanks for the report, I’ll take a look.

Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.

Is that really necessary? The example I wrote up for the specification doesn’t define a genderless “ordinal-01” term.

I was wondering, too. Gracile explained that there is no genderless term in this case and Rintze suggested to generally fallback to the feminine version when looking up terms since that is the more common case in the languages we looked at.

Let me think out loud here for a few lines.

(1) If a masc, fem or neut variable term is called, the
corresponding genderized term should be used. That much is common
sense.

(2) If a neuter term is defined, and a masc or fem variable term is
called, and no corresponding genderized term is defined, it defaults
to the neuter term version. That’s clear from the spec.

(3) If a fem term is defined, and no neut term is defined, the fem
term becomes the default, and will be used if a masc term variant is
undefined (following the suggestion above).

(4) If only a masc term is defined, I guess that becomes the
default, and will be used if (as would logically be so) a fem term is
undefined.

I’ll confess that this will require a rewrite the locale and term
calling code in citeproc-js. I’ll wind out the latest citeproc-js
release from MLZ, and post a note when the work has been done. It will
probably be another month or so.

Frank