As far as we know, a lot of styles are probably depending on the
a,b,c,d,e behaviour. I will be able to say for sure with a bit more tooling. It would be pretty easy to create an “A/B tester” to determine if there are significant differences across the style repository from changing this. It would involve:
- A sample library that covers all item types with typical field usage
- A small script to execute, for each style, every cite position and record the HTML output. There’s a useful TestEngine in jest-csl that could be adapted for this purpose; similarly, citeproc-rs can already do this by itself but would need to be able to select position=“ibid”, etc.
- Running it
- Switching a flag in the code and recompiling
- Running it again into a different file
git diff --no-index, our saviour for this kind of thing
If the diff when changing
a,b,c,d,e -> a,bcd,e turns out to be very small, then people weren’t depending on the incorrect behaviour, they were writing explicit groups inside if blocks, which would not require rewriting if you made citeproc-js compliant OR if you changed the spec.
If the diff turns out to be large, then people were depending on a,b,c,d,e, which would not require rewriting if you changed the spec to match it, BUT would require rewriting if you made citeproc-js compliant. My guess is that a significant number of styles are. The strange thing about this is that the only users that would actually be affected by introducing
a,b,c,d,e as the New Way… are people who are not using citeproc-js, and whose different implementation behaves according to the spec. I do not know if any such people or styles or implementations exist.
I can further confirm that pandoc-citeproc if-blocks follow citeproc-js in
a,b,c,d,e, and also in the way macros produce
a,bcd,e. It would appear implementations have been forced to follow citeproc-js, most likely due to a large number of styles depending on its behaviour.
I quite like the term fragment to describe a region of CSL that isn’t a group and may include multiple elements. You could say that an if block producing
bcd is at its core a group without delimiter features, whereas one that produces
b,c,d is a fragment that is included inline in place of the
I have some other ideas about how to make macros more reusable with something akin to the concept of Transclusion aka
<ng-content> in Angular or
children in React. As a quick sketch to discuss some other time, mostly to explain precisely what I mean by a fragment:
<group delimiter=", " prefix="(" suffix=")">
<date variable="issued" />
<CommaSepBraces> <!-- funky new syntax for UpperCamelCased macro names -->
<text value="a" />
<text value="b" />
<!-- inside the macro invocation is a fragment,
included via the <content/> tag above. -->
… would produce
(a, b, 12 Dec 1999).