I think I’ve finally gotten my head around the collapsing joins thing.
Here’s a fresh proposal. It contradicts everything I’ve said about
this so far, so a fresh thread.
We’re getting tangled up with a maze of options and attributes. We
have year-suffix-delimiter, the delimiter on layout, and the
delimiters on individual elements, and even in discussion we’re having
trouble keeping straight which applies in a given use case. This is
not a good sign.
Basically all that’s happening is that the first element rendered sets
the prefix to be used in the event that it is joined with a previous
rendered citation, and that is trumped by a range delimiter. If we
express it that way in the CSL, I think it will dispel the confusion.
We could do that with attributes “join-prefix” and
"range-join-prefix", set on each of the relevant elements. A test is
attached that illustrates the approach. It will correctly handle new
use cases that Rinze has put forward, and (although it buries the
prefix inside the CSL, which I originally thought would be hard to
follow), I think it’s easier to understand on the face of the CSL.
See what you think.
Frank
I’ve not had a chance to look at this recent thread yet, but …On Tue, Apr 7, 2009 at 8:38 PM, Frank Bennett <@Frank_Bennett> wrote:
I think I’ve finally gotten my head around the collapsing joins thing.
Here’s a fresh proposal. It contradicts everything I’ve said about
this so far, so a fresh thread.
We’re getting tangled up with a maze of options and attributes. We
have year-suffix-delimiter, the delimiter on layout, and the
delimiters on individual elements, and even in discussion we’re having
trouble keeping straight which applies in a given use case. This is
not a good sign.
Basically all that’s happening is that the first element rendered sets
the prefix to be used in the event that it is joined with a previous
rendered citation, and that is trumped by a range delimiter. If we
express it that way in the CSL, I think it will dispel the confusion.
We could do that with attributes “join-prefix” and
“range-join-prefix”, set on each of the relevant elements. A test is
attached that illustrates the approach. It will correctly handle new
use cases that Rinze has put forward, and (although it buries the
prefix inside the CSL, which I originally thought would be hard to
follow), I think it’s easier to understand on the face of the CSL.
See what you think.
Notwithstanding what I think about it, it would be a
backward-incompatible change. Is the problem solved worth the problems
it would create?
Bruce
I’ve not had a chance to look at this recent thread yet, but …
I think I’ve finally gotten my head around the collapsing joins thing.
Here’s a fresh proposal. It contradicts everything I’ve said about
this so far, so a fresh thread.
We’re getting tangled up with a maze of options and attributes. We
have year-suffix-delimiter, the delimiter on layout, and the
delimiters on individual elements, and even in discussion we’re having
trouble keeping straight which applies in a given use case. This is
not a good sign.
Basically all that’s happening is that the first element rendered sets
the prefix to be used in the event that it is joined with a previous
rendered citation, and that is trumped by a range delimiter. If we
express it that way in the CSL, I think it will dispel the confusion.
We could do that with attributes “join-prefix” and
“range-join-prefix”, set on each of the relevant elements. A test is
attached that illustrates the approach. It will correctly handle new
use cases that Rinze has put forward, and (although it buries the
prefix inside the CSL, which I originally thought would be hard to
follow), I think it’s easier to understand on the face of the CSL.
See what you think.
Notwithstanding what I think about it, it would be a
backward-incompatible change. Is the problem solved worth the problems
it would create?
I think so, but I’m not going to absorb the pain, so my opinion there
doesn’t count for much. Simon or Elena may have views.
You could implement both join mechanisms, and deprecate the current
style. The syntax doesn’t clash. That might satisfy everyone, and at
some point you could drop the current options-based stuff. Note that
Rintze has identified a need for a further option, to handle the join
used on a year when the author is collapsed. If that were implemented
only through the new method, it would be a bit of candy to attract
style designers to adjust their code.
A related item just occurred to me, which is kind of important. The
year-suffix delimiters are numbers, and things will be much less messy
at the implementation level if they are expressed with a number
element:
The current schema will work, but in order to implement range joins of
the suffixes, every implementation will want to trap the
“variable-suffix” variable and recharacterize it as a number
internally. It would save a lot of confusion in the code if it were
just declared to be a number in the first place. That would also let
editors use roman numbers, or parens-enclosed arabic numerals, or
whatever as disambiguation strings, and they would all delimit and
range correctly out of the box, using standard numbers handling
machinery. A text element with a year-suffix var is bound to a single
style of presentation, which could bite down the road
(year-suffix-roman … year-suffix-roman-square-braces …).
Frank
I’ve not had a chance to look at this recent thread yet, but …
I think I’ve finally gotten my head around the collapsing joins thing.
Here’s a fresh proposal. It contradicts everything I’ve said about
this so far, so a fresh thread.
We’re getting tangled up with a maze of options and attributes. We
have year-suffix-delimiter, the delimiter on layout, and the
delimiters on individual elements, and even in discussion we’re having
trouble keeping straight which applies in a given use case. This is
not a good sign.
Basically all that’s happening is that the first element rendered sets
the prefix to be used in the event that it is joined with a previous
rendered citation, and that is trumped by a range delimiter. If we
express it that way in the CSL, I think it will dispel the confusion.
We could do that with attributes “join-prefix” and
“range-join-prefix”, set on each of the relevant elements. A test is
attached that illustrates the approach. It will correctly handle new
use cases that Rinze has put forward, and (although it buries the
prefix inside the CSL, which I originally thought would be hard to
follow), I think it’s easier to understand on the face of the CSL.
See what you think.
Notwithstanding what I think about it, it would be a
backward-incompatible change. Is the problem solved worth the problems
it would create?
I think so, but I’m not going to absorb the pain, so my opinion there
doesn’t count for much. Simon or Elena may have views.
You could implement both join mechanisms, and deprecate the current
style. The syntax doesn’t clash. That might satisfy everyone, and at
some point you could drop the current options-based stuff. Note that
Rintze has identified a need for a further option, to handle the join
used on a year when the author is collapsed. If that were implemented
only through the new method, it would be a bit of candy to attract
style designers to adjust their code.
A related item just occurred to me, which is kind of important. The
year-suffix delimiters are numbers, and things will be much less messy
at the implementation level if they are expressed with a number
element:
The current schema will work, but in order to implement range joins of
the suffixes, every implementation will want to trap the
“variable-suffix” variable and recharacterize it as a number
internally. It would save a lot of confusion in the code if it were
just declared to be a number in the first place. That would also let
editors use roman numbers, or parens-enclosed arabic numerals, or
whatever as disambiguation strings, and they would all delimit and
range correctly out of the box, using standard numbers handling
machinery. A text element with a year-suffix var is bound to a single
style of presentation, which could bite down the road
(year-suffix-roman … year-suffix-roman-square-braces …).
Before the day begins in the US, I should note that I don’t have
particularly strong feelings about the first item. Things will work
as well with either approach (options or join attributes), so if it’s
awkward to change the schema, I’ll happily fold. It’s important to
cover the bases, though. From what we know so far, with the options
approach we would need something like the following options:
It’s a judgement call whether the two range-delimiter options could be
combined to a single one. If it’s safe to combine them, the range
character could be defined as a locale term instead, and that option
(i.e. the latter two of the four above) would not be needed.
Frank
…
Before the day begins in the US, I should note that I don’t have
particularly strong feelings about the first item. Things will work
as well with either approach (options or join attributes), so if it’s
awkward to change the schema, I’ll happily fold. It’s important to
cover the bases, though.
We shouldn’t necessarily assume this last bit. There are some rules
that are so stupid and awkward to implement that it’s not worth our
bother. So we always need to keep in view the “won’t fix” option.
I’ve not read this whole earlier thread, and will just assume you’ve
condensed it down to its essence.
From what we know so far, with the options
approach we would need something like the following options:
The last one seems strange. What’s the use case? Surely it’s not
something so silly as saying that what normally would be (Doe, 1999,
2000) ought to be (Doe, 1999-2000)?
If it is, then my first impulse would be to put that in the “won’t
fix” category, with the logic that it’s a stupid convention that’s a)
confusing to a reader, b) adds processing complexity (even if
minimal), and c) of negligible space-saving benefit.
Bruce
You’re right, that last one doesn’t make any sense.
Assuming that we’re going with the options based approach, here is a
short description of each of the options and what they do, as a first
shot at descriptive notes for the schema:
collapse=“year” causes output of the author name to be suppressed
if it is the same as in the preceding cite:
Smith 1990, 1991On Wed, Apr 8, 2009 at 11:48 PM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
On Wed, Apr 8, 2009 at 8:57 AM, Frank Bennett <@Frank_Bennett> wrote:
…
Before the day begins in the US, I should note that I don’t have
particularly strong feelings about the first item. Things will work
as well with either approach (options or join attributes), so if it’s
awkward to change the schema, I’ll happily fold. It’s important to
cover the bases, though.
We shouldn’t necessarily assume this last bit. There are some rules
that are so stupid and awkward to implement that it’s not worth our
bother. So we always need to keep in view the “won’t fix” option.
I’ve not read this whole earlier thread, and will just assume you’ve
condensed it down to its essence.
From what we know so far, with the options
approach we would need something like the following options:
The last one seems strange. What’s the use case? Surely it’s not
something so silly as saying that what normally would be (Doe, 1999,
2000) ought to be (Doe, 1999-2000)?
If it is, then my first impulse would be to put that in the “won’t
fix” category, with the logic that it’s a stupid convention that’s a)
confusing to a reader, b) adds processing complexity (even if
minimal), and c) of negligible space-saving benefit.
collapse=“year-suffix” causes output of both the author name and the
year to be suppressed if they are the same as in the preceding cite:
Smith 1990a,b
name=“year-delimiter” specifies the string used to join a year to the
preceding cite when it is the first item rendered. With a value of
", " combined with collapse=“year” it will produce the following:
Smith 1990, 1991; Jones 1992
name=“year-suffix-delimiter” specifies the string used to join a
year-suffix to the preceding cite when it is the first item rendered.
With a value of “,”, combined with collapse=“year-suffix” it will produce
the following:
Smith 1990a,b, 1991; Jones 1992
name=“year-suffix-range-delimiter” specifies that a sequence of
three or more year-suffixes should be collapsed, with the first and
last values separated by the specified string. With a value of
“-”, combined with collapse=“year-suffix”, it will produce the
following:
Smith 1990a-c; Jones 1992
Frank
Assuming that we’re going with the options based approach, here is a
short description of each of the options and what they do, as a first
shot at descriptive notes for the schema:
collapse=“year” causes output of the author name to be suppressed
if it is the same as in the preceding cite:
Smith 1990, 1991
collapse=“year-suffix” causes output of both the author name and the
year to be suppressed if they are the same as in the preceding cite:
Smith 1990a,b
Shouldn’t ‘author’ be replaced by ‘contributor’?
name=“year-delimiter” specifies the string used to join a year to the
preceding cite when it is the first item rendered. With a value of
", " combined with collapse=“year” it will produce the following:
Smith 1990, 1991; Jones 1992
One thing to keep in mind here is that ", " is currently hardcoded in Zotero
as a year-delimiter. Current author-date styles in the Zotero Style
Repository will break if no delimiter is added by citeproc when this option
is absent (which I guess is the desired behavior).
RintzeOn Thu, Apr 9, 2009 at 12:03 AM, Frank Bennett <@Frank_Bennett>wrote: