cs:group

CSL Development
1

Hi Folks,

I’ve run into an issue with cs:group elements and seek some clarification
on the spec.

I have a group which contains a number of elements rendered either directly
from variables for indirectly from macros.

My interpretation of the spec is that ALL of the variables/macros have to
be empty before the group is suppressed, but in the case of a group with
multiple variables/macros, this can produce some strange output.

Here is my specific case…

    <group delimiter="">
      <text term="in" suffix=": " text-case="capitalize-first"/>
      <text macro="container-contributors" prefix=" " suffix=": "/>
      <text macro="container-title" suffix="."/>
      <label variable="page" form="short" text-case="lowercase"

suffix=". " prefix=" – "/>

In this case, both “container-contributors” and “container-title” macros
evaluate empty but the “page” variable is there, so it creates strange
output like this…

“In: – pp. 329–368”

Seems to me in this case, the whole thing should be suppressed.

Am I misinterpreting the spec?

Ron.

2

Without getting too deep, step back a bit and note that the data in
this case is flawed.

The purpose of that group is to describe the characteristics of a
container; likely a book. If the data record doesn’t have a title or
contributor (editor), then you can’t get a correct formatted
reference.

So in short, a bug in the data.

Bruce

3

also, look at the spec again:
a group is suppressed if:
a) at least one rendering element in cs:group calls a variable (either
directly or via a macro), and b) all variables that are called are empty.
This accommodates descriptive cs:text elements.

b) is not the case in your example, as page is a variable and it’s not
empty. So this is exactly what the specs are saying.

Bruce is right, of course, that the data is faulty in your example, but one
of the nice thing about groups is that they help you deal with incomplete
data - in this case probably something like (also cleaning up some of the
remaining code):








</group

4

Hi Bruce & Sebastian

You are correct on both counts, it is a book descriptor, and it is flawed
data.

But I guess my question is that if a cs:group is going to act like a
conditional, shouldn’t ALL the variables/macros be required to evaluate to
TRUE, not just one? Allowing output with ANY variable/macro evaluating to
TRUE can lead to incorrect output as we see here. Or, perhaps there could
be a “match” attribute attached to the group to control this behavior.

In this case I don’t want any output, regardless of the fact that I do have
a “page” variable.

Ron.

5

But I guess my question is that if a cs:group is going to act like a
conditional, shouldn’t ALL the variables/macros be required to evaluate to
TRUE, not just one? Allowing output with ANY variable/macro evaluating to
TRUE can lead to incorrect output as we see here. Or, perhaps there could
be a “match” attribute attached to the group to control this behavior.

no, most definitely not! The most important purpose of groups is that they
deal correctly with missing values. A typical case is e.g. “edition,” which
only exists for some book. We’d often do something like:



Which produces:
Book Title. (when there is no edition)
and
Book Title, 2nd edition. (when there is no edition)
That’s what groups are for - it would obviously be bad if this entire group
disappeared where there is no edition.
The reason you’re getting wrong output in your example is that you’re using
groups wrong. See my example code in the prior e-mail for a better way of
doing this.

I see no reason for changing the current behavior, which works great. It’s
always going to be possible to create faulty output if you write syntax
that doesn’t take into account the specs properly.

Sebastian>

6

OK, fair enough. I just wanted to make sure that my csl processor
(citeproc-php) was doing what it was supposed to. Now I can point the
finger at the CSL author :slight_smile:

Cheers,

Ron.