It gives me great pleasure to announce that the AGU sort example now
passes in citeproc-js, using form=“count” and small tweaks to the key
element:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-js/branches/fbennett/std/humans/sort_AguStyle.txt?revision=898&view=markup
The tweak is to permit et-al-min and et-al-use-first directly as named
attributes on the key element. This seems to be the right place for
them; it gives pinpoint control over the number of names included in
individual keys and counts, and the et-al attribute logic incidentally
works out perfectly for the sort AGU rules. It’s nice and compact,
and I feel like I’ve done some decent work today.
I’ve left the schema note in the test as “0.9 experimental” for now.
Will look forward to further comments from Bruce and others.
Frank
It gives me great pleasure to announce that the AGU sort example now
passes in citeproc-js,
Nice job.
using form=“count” and small tweaks to the key
element:
XBib download | SourceForge.net
The tweak is to permit et-al-min and et-al-use-first directly as named
attributes on the key element. This seems to be the right place for
them; it gives pinpoint control over the number of names included in
individual keys and counts, and the et-al attribute logic incidentally
works out perfectly for the sort AGU rules. It’s nice and compact,
and I feel like I’ve done some decent work today.
Can you just explain how this relates to the previous start/end
attributes you had suggested? Are you suggesting these in lieu of
those?
Bruce
It gives me great pleasure to announce that the AGU sort example now
passes in citeproc-js,
Nice job.
using form=“count” and small tweaks to the key
element:
XBib download | SourceForge.net
The tweak is to permit et-al-min and et-al-use-first directly as named
attributes on the key element. This seems to be the right place for
them; it gives pinpoint control over the number of names included in
individual keys and counts, and the et-al attribute logic incidentally
works out perfectly for the sort AGU rules. It’s nice and compact,
and I feel like I’ve done some decent work today.
Can you just explain how this relates to the previous start/end
attributes you had suggested? Are you suggesting these in lieu of
those?
Yes, the existing et-al logic does everything that’s necessary.
start/end were not needed. I don’t think they ever will be; if
someone wants to sort documents by the second contributor only, it
would be fair to tell them to stop teasing and go away. 
Frank
It gives me great pleasure to announce that the AGU sort example now
passes in citeproc-js,
Nice job.
using form=“count” and small tweaks to the key
element:
XBib download | SourceForge.net
The tweak is to permit et-al-min and et-al-use-first directly as
named
attributes on the key element. This seems to be the right place for
them; it gives pinpoint control over the number of names included in
individual keys and counts, and the et-al attribute logic
incidentally
works out perfectly for the sort AGU rules. It’s nice and compact,
and I feel like I’ve done some decent work today.
Can you just explain how this relates to the previous start/end
attributes you had suggested? Are you suggesting these in lieu of
those?
Yes, the existing et-al logic does everything that’s necessary.
start/end were not needed. I don’t think they ever will be; if
someone wants to sort documents by the second contributor only, it
would be fair to tell them to stop teasing and go away.
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Bruce
It gives me great pleasure to announce that the AGU sort example now
passes in citeproc-js,
Nice job.
using form=“count” and small tweaks to the key
element:
XBib download | SourceForge.net
The tweak is to permit et-al-min and et-al-use-first directly as
named
attributes on the key element. This seems to be the right place for
them; it gives pinpoint control over the number of names included in
individual keys and counts, and the et-al attribute logic
incidentally
works out perfectly for the sort AGU rules. It’s nice and compact,
and I feel like I’ve done some decent work today.
Can you just explain how this relates to the previous start/end
attributes you had suggested? Are you suggesting these in lieu of
those?
Yes, the existing et-al logic does everything that’s necessary.
start/end were not needed. I don’t think they ever will be; if
someone wants to sort documents by the second contributor only, it
would be fair to tell them to stop teasing and go away.
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Hmm. I can see that it might be confusing the call these
et-al-something. They limit the number of included names in exactly
the same way as et-al-min/et-al-use-first (and both are needed, to
disable a key in the way AGU requires for its third grouping). But
(although it’s not visible) they only deliver the names to the key;
“et al.” and any other decorations are omitted because they would mess
up the sort. I think that means that the semantics are the same, but
a separate explanation is required in the schema, because they are
used for something different. It might also be better to give them a
distinct basename, like names-min and names-use-first, to highlight
the difference. I didn’t think that through while lashing it
together.
Here’s a possible text for the schema, just to throw it out there (I
hope I haven’t messed up on the schema syntax, but it’s only a hope):
The number of names included in a sort key (whether
as a list of names or as a count value) can be
controlled using the attributes names-min and
names-use-first. The semantics of these attributes
are the same as the et-al-min and et-al-use-first
options, but their use is restricted to sort keys.
Note that “et al.” will not be included in the key.
attribute names-min { xsd:integer }?,
attribute names-use-first { xsd:integer }?
(text also attached as a patch)
Frank
schema_sort_proposal.patch (865 Bytes)
…
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Hmm. I can see that it might be confusing the call these
et-al-something. They limit the number of included names in exactly
the same way as et-al-min/et-al-use-first (and both are needed, to
disable a key in the way AGU requires for its third grouping). But
(although it’s not visible) they only deliver the names to the key;
“et al.” and any other decorations are omitted because they would mess
up the sort. I think that means that the semantics are the same, but
a separate explanation is required in the schema, because they are
used for something different. It might also be better to give them a
distinct basename, like names-min and names-use-first, to highlight
the difference.
So conceptually it’s the same, too, as the more generic “count-min”
and “count-max” attribute I had been proposing; it’s just that a) you
restrict it to names, and b) you allow it to be used on the key macro
call?
Bruce
…
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Hmm. I can see that it might be confusing the call these
et-al-something. They limit the number of included names in exactly
the same way as et-al-min/et-al-use-first (and both are needed, to
disable a key in the way AGU requires for its third grouping). But
(although it’s not visible) they only deliver the names to the key;
“et al.” and any other decorations are omitted because they would mess
up the sort. I think that means that the semantics are the same, but
a separate explanation is required in the schema, because they are
used for something different. It might also be better to give them a
distinct basename, like names-min and names-use-first, to highlight
the difference.
So conceptually it’s the same, too, as the more generic “count-min”
and “count-max” attribute I had been proposing; it’s just that a) you
restrict it to names, and b) you allow it to be used on the key macro
call?
Ah. More lights just went on, and I should revise this proposal.
The way to handle this, I think, is just to allow et-al-min and
et-al-use-first as attributes on the names element. That would solve
both this one, plus the group-by issue, in one go. For the use case
behind group-by, it would permit subsequent references to use a
smaller set of creator names, and that would trigger correct
year-suffixes. For AGU, it will do exactly what the current
sort_AguStyle.txt test does (if the et al. term is dropped from names
for sorting purposes, which is the right thing to do). The only
difference is that the min/use-first declaration moves into the
creator macro, where it’s more generally useful.
My chatter above may be hard to follow, I’ll formalize both of these
solutions with tests later. But in case it raises eyebrows, I should
note that permitting et-al-min/et-al-use-first as attributes on names
would be a backward-compatible change. The existing option would set
the default, and the attributes would take precedence if supplied.
The essential catch with max/min is that you have to choose between
counting totals across a list of variables and counting the first
non-nil variable. With the second choice, handling creator
substitutions becomes complex. With the first choice, the syntax
needed to handle AGU is simpler, but you can’t get totals.
Frank
…
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Hmm. I can see that it might be confusing the call these
et-al-something. They limit the number of included names in exactly
the same way as et-al-min/et-al-use-first (and both are needed, to
disable a key in the way AGU requires for its third grouping). But
(although it’s not visible) they only deliver the names to the key;
“et al.” and any other decorations are omitted because they would mess
up the sort. I think that means that the semantics are the same, but
a separate explanation is required in the schema, because they are
used for something different. It might also be better to give them a
distinct basename, like names-min and names-use-first, to highlight
the difference.
So conceptually it’s the same, too, as the more generic “count-min”
and “count-max” attribute I had been proposing; it’s just that a) you
restrict it to names, and b) you allow it to be used on the key macro
call?
Ah. More lights just went on, and I should revise this proposal.
The way to handle this, I think, is just to allow et-al-min and
et-al-use-first as attributes on the names element. That would solve
both this one, plus the group-by issue, in one go. For the use case
behind group-by, it would permit subsequent references to use a
smaller set of creator names, and that would trigger correct
year-suffixes. For AGU, it will do exactly what the current
sort_AguStyle.txt test does (if the et al. term is dropped from names
for sorting purposes, which is the right thing to do). The only
difference is that the min/use-first declaration moves into the
creator macro, where it’s more generally useful.
My chatter above may be hard to follow, I’ll formalize both of these
solutions with tests later. But in case it raises eyebrows, I should
note that permitting et-al-min/et-al-use-first as attributes on names
would be a backward-compatible change. The existing option would set
the default, and the attributes would take precedence if supplied.
The essential catch with max/min is that you have to choose between
counting totals across a list of variables and counting the first
non-nil variable. With the second choice, handling creator
substitutions becomes complex. With the first choice, the syntax
needed to handle AGU is simpler, but you can’t get totals.
(oops. “first” and “second” should have been reversed in the above.
sorry for the extra traffic.)
…
I wonder; do the semantics of these attributes change in this context?
If not, how would you describe them?
Hmm. I can see that it might be confusing the call these
et-al-something. They limit the number of included names in exactly
the same way as et-al-min/et-al-use-first (and both are needed, to
disable a key in the way AGU requires for its third grouping). But
(although it’s not visible) they only deliver the names to the key;
“et al.” and any other decorations are omitted because they would mess
up the sort. I think that means that the semantics are the same, but
a separate explanation is required in the schema, because they are
used for something different. It might also be better to give them a
distinct basename, like names-min and names-use-first, to highlight
the difference.
So conceptually it’s the same, too, as the more generic “count-min”
and “count-max” attribute I had been proposing; it’s just that a) you
restrict it to names, and b) you allow it to be used on the key macro
call?
Ah. More lights just went on, and I should revise this proposal.
The way to handle this, I think, is just to allow et-al-min and
et-al-use-first as attributes on the names element. That would solve
both this one, plus the group-by issue, in one go. For the use case
behind group-by, it would permit subsequent references to use a
smaller set of creator names, and that would trigger correct
year-suffixes. For AGU, it will do exactly what the current
sort_AguStyle.txt test does (if the et al. term is dropped from names
for sorting purposes, which is the right thing to do). The only
difference is that the min/use-first declaration moves into the
creator macro, where it’s more generally useful.
My chatter above may be hard to follow, I’ll formalize both of these
solutions with tests later. But in case it raises eyebrows, I should
note that permitting et-al-min/et-al-use-first as attributes on names
would be a backward-compatible change. The existing option would set
the default, and the attributes would take precedence if supplied.
The essential catch with max/min is that you have to choose between
counting totals across a list of variables and counting the first
non-nil variable. With the second choice, handling creator
substitutions becomes complex. With the first choice, the syntax
needed to handle AGU is simpler, but you can’t get totals.
(oops. “first” and “second” should have been reversed in the above.
sorry for the extra traffic.)
(oops again. forgot about missed et-al-subsequent-*, no need for an
attribute on names. won’t bother this thread further until I’ve
gotten formal tests in place. again, sorry for the surplus traffic.)