Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about sort_ConditionalMacroDates.txt #31

Open
jgm opened this issue Jun 25, 2020 · 2 comments
Open

Question about sort_ConditionalMacroDates.txt #31

jgm opened this issue Jun 25, 2020 · 2 comments

Comments

@jgm
Copy link

@jgm jgm commented Jun 25, 2020

I'm baffled by this one -- there must be something I'm not understanding.

We have

    <sort>
      <key macro="issued-date" sort="ascending"/>
    </sort>

and the issued-date macro looks like this:

  <macro name="issued-date">
    <group prefix="[" suffix="]">
    <text variable="title"/>
    <choose>
      <if type="book">
        <date variable="issued">
          <date-part name="year" form="long"/>
        </date>
      </if>
      <else>
        <date variable="issued">
          <date-part name="year" form="long" suffix="-"/>
          <date-part name="month" form="numeric" suffix="-"/>
          <date-part name="day" form="numeric"/>
        </date>
      </else>
    </choose>
    </group>
  </macro>

Note the <text variable="title"/> which appears before the date. So the output of this macro for the various items should be something like

item-1:  title 220021025
item-2:  title 32002
item-3:  title 120021025

And that should give (for an ascending sort): item-3, item-1, item-2, resulting in:

Title 1
Title 2
Title 3

Instead, the expected result is

>>===== RESULT =====>>
<div class="csl-bib-body">
  <div class="csl-entry">Title 3</div>
  <div class="csl-entry">Title 1</div>
  <div class="csl-entry">Title 2</div>
</div>
<<===== RESULT =====<<

Here we get sorting on the date, apparently ignoring the title (and indeed, removing the line with <text variable="title"/> makes no difference to citeproc.js).

There is no way an ascending sort that looks at titles before dates could give this result. So I'm confused! What am I missing?

@adam3smith
Copy link
Member

@adam3smith adam3smith commented Jun 25, 2020

This one doesn't make any sense to me either.
Some quick tests show that:

  1. citeproc-js indeed behaves this way (as one would hope given the test)
  2. This is unrelated to the numbers in the title: Title A, Title B, Title C behave the exact same way
<sort>
  <key variable="title"/>
  <key macro="issued-date"/>
</sort>

Sorts as

Title 1
Title 2
Title 3

as expected (with or without the title being part of the issued-date variable).

It'd be great if @fbennett could chime in, but I'd currently call this as an incorrect test and suggest changing it (likely by just removing the title variable from the macro since the test is about dates)

@fbennett
Copy link
Member

@fbennett fbennett commented Jun 25, 2020

Ah, I remember this one. Rintze and I discussed the case in 2013, back in the BitBucket days. In the discussion Rintze also questioned the discarding of the non-date text from the macro when generating keys, and noted that doing so is an off-spec invention.

As I note in the linked thread, intermixing date and string values in a single key can't be made to produce intuitive sort results. Dates are a bit special: keys for non-date variables are simple strings or numbers that can be derived directly from the variable; but date keys must generate a machine-readable sort key that takes account of the date-parts element of the rendered form. As a result, there are cases in which a macro containing a condition must be used to produce the date key (APA is mentioned in the discussion).

The need to express date keys in a macro can be addressed in one of two ways. One would be to assume that such macros will always contain exactly one date. The other would be to extract a date from an existing macro, and ignore everything else it contains. citerproc-js adopts the latter approach. While it (obviously) can create confusion, it has the advantage that, if a style designer mistakenly assumes that a macro combining two elements (creator and date, say) will treat the contents as two atomic keys, the attempt will throw bad sort results immediately. (There is an example of this in the repo, in the initial history of deutsche-sprache.csl, where the initial checkin of the style is followed immediately by an amendment to the sort keys.)

So that's the reasoning behind it. On a quick check of the repository (based on macro names alone), it looks like a few styles would need to be amended to add and call date-only macros if the former approach is preferred.

beltz-padagogik.csl
berlin-school-of-economics-and-law-international-marketing-management.csl
biuletyn-polskiego-towarzystwa-jezykoznawczego.csl
deutsche-sprache.csl
hochschule-hannover-soziale-arbeit.csl
keel-ja-kirjandus.csl
zeitschrift-fur-qualitative-forschung.csl
wirtschaftsuniversitat-wien-abteilung-fur-bildungswissenschaft.csl
wirtschaftsuniversitat-wien-unternehmensrechnung-und-controlling.csl
wirtschaftsuniversitat-wien-wirtschaftspadagogik.csl
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.