See this forum thread:
http://forums.zotero.org/discussion/5047/italic-year-suffix/
I think to solve this correctly, we probably need to require explicit
encoding of et al and author-date suffixes; e.g. the simplest (though
am not sure it’s the best) way requires very minor schema changes:
I would consider this a backward-incompatilble change, but probably
one we need to do. To do it, though, I think we need both:
-
general agreement it’s a good idea, and also
-
a commitment to implement.
Can I get feedback on both?
Bruce
See this forum thread:
http://forums.zotero.org/discussion/5047/italic-year-suffix/
I think to solve this correctly, we probably need to require explicit
encoding of et al and author-date suffixes; e.g. the simplest (though
am not sure it’s the best) way requires very minor schema changes:
Since both (et-al and author-date-suffix) are options I think it would
be better to tune them with options too. That would not be
backward-incompatible, right?
I would consider this a backward-incompatilble change, but probably
one we need to do. To do it, though, I think we need both:
-
general agreement it’s a good idea, and also
-
a commitment to implement.
Can I get feedback on both?
I’m not sure for 1) but if an agreement is reached, yes for 2).
Best,
Andrea
See this forum thread:
http://forums.zotero.org/discussion/5047/italic-year-suffix/
I think to solve this correctly, we probably need to require explicit
encoding of et al and author-date suffixes; e.g. the simplest (though
am not sure it’s the best) way requires very minor schema changes:
Since both (et-al and author-date-suffix) are options I think it would
be better to tune them with options too. That would not be
backward-incompatible, right?
Right, but then:
a) we’d have to add options like “et-al-italicize” and
“author-date-suffix-italicize”, and …
b) we’d have to offer equivalent new options if someone came around
and I said “I need et al bold”
I’m open to this, but there is a trade-off.
I would consider this a backward-incompatilble change, but probably
one we need to do. To do it, though, I think we need both:
-
general agreement it’s a good idea, and also
-
a commitment to implement.
Can I get feedback on both?
I’m not sure for 1) but if an agreement is reached, yes for 2).
OK, thanks. Let’s see what others have to say then.
Bruce
I would like to plug this much related feature request:
http://sourceforge.net/tracker/index.php?func=detail&aid=2212677&group_id=117435&atid=678021
Modifying the author-date-suffix sometimes goes beyond the font-style. I’ve
come across multiple styles which require a certain delimiter for the
author-date suffix (no space, space, semicolon (with/without space),
forward-slash). So a flexible way to define these parameters would be
appreciated.
Rintze Zelle
So you’re suggesting the need for the backward-incompatible version.
Nobody else? Simon? Dan?
I’m starting to think we need to come up with a more formal way to
move forward with CSL, as posting a note to the list every so often
does not seem to garner sufficient attention.
Any ideas?
Here’s the current list of issues:
http://sourceforge.net/tracker/?func=browse&group_id=117435&atid=678021
Bruce
I think this is a good idea. I would favor entries in for both
of these, since the options we want to offer seem to go beyond what’s
offered by . It might be better to use special and
elements, since it seems like we want to put more
functionality here than elements will afford. In the absence of
such terms, we could default to the current behavior to preserve
backwards compatibility.
Simon
I suppose you mean an entry in for and in for
, which would probably be better, right?
That would be a nice solution.
Andrea
So am I seeing some consensus at adding elements for these? Simon, do
you have some specific RNC in mind?
Bruce
I found another funky case with regard to ‘et al’-usage in the style guide
of the American Meteorological
Society. For in-text citations, ‘et al’ is used in case of three of more
authors. However, in the bibliography, ‘and Coauthors’ should be used in
case of more than eight authors instead of ‘et al’. Would the proposed
solution offer the ability to call different terms in the citation and
bibliography elements of the CSL style?
Rintze
I found another funky case with regard to ‘et al’-usage in the style guide
of the American Meteorological
Society. For in-text citations, ‘et al’ is used in case of three of more
authors. However, in the bibliography, ‘and Coauthors’ should be used in
case of more than eight authors instead of ‘et al’. Would the proposed
solution offer the ability to call different terms in the citation and
bibliography elements of the CSL style?
In footnotes, the Bluebook requires the discretionary listing of all
authors for specific cites, where names that would be masked by et al.
are important to the context (rule 15.1.1). If I understand this
change correctly (and I may not do), it would permit us to set up a
style that assumes use of the full list of authors by default, and
requests the et-al algorithm for each cite on the fly.
If that is right, it would open the possibility of satisfying the
Bluebook use case through a user override. (The toggle would have to
come through somewhere. The “context” element that I proposed earlier
would be one way to grab it.) Am I following this alright, or am I
out in left field?
This is related to a larger discussion that includes this:
https://sourceforge.net/tracker/index.php?func=detail&aid=2498082&group_id=117435&atid=678021
To implement this would I think just require adding these to the conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
I’m not sure we need a separate at-al element. Why not just …
…?
Of course, et-al is currently a little different; we nowhere
explicitly say “print x first names” etc.
Bruce
I found another funky case with regard to ‘et al’-usage in the style
guide
of the American Meteorological
Society. For in-text citations, ‘et al’ is used in case of three of more
authors. However, in the bibliography, ‘and Coauthors’ should be used in
case of more than eight authors instead of ‘et al’. Would the proposed
solution offer the ability to call different terms in the citation and
bibliography elements of the CSL style?
This is related to a larger discussion that includes this:
<
XBib / Feature Requests / #9 add ability to count variables
Is the link in that tracker entry meant to point to the other tracker entry
“remove “disambiguate-add-title””? If so, I don’t get the link (no pun
intended).
To implement this would I think just require adding these to the
conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
To do what exactly?
I’m not sure we need a separate at-al element. Why not just …
…?
Of course, et-al is currently a little different; we nowhere
explicitly say “print x first names” etc.
Is this already valid CSL with the current schema? It might work, but only
if I replace the string of the term “et-al” with an empty string, and
introduce hard-coded suffixes in the names-elements of both the citation (to
append " et al.“) and the bibliography section (to append " and Coauthors”)
of the CSL style.
Rintze
I found another funky case with regard to ‘et al’-usage in the style
guide
of the American Meteorological
Society. For in-text citations, ‘et al’ is used in case of three of more
authors. However, in the bibliography, ‘and Coauthors’ should be used in
case of more than eight authors instead of ‘et al’. Would the proposed
solution offer the ability to call different terms in the citation and
bibliography elements of the CSL style?
This is related to a larger discussion that includes this:
https://sourceforge.net/tracker/index.php?func=detail&aid=2498082&group_id=117435&atid=678021
Is the link in that tracker entry meant to point to the other tracker entry
“remove “disambiguate-add-title””? If so, I don’t get the link (no pun
intended).
Oops;
https://sourceforge.net/mailarchive/message.php?msg_id=52C37979-8F51-4D7D-82B8-96CAE5C5C9B7%40simonster.com
To implement this would I think just require adding these to the
conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
To do what exactly?
Per above thread, to be able to count variables; relevant to et-al
handling, as well as the funky sorting rules outlined in that thread.
I’m not sure we need a separate at-al element. Why not just …
…?
Of course, et-al is currently a little different; we nowhere
explicitly say “print x first names” etc.
Is this already valid CSL with the current schema?
I don’t believe so.
It might work, but only
if I replace the string of the term “et-al” with an empty string, and
introduce hard-coded suffixes in the names-elements of both the citation (to
append " et al.“) and the bibliography section (to append " and Coauthors”)
of the CSL style.
Not following you.
Bruce
To implement this would I think just require adding these to the
conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
To do what exactly?
Per above thread, to be able to count variables; relevant to et-al
handling, as well as the funky sorting rules outlined in that thread.
Counting isn’t the problem here. You can already set the “et-al-min” option
to separate values in the citation and bibliography sections of a CSL style.
I’m not sure we need a separate at-al element. Why not just …
…?
Of course, et-al is currently a little different; we nowhere
explicitly say “print x first names” etc.
Is this already valid CSL with the current schema?
I don’t believe so.
It might work, but only
if I replace the string of the term “et-al” with an empty string, and
introduce hard-coded suffixes in the names-elements of both the citation
(to
append " et al.“) and the bibliography section (to append " and
Coauthors”)
of the CSL style.
Not following you.
Maybe you could take a look at the style guide. It may explain things better
than I could do:
404 - American Meteorological Society (pages 50 and
51)
the relevant excerpts:
"b. Citations in text
If there are three or more authors, state the first author’s surname,
followed by “et al.” and the year of publication—for example, Smith et al.
(1990) or (Smith et al. 1990)."
and
"c. Reference format
For references with more than eight authors, list only the first author by
name followed by “and Coauthors” (e.g., “Smith, J., and Coauthors, 1998:
Title of article …”)."
So for both the in-text citations and for the bibliography I need the et-al
logic currently available in CSL, so that the correct number of authors is
shown (which works fine). The problem is that when the “et-al” condition is
true, the “et-al” term is appended after the authors-listing, even though
this term isn’t explicitly called. This causes a problem as I need different
strings for the in-text citations on the one hand (" et al.“) and the
bibliography on the other (where is should be " and Coauthors”), and I don’t
know how to do that.
Rintze
To implement this would I think just require adding these to the
conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
To do what exactly?
Per above thread, to be able to count variables; relevant to et-al
handling, as well as the funky sorting rules outlined in that thread.
Counting isn’t the problem here. You can already set the “et-al-min” option
to separate values in the citation and bibliography sections of a CSL style.
Right, but I’m suggesting that if we step back, there are some generic
issues. And we never did resolve this counting case.
I’m not sure we need a separate at-al element. Why not just …
…?
Of course, et-al is currently a little different; we nowhere
explicitly say “print x first names” etc.
Is this already valid CSL with the current schema?
I don’t believe so.
It might work, but only
if I replace the string of the term “et-al” with an empty string, and
introduce hard-coded suffixes in the names-elements of both the citation
(to
append " et al.“) and the bibliography section (to append " and
Coauthors”)
of the CSL style.
Not following you.
Maybe you could take a look at the style guide. It may explain things better
than I could do:
404 - American Meteorological Society (pages 50 and
51)
the relevant excerpts:
"b. Citations in text
If there are three or more authors, state the first author’s surname,
followed by “et al.” and the year of publication—for example, Smith et al.
(1990) or (Smith et al. 1990)."
and
"c. Reference format
For references with more than eight authors, list only the first author by
name followed by “and Coauthors” (e.g., “Smith, J., and Coauthors, 1998:
Title of article …”)."
So for both the in-text citations and for the bibliography I need the et-al
logic currently available in CSL, so that the correct number of authors is
shown (which works fine). The problem is that when the “et-al” condition is
true, the “et-al” term is appended after the authors-listing, even though
this term isn’t explicitly called. This causes a problem as I need different
strings for the in-text citations on the one hand (" et al.“) and the
bibliography on the other (where is should be " and Coauthors”), and I don’t
know how to do that.
You can’t now, but I think you can with what I’m suggesting.
Essentially, the cs:name element has to b continue to be smart to know
an et al condition and drop names accordingly. But beyond that, we
require explicit specification of what to print under that condition.
The same is true of year-suffixes.
What I’m trying to get is consensus on if this is the right approach,
and to implement it. We need to clean these things up and push towards
1.0.
Bruce
[snip]
This is related to a larger discussion that includes this:
[snip]
https://sourceforge.net/mailarchive/message.php?msg_id=52C37979-8F51-4D7D-82B8-96CAE5C5C9B7%40simonster.com
To implement this would I think just require adding these to the
conditionals:
attribute count-min { xsd:integer }
attribute count-max { xsd:integer }
[snip]
I’m not sure we need a separate at-al element. Why not just …
I’m not sure I follow how count-min / count-max fit together with the
et-al condition. If you have the former, it covers the use case for
the latter no?
That said, Simon’s reservations about introducing non-conditional
attributes into if kind of bother me too. Would it make sense to
provide for named ranges in the citation and bibliography headers,
which can then be referenced as arguments to the match attribute
inside if, with the variable to be counted set in a special
attribute? That way valid style code would always specify only one
variable to be counted, and only one that is in fact countable.
Something like this:
[...]
[... ]
[...]
This would fit together with a means of controlling the number of
names (and the way of joining them as per status quo). Suffixes would
be supplied explicitly with text tags, as in Bruce’s example.
A thought, anyway.
Can we move outside of names? If so, I like this idea
generally, with a couple of concerns:
- It’s a little verbose; this is 9-10 extra lines per style (although
with macros, it shouldn’t impair clarity)
- It isn’t backwards compatible (although it would be easy to convert
existing styles)
Simon
…
Can we move outside of names? If so, I like this idea generally,
with a couple of concerns:
- It’s a little verbose; this is 9-10 extra lines per style (although with
macros, it shouldn’t impair clarity)
So you’re thinking something like:
… and:
…? Why move the choose outside of names? Am not opposed (I have no
opinion really); just not immediately seeing.
- It isn’t backwards compatible (although it would be easy to convert
existing styles)
Right. Would be true of adding the et-al element as well though.
Bruce
As I see this issue come up again on the Zotero forums, I’ll bump this
question for Simon.
As I see this issue come up again on the Zotero forums, I’ll bump this
question for Simon.
…
Can we move outside of names? If so, I like this idea
generally,
with a couple of concerns:
- It’s a little verbose; this is 9-10 extra lines per style
(although with
macros, it shouldn’t impair clarity)
So you’re thinking something like:
… and:
…? Why move the choose outside of names? Am not opposed (I have no
opinion really); just not immediately seeing.
Allowing macros in , or adding to , would
require some significant schema complications, since right now only a
very limited subset of elements are allowed in (or at least
that’s what I recall, since is essentially a variable type).
- It isn’t backwards compatible (although it would be easy to
convert
existing styles)
Right. Would be true of adding the et-al element as well though.
Not necessarily. We could revert to formatting as we do now if no et-
al element is present.
Simon