I realized this morning that the et-al-use-last / names-use-last
proposal for APA 6th has been cooling its heels in the tracker. I
hadn’t yet implemented names-use-last, but I’ve just done so. If
Rintze’s proposal is accepted, it can go forward in the schema.
Frank
After that long back-and-forth, where did we end up WRT to both schema
and spec changes? Are all questions resolved?
Bruce
It was a bit chaotic at the start, but we seem to have settled on the
following, from Rintze:On Sun, Nov 14, 2010 at 8:55 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
On Sat, Nov 13, 2010 at 6:48 PM, Frank Bennett <@Frank_Bennett> wrote:
I realized this morning that the et-al-use-last / names-use-last
proposal for APA 6th has been cooling its heels in the tracker. I
hadn’t yet implemented names-use-last, but I’ve just done so. If
Rintze’s proposal is accepted, it can go forward in the schema.http://bitbucket.org/bdarcus/csl-schema/issue/14/list-last-authors-name-in-truncated
After that long back-and-forth, where did we end up WRT to both schema
and spec changes? Are all questions resolved?
et-al-use-last
When et-al-use-last is set to “true” (the default is “false”), and
et-al abbreviation is active, the “ellipsis” term replaces the “et-al”
term, and is followed by the last author. et-al-use-last only has an
effect when the number set to et-al-use-first is at least 2 lower than
the number set to et-al-min. An example:
A. Goffeau, B. G. Barrell, H. Bussey, R. W. Davis, B. Dujon, H.
Feldmann, … S. G. Oliver
plus
On the cs:key element, names-use-last may be used to override the
value of et-al-use-last, in the same way that names-min and
names-use-first may be used to override the values of et-al-min and
et-al-use-first.
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.
It appears that an “ellipsis” term should be added to the locale files
to support this, since the typography of ellipses varies slightly
between languages. So we’ll also need a go-ahead on that before
proceeding with edits to the locale files.
Frank
Rinze - thoughts or input?
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.
Agreed. Adding the ability to render more than one name at the end would
make things much more complex, and isn’t required for APA.
It appears that an “ellipsis” term should be added to the locale files
to support this, since the typography of ellipses varies slightly
between languages. So we’ll also need a go-ahead on that before
proceeding with edits to the locale files.
As I noted on the issue tracker, adding a new term to the CSL 1.0 locale
files would break validation against the CSL 1.0 schema. I could create a
1.0 branch, and perhaps a downgrade.xsl to allow for the automatic
conversion of trunk to CSL 1.0 locale files (for now, it would just strip
the “ellipsis” term).
RintzeOn Sat, Nov 13, 2010 at 9:12 PM, Frank Bennett <@Frank_Bennett>wrote:
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end would
make things much more complex, and isn’t required for APA.
So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?
It appears that an “ellipsis” term should be added to the locale files
to support this, since the typography of ellipses varies slightly
between languages. So we’ll also need a go-ahead on that before
proceeding with edits to the locale files.As I noted on the issue tracker, adding a new term to the CSL 1.0 locale
files would break validation against the CSL 1.0 schema. I could create a
1.0 branch, and perhaps a downgrade.xsl to allow for the automatic
conversion of trunk to CSL 1.0 locale files (for now, it would just strip
the “ellipsis” term).
I wonder if we should look at the tweaking the schema so that
additions like this don’t break things?
Bruce
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end would
make things much more complex, and isn’t required for APA.So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?
Only when there would be a very strong demand for that, but I don’t see that
happening anytime soon.
It appears that an “ellipsis” term should be added to the locale files
to support this, since the typography of ellipses varies slightly
between languages. So we’ll also need a go-ahead on that before
proceeding with edits to the locale files.As I noted on the issue tracker, adding a new term to the CSL 1.0 locale
files would break validation against the CSL 1.0 schema. I could create a
1.0 branch, and perhaps a downgrade.xsl to allow for the automatic
conversion of trunk to CSL 1.0 locale files (for now, it would just strip
the “ellipsis” term).I wonder if we should look at the tweaking the schema so that
additions like this don’t break things?
That’s possible as well, but that would be a post-CSL 1.0 change (we could
of course release a CSL 1.0.1 schema to deal with this). The new “ellipsis”
term would break validation against the original CSL 1.0 schema.
Rintze
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end would
make things much more complex, and isn’t required for APA.So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?Only when there would be a very strong demand for that, but I don’t see that
happening anytime soon.
Right, but what I’m saying here is that I don’t want to change the
datatype value in the future. If we settle on a boolean, then we
shouldn’t ever change it.
OTOH, if there’s a chance that it might change, then we should define
it as an integer, but constrain its value to “1” now.
It appears that an “ellipsis” term should be added to the locale files
to support this, since the typography of ellipses varies slightly
between languages. So we’ll also need a go-ahead on that before
proceeding with edits to the locale files.As I noted on the issue tracker, adding a new term to the CSL 1.0 locale
files would break validation against the CSL 1.0 schema. I could create
a
1.0 branch, and perhaps a downgrade.xsl to allow for the automatic
conversion of trunk to CSL 1.0 locale files (for now, it would just
strip
the “ellipsis” term).I wonder if we should look at the tweaking the schema so that
additions like this don’t break things?That’s possible as well, but that would be a post-CSL 1.0 change (we could
of course release a CSL 1.0.1 schema to deal with this). The new “ellipsis”
term would break validation against the original CSL 1.0 schema.
What I had in mind here is defining the term names independently of
the CSL structure somehow.
This brings up the question whether we can change outboard schema
files (for types, variable, and term names) independent of CSL
releases?
Bruce
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end
would
make things much more complex, and isn’t required for APA.So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?Only when there would be a very strong demand for that, but I don’t see
that
happening anytime soon.Right, but what I’m saying here is that I don’t want to change the
datatype value in the future. If we settle on a boolean, then we
shouldn’t ever change it.OTOH, if there’s a chance that it might change, then we should define
it as an integer, but constrain its value to “1” now.
It’s very easy to convert “true” to “1”, if the need arises. As long as the
change goes into a backwards-incompatible CSL update (along with another
upgrade.xsl), people would hardly notice. As for your remark, I think
there’s only a very small chance that it’ll be changed in the next 5 years,
but my crystal ball isn’t that reliable.
This brings up the question whether we can change outboard schema
files (for types, variable, and term names) independent of CSL
releases?
Shouldn’t we keep things together to make sure the different CSL
implementations are compatible as much as possible?
Rintze
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end
would
make things much more complex, and isn’t required for APA.So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?Only when there would be a very strong demand for that, but I don’t see
that
happening anytime soon.Right, but what I’m saying here is that I don’t want to change the
datatype value in the future. If we settle on a boolean, then we
shouldn’t ever change it.OTOH, if there’s a chance that it might change, then we should define
it as an integer, but constrain its value to “1” now.It’s very easy to convert “true” to “1”, if the need arises. As long as the
change goes into a backwards-incompatible CSL update (along with another
upgrade.xsl), people would hardly notice. As for your remark, I think
there’s only a very small chance that it’ll be changed in the next 5 years,
but my crystal ball isn’t that reliable.
If it will help to move things forward, shall we agree to make
names-use-last a numeric option, with possible values of “0” or “1”?
This brings up the question whether we can change outboard schema
files (for types, variable, and term names) independent of CSL
releases?
Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.
There are two points for final confirmation.
The proposal allows only one name to be included from the end of a
list of names, but there are no known styles that require more than
one. The use of “and” with more than one is unclear, so in the
absence of a style that requires it, we would like to start with a
boolean option and a single name.Agreed. Adding the ability to render more than one name at the end
would
make things much more complex, and isn’t required for APA.So just to be clear, then: we won’t be changing this later? E.g. we’re
not going to now say the value is boolean, and later say it’s an
integer?Only when there would be a very strong demand for that, but I don’t see
that
happening anytime soon.Right, but what I’m saying here is that I don’t want to change the
datatype value in the future. If we settle on a boolean, then we
shouldn’t ever change it.OTOH, if there’s a chance that it might change, then we should define
it as an integer, but constrain its value to “1” now.It’s very easy to convert “true” to “1”, if the need arises. As long as the
change goes into a backwards-incompatible CSL update (along with another
upgrade.xsl), people would hardly notice. As for your remark, I think
there’s only a very small chance that it’ll be changed in the next 5 years,
but my crystal ball isn’t that reliable.If it will help to move things forward, shall we agree to make
names-use-last a numeric option, with possible values of “0” or “1”?
Correction:
If it will help to move things forward, shall we agree to make
et-al-use-last and names-use-last numeric options, with possible
values of “0” or “1”?
This brings up the question whether we can change outboard schema
files (for types, variable, and term names) independent of CSL
releases?Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.
As per previous message:
Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.
Fine with me. (I’ll update the schema/spec proposals if we go this way)
RintzeOn Thu, Nov 18, 2010 at 3:31 PM, Frank Bennett <@Frank_Bennett>wrote:
If it will help to move things forward, shall we agree to make
et-al-use-last and names-use-last numeric options, with possible
values of “0” or “1”?
In general, this is my preference for future-proofness. But what would
a value of “0” indicate?
Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.Fine with me. (I’ll update the schema/spec proposals if we go this way)
I didn’t really follow this issue. Whatever you guys think it fine is OK by me.
Bruce
If it will help to move things forward, shall we agree to make
et-al-use-last and names-use-last numeric options, with possible
values of “0” or “1”?In general, this is my preference for future-proofness. But what would
a value of “0” indicate?
“0” would correspond to “false” (i.e., no et-al-use-last abbreviation of
name lists takes place). It would be the default.
Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.
Fine with me. (I’ll update the schema/spec proposals if we go this way)
I didn’t really follow this issue. Whatever you guys think it fine is OK by
me.
There might be requests for localized ellipses and/or three periods instead
of a true ellipsis character (see also
Ellipsis - Wikipedia ), but for
this we’d have to add an ellipsis term. As we discussed, this requires
branching of the CSL locales to ensure we have a set that validates against
the CSL 1.0 schema. The flexibility of having a customizable term is
desirable, but shouldn’t hold back implementation of et-al-use-last. But we
can always revisit this if we find other terms that have to be added to the
CSL locale files.
Rintze
If it will help to move things forward, shall we agree to make
et-al-use-last and names-use-last numeric options, with possible
values of “0” or “1”?In general, this is my preference for future-proofness. But what would
a value of “0” indicate?“0” would correspond to “false” (i.e., no et-al-use-last abbreviation of
name lists takes place). It would be the default.
From the perspective of a strongly typed programming language this is
pure madness: a number should be a number and indicate a succession of
quantities, and a boolean should be a boolean, a data type holding
only two possible values What would a “2” mean?
Seriously, if there are only two possible values, a boolean would be
better, in my opinion.
Again, if it will help move things forward on this point, we can use a
hard-coded ellipsis character in the first instance.
Frank already implemented all this with a hard-coded ellipsis - there
are already a few tests in the test-suite repository. I’m going to do
the same since pandoc has its own hard-coded ellipsis - this way my
code will pass all the sort tests.
Andrea
ps (for Frank): BTW a “bibliography-nosort” mode in the test suite
(see sort_BibliographyNosortOption.txt) is confusing. I spent half an
hour in trying to understand why my code was failing just to discover
about this new fancy new mode…
If it will help to move things forward, shall we agree to make
et-al-use-last and names-use-last numeric options, with possible
values of “0” or “1”?In general, this is my preference for future-proofness. But what would
a value of “0” indicate?“0” would correspond to “false” (i.e., no et-al-use-last abbreviation of
name lists takes place). It would be the default.From the perspective of a strongly typed programming language this is
pure madness: a number should be a number and indicate a succession of
quantities, and a boolean should be a boolean, a data type holding
only two possible values What would a “2” mean?
It would mean the last two names are preserved; e.g.:
Doe, Smith … Jones, Adams
Seriously, if there are only two possible values, a boolean would be
better, in my opinion.
The issue is whether there will only ever be two options. If we go
with the boolean, we are saying that. If people are comfortable with
that, then that’s fine with me. Is that your position?
…
Bruce
I do not have a position since I was not aware that such a possible
way of formatting contributors’ names was in use, actually.
My remarks were only related to data type consistency.
Andrea
OK, so let’s review:
This proposal is driven by the needs of the new APA style, which has
the requirement that shortening of author lists happens not by doing
the traditional et al reduction, but instead by replacing all author
names after the first n, EXCEPT the last, with ellipses.
The proposal to add this attribute with a boolean value is designed
for this precise use case.
My question about this is whether we can ever imagine that a style may
come along that says:
“Replace all author names after the first n, EXCEPT the last TWO, with
ellipses.”
The idea to have the value and integer, but constrain the values for
now, is thus a way to leave open the possibility of the latter, while
supporting APA 6 now.
So we have two choices:
Bruce
“no future flexibility” meaning that a non-backwards compatible change would
have to be made to the CSL schema if we switch from boolean to numeric
values (requiring upgrading of existing styles, comparable to the conversion
of CSL 0.8 styles to CSL 1.0 using upgrade.xsl).
Rintze
I’m also worried about processing code.
I’m pretty opposed to changing a data-type at any point, and I’m
assuming Andrea will agree with me, given that his code depends on
clear datatypes (he literally has to define the value of every data
structure, and stuff will break if the input is wrong).
So I don’t have a strong opinion on this, other than that if we choose
a data-type (positive integer or boolean) we stick with it in the
future.
Bruce