Better handling of title-main / title-sub splits

[denismaier]

The failure of the language condition on text-case has been fixed in release 1.2.31. It will have the unfortunate side-effect that you note (Main Title [Main title variant]: Subtitle [Subtitle variant]). That's a tough one to address, and I'm not quite sure yet how to resolve it. Some special handling of a specifically named macro might work, but folding that into the existing code would involve workarounds. It needs some thought. Suggestions on how to minimize the complexity of a solution in the hands of style authors very welcome!

Originally posted by @fbennett in https://github.com/Juris-M/citeproc-js/issues/120#issuecomment-575406252

What about this as: Currently, we have to use title-main and title-sub explicitly. What if you add an implicit mechanism that just replaces the full title with title-main + custom separator + title-sub. Then style authors can just call the full title (with the full variant), title-main (with its variant) or title-sub (with its variant). For the separator an inheritable attribute like title-sub-separator would be quite handy (was suggested by @georgd here).

What do you think? Shouldn't that solve the problem with variants, and, at the same time, make life for style authors a bit easier?

(The other option would be to make variants explicitly usable in styles. But this would be a bigger change... And make style authoring even more complicated...)

[denismaier]

Ok, I've had a quick look now. Replacing line 832 (var subJoin = vals[title.subjoin];) in load.js with

if (vals[title.subjoin] == ": ") {
    var subJoin = ". ";
} else {
    var subJoin = vals[title.subjoin];
}

isn't so bad already.

That gives me correct results for that test:

>>===== MODE =====>>
citation
<<===== MODE =====<<

>>===== RESULT =====>>
Title input with immediate colon. Should start with uppercase
<<===== RESULT =====<<

>>===== CITATION-ITEMS =====>>
[
  [
    {
      "id": "ITEM-1"
    }
  ]
]
<<===== CITATION-ITEMS =====<<

>>===== OPTIONS =====>>
{
    "uppercase_subtitles": true
}
<<===== OPTIONS =====<<

>>===== CSL =====>>
<style 
      xmlns="http://purl.org/net/xbiblio/csl"
      class="note"
      version="1.0">
  <info>
    <id />
    <title />
    <updated>2009-08-10T04:49:00+09:00</updated>
  </info>
  <citation>
    <layout delimiter="; ">
      <text variable="container-title"/>
    </layout>
  </citation>
</style>
<<===== CSL =====<<

>>===== INPUT =====>>
[
    {
        "id": "ITEM-1", 
        "container-title": "Title input with immediate colon: should start with uppercase", 
        "type": "article-journal"
    }
]
<<===== INPUT =====<<

I'm not sure how robust that is, and if there are cases that aren't covered and break the mechanism. At least, I'm not getting those odd combinations like "?." and "!." anymore, which I had at the beginning.

Perhaps, the more difficult question is which characters should be replaced by that mechanism. Only colons? Or everything perhaps question marks and exclamation marks?

(And of course, a hardcoded solution like that should be avoided. But at least, it looks like the replacement could be added easily. Perhaps the delimitor can be retrieved from an attribute?)

[denismaier]

Success...

A new attribute in attributes.js:

CSL.Attributes["@subtitle-delimiter"] = function (state, arg) {
    state.opt["subtitle-delimiter"] = arg;
};

Adjusted replacement logic:

if (state.opt["subtitle-delimiter"]) {
var subJoinDelimiter = state.opt["subtitle-delimiter"];
} else {
var subJoinDelimiter =  ": ";
}
if (vals[title.subjoin] == ": ") {
    var subJoin = subJoinDelimiter;
} else {
    var subJoin = vals[title.subjoin];
}

This test passes:

>>===== MODE =====>>
citation
<<===== MODE =====<<

>>===== RESULT =====>>
Title input with immediate colon. Should start with uppercase
<<===== RESULT =====<<

>>===== CITATION-ITEMS =====>>
[
  [
    {
      "id": "ITEM-1"
    }
  ]
]
<<===== CITATION-ITEMS =====<<

>>===== OPTIONS =====>>
{
    "uppercase_subtitles": true
}
<<===== OPTIONS =====<<

>>===== CSL =====>>
<style 
      xmlns="http://purl.org/net/xbiblio/csl"
      class="note"
      version="1.0"
      subtitle-delimiter=". "
      >
  <info>
    <id />
    <title />
    <updated>2009-08-10T04:49:00+09:00</updated>
  </info>
  <citation>
    <layout delimiter="; ">
      <text variable="container-title"/>
    </layout>
  </citation>
</style>
<<===== CSL =====<<

>>===== INPUT =====>>
[
    {
        "id": "ITEM-1", 
        "container-title": "Title input with immediate colon: should start with uppercase", 
        "type": "article-journal"
    }
]
<<===== INPUT =====<<

[denismaier]

Update: You might have seen that there's been some work on the title-split feature over at the csl schema repository. I am not sure if that could also help with the problem mentioned here. The essence is:

• Users will not call title-main or title-sub explicitly in styles. Instead there will some attributes that allow for easy configuration of how titles are re-assembled. If there is a need for different formatting of a subtitle there is a new cs:title element as a sibling of cs:text that allows that.

So I imagine there might be a way to output all title variants after the whole title? What do you think?