I noticed the following in APA:
In Papers2, the publisher/title get output without any space between them. Now, I am not sure what the processor is supposed to do:
Thanks for your help!
Charles–
Charles Parnot
@Charles_Parnot
twitter: @cparnot
My vote is for this one. I would not expect the style to include a
space between the two variables, and this is most probably incorrect
for APA.
Rintze
I’m confused - aren’t these in cs:substitute?
When I wrote this, my expectation when I wrote this was that this would
first go to publisher and if there is no publisher to title, but never
print both. Did I misunderstand the specs there?
update: Citeproc-js/Zotero does exactly what I describe and I wouldn’t know
any other way to get differing substitute behaviors for different item
types.
Ah, I see. The issue is that I take into account the 3 root elements as the possible substitutes, and the third one is the <choose> element. It’s similar to having e.g. a <group> element. In theory, we could set the rule that only a <group> element can be used to group element together, and otherwise each individual element should be considered a separate option. But it makes the implementation less natural. I also think it makes the reading of the CSL confusing, as in all the other CSL files, 2 sibling elements mean the 2 elements are next to each other. The <substitute> element is the only place where that’s not true, and transfering that property to descendants of the XML tree can be confusing.
In other words, I think the following is less ambiguous, and is consistent with patterns used in the rest of the CSL files (though more verbose, of course):
Now, I am open to discussion, and in particular, ready to follow the rules already implemented by the other processors if that’s the way it’s been done.
The same pattern is used in many of the styles (derived from APA), and I am ready to change them all myself, of course 
Charles
update: Citeproc-js/Zotero does exactly what I describe and I wouldn’t know any other way to get differing substitute behaviors for different item types.
Ah, there, I have my answer…
There is a way to achieve the same result with a choose element, though, as I wrote in my email.
Now, I wonder what is the behavior of the processor with a <group> element? I am just asking because I want to make sure there is a way to do the opposite: have 2 variables chained together and output as a substitute.
charles
Sorry for the noise; Sebastian is right.
You could handle your case by creating a macro and calling that from
within cs:substitute.
Rintze
Now, I wonder what is the behavior of the processor with a
<group>
element? I am just asking because I want to make sure there is a way to do
the opposite: have 2 variables chained together and output as a substitute.
citeproc-js/Zotero does treat a group as a single element, i.e. it renders
all elements in the group placed in cs:substitute. So this would work even
without the macro that Rintze suggests, though that’s more elegant in many
cases.
I don’t have a strong opinion on this, but I do prefer the way this is
currently handled by citeproc. To me, it’s intuitive and I find the code
easier to read and less messy: With more substitute elements than for APA,
using Charles’ method there would be a need for endless if - else-if - else
chains and if different names elements are required for different item
types that would require re-specifying all and properties.>
I read this exchange with a growing sense of relief. My initial
reaction was to assume the existing citeproc-js behaviour was a bug,
and to reach for the source code. The story rapidly grew more
complicated as I tried to dig into the problem – and I was delighted
to find a reminder of what I should have remembered – that the
current behaviour actually does make sense.
Frank
I still think it’s conceptually more logical that each child is considered a substitute (and by the way, the <substitute> element would be a great alternative to in some cases, if extended to the rest of CSL). However, I must bow to the reference implementation, and I suggest maybe the written specification should be more explicit, 
Now, I do have a problem is that this will requires quite a lot of work to make my processor work with this rule, but so be it…
(Let me explain why. In the way the XML tree is treated, all elements are handled as much as possible independently of the context in which they are. For instance, the <substitute> element will ask its children, in turn, to evaluate themselves, until it finds one child that has a non-empty value; and when the <choose> element is evaluated, it’s evaluated just like any other <choose> element, and does not apply any special rule to take into account the fact that it’s within a <substitute>. This is what I meant by being more logical in terms of the XML tree, even if I totally understand it makes things easier to write, and I also agree that syntax brevity is a feature that often trump implementation complexity).
charles
I forgot to ask you, Frank, as well: could you confirm that <group> will behave as one block and will not return just the first non-empty field within it?
If true (fingers crossed!!), I also want to plead to maintain <group> as an exception to the ‘first descendant’ rule, because I will rely on that property to get the implementation right.
Thanks!
Charles
I forgot to ask you, Frank, as well: could you confirm that
<group>will behave as one block and will not return just the first non-empty field within it?If true (fingers crossed!!), I also want to plead to maintain
<group>as an exception to the ‘first descendant’ rule, because I will rely on that property to get the implementation right.Thanks!
Charles
Group does work as a unit currently.
If true (fingers crossed!!), I also want to plead to maintain
<group>
as an exception to the ‘first descendant’ rule, because I will rely on that
property to get the implementation right.Thanks!
Charles
Group does work as a unit currently.
I strongly support keeping it that way, even more so if Charles also
prefers that.> >
All: feel free to create an issue in the “schema” repo and propose a
modified description of the spec. I’d volunteer to do this myself but
I think some of you have a better grasp of how the spec could be
clarified.
Rintze
I have opened the issue here:
Just to be clear, it seems it then makes sense that further <choose> elements down the hierarchy are treated similarly, and that <group> elements within <choose> elements are treated as a unit as well (but <choose> elements within <group> elements will be evaluated normally and won’t follow the special <substitute> rule, since they are part of the group).
Does that make sense? Maybe best to comment on the issue directly at this point.
Charles