Closing a last few tickets for CSL 1.0.1

CSL Development
1

Dear all,

I think it makes sense to put out a timely CSL 1.0.1 release in the next
few months, instead of waiting any longer for the Zotero team to address
all the tickets affecting the Zotero data model (see
https://github.com/ajlyon/zotero-bits/issues).

Since the release of CSL 1.0 I’ve rewritten most of the specification for
increased precision and clarity. I closed a number of tickets which should
all be listed in http://goo.gl/mD2Ez (source:
https://github.com/citation-style-language/documentation/blob/master/release-notes-CSL-1.0.1.txt).
The rendered version of the trunk specification can be seen at
http://goo.gl/r5gkH (source:
https://github.com/citation-style-language/documentation/blob/master/specification.txt).

In order to prepare for 1.0.1, I would like to make one last round of
tickets we can close without too much discussion. I identified several
candidates which I would like to receive feedback on. If I don’t receive
feedback in the next two weeks, I assume people have no objections against
their implementation. Feel free to suggest other tickets that you think are
uncontroversial that I might have missed. Please provide feedback on
individual tickets via the GitHub issue tracker.

Tickets:

Allow dependent styles to define an overriding default-locale value


My opinion: would like to implement proposal as is
My question: whether any CSL-implementators have problems with this, since
information in dependent styles will start to affect how the independent
parent style is rendered

Create new terms for commonly used text strings


My opinion: would like to add terms for “supra” and “available-at”. I’m not
yet convinced that any of the other candidates are popular enough to
warrant a term.
My question: what happens if a CSL 1.0.1 processor encounters a CSL 1.0.1
style calling a new term and only has a CSL 1.0 locale file which doesn’t
define the term? (CSL 1.0.1 should be backward-compatible) Would it make
sense to have a hardcoded list with default term values in each CSL
processor for CSL 1.0.1 terms?

Add “page-range-format” option for OSCOLA


My opinion: would like to implement proposal as is, although I’m still
undecided about the best name of the attribute value. It’s a bit nitpicky,
but I prefer “minimum-two” over “minimal-two” (
http://forum.wordreference.com/showthread.php?t=935755 )

Add a test condition context=“citation” / context=“bibliography”


(probably will mostly be used in complex styles, which are less likely to
be ever edited with a style editor)
My opinion: would like to implement proposal

Spec language for multiple numbers


My opinion: would be good to implement, but need input from Frank and
others, and this will need some polishing



My opinion: I already added a “dimensions” term, but I think we probably
should also add “scale”. Furthermore, we probably need accompanying terms
as well.

Best,

Rintze

2

I am OK with the list. I can’t comment too much, since I really only can judge things from an implementor’s point of view, and not so much as a style writer, where frankly, I have very little experience. As an implementor, I’ll just support whatever makes the life of style writers and users easier.

Regarding the issue of 1.0 locales not working well with 1.0.1 styles, I would not worry too much about it. I am not sure when that can happen, and if that happens, I don’t see why the CSL specs would have to go out of their way to cover the case. Also, I am not sure it can be handled gracefully anyway… I’d rather see more terms supported for a better user experience :slight_smile:

In any case, it’s great to see how much care is going into this. I am, as always, impressed…

Charles

3

Tickets:

Allow dependent styles to define an overriding default-locale value
Allow dependent styles to define an overriding default-locale value · Issue #91 · citation-style-language/schema · GitHub
My opinion: would like to implement proposal as is
My question: whether any CSL-implementators have problems with this, since
information in dependent styles will start to affect how the independent
parent style is rendered

Yeah, this seems to me an important question: it fundamentally changes
the meaning of a “dependent style” to include processing override
behavior. I can see the value of this particular case, but do we
really want to go down this path now?

Create new terms for commonly used text strings
Create new terms for commonly used text strings · Issue #90 · citation-style-language/schema · GitHub
My opinion: would like to add terms for “supra” and “available-at”. I’m not
yet convinced that any of the other candidates are popular enough to warrant
a term.
My question: what happens if a CSL 1.0.1 processor encounters a CSL 1.0.1
style calling a new term and only has a CSL 1.0 locale file which doesn’t
define the term? (CSL 1.0.1 should be backward-compatible) Would it make
sense to have a hardcoded list with default term values in each CSL
processor for CSL 1.0.1 terms?

I support this change, but think implementers should tell us how
they’re going to respond.

Add “page-range-format” option for OSCOLA
Add "page-range-format" option for OSCOLA · Issue #84 · citation-style-language/schema · GitHub
My opinion: would like to implement proposal as is, although I’m still
undecided about the best name of the attribute value. It’s a bit nitpicky,
but I prefer “minimum-two” over “minimal-two” (
Minimum - minimal | WordReference Forums )

I agree with you.

Add a test condition context=“citation” / context=“bibliography”
Add a test condition context="citation" / context="bibliography" · Issue #80 · citation-style-language/schema · GitHub
(probably will mostly be used in complex styles, which are less likely to be
ever edited with a style editor)
My opinion: would like to implement proposal

I never understood this issue, but think I do now:

It is to allow authors to define single macros that can define
behavior across the citation/bibliography divide.

Is that right?

If yes, this is another subtly big issue. Right now, citation and bib
configuration are strictly separate. This would change that.

Pro: allows less verbose styles
Con: changes the essential logic of CSL, and potentially (?) could
lead to really confusing styles
Question: do the pros really outweigh the cons?

Bruce

4

Yeah, this seems to me an important question: it fundamentally changes
the meaning of a “dependent style” to include
processing override behavior.

A comment on the ticket mentions that potentially there could be a lot
of styles created which
differ only in this attribute. Are there any other attributes which
this could happen with?

Regards,
Rob.

5

just a quick not from the style creator perspective:

Tickets:

Allow dependent styles to define an overriding default-locale value
Allow dependent styles to define an overriding default-locale value · Issue #91 · citation-style-language/schema · GitHub
My opinion: would like to implement proposal as is
My question: whether any CSL-implementators have problems with this, since
information in dependent styles will start to affect how the independent
parent style is rendered

Yeah, this seems to me an important question: it fundamentally changes
the meaning of a “dependent style” to include processing override
behavior. I can see the value of this particular case, but do we
really want to go down this path now?
I understand Bruce’s concern, but I really want to put in a big pretty
please to implement this. It will make things so much easier.
Following Robert’s question, I don’t think there are any other
attributes that are comparable to the locale attribute in this
respect. While it’s not unlikely that we will have cases that are
"just like APA but with page-range-format=“minimal” - these are still
different styles and I don’t mind maintaining them as such. A style
with a default locale is actually the same style - it just forces
non-English (typically) users to work with their client’s locale
settings.

Add a test condition context=“citation” / context=“bibliography”
Add a test condition context="citation" / context="bibliography" · Issue #80 · citation-style-language/schema · GitHub
(probably will mostly be used in complex styles, which are less likely to be
ever edited with a style editor)
My opinion: would like to implement proposal

I never understood this issue, but think I do now:

It is to allow authors to define single macros that can define
behavior across the citation/bibliography divide.

Is that right?
Yes.
This is Frank’s baby. For me this will rarely, if ever, be useful. As
I say on the ticket, it’s only relevant for note styles. The
formatting in Chicago Manual for notes and bibliography - which are
the template for almost all non-legal note styles - is quite distinct,
so this won’t help much. If Frank is really attached or if this has
for some reason I’m overlooking the potential to be really helpful for
GUI style creating, let’s go with it, but otherwise I’d throw this one
out.
Best,–

Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University

6

As a bit of background: while the default-locale attribute existed before
CSL 1.0, it wasn’t well-documented or recognized by Zotero, and few styles
carried it. As a result, most styles used to localize according to the
system/Zotero-locale for Zotero users. While automatic localization is a
neat feature of CSL, it is clearly undesirable for journal-specific styles,
so I recently went over all independent styles and added default-locales
where applicable. This left us with a small selection of
non-journal-specific styles (e.g. APA, Vancouver and IEEE). These include
all the popular styles, which are generally prime candidates for automatic
localization (which would argue for leaving out a default-locale), but
which also have many dependents that are locale-specific (e.g. for US
journals). Allowing dependent styles to specify a default-locale would
solve this dilemma.

So I think this case is rather special. One other option I see is setting a
default-locale even for styles like Vancouver, but this would decrease the
discoverability of automatic style localization, and should IMHO be
accompanied by an easy way for the user to specify an overriding locale (in
the case of Zotero, preferably both in the general preferences and the word
processor plugins preferences (on a per-document basis)).

Rintze