Affixes to layout within bibliography vs. within citation

We’ve run into an interesting problem on the layout element.

To illustrate, the following are drawn from chicago-author-date.csl:

Citation layout:
Bibliography layout:

The first sets affixes on the full set of multiple rendered items, and
sets a delimiter to join them. The second sets an affix to be applied
to each rendered item.

It would be helpful to both implementers and style authors if this
inconsistency were eliminated. Unfortunately, doing that would
require that a large number of styles be altered (77 of them, to be
exact). The change would involve wrapping the bibliography layout
content in a group in the affected styles, and moving the affixes
(uniformly suffix=".") from the layout to the group element.

I don’t like to propose something this sweeping, but I think it would
be a very helpful bit of housecleaning. The revised styles would run
just fine with both the old and the new CSL processors for Zotero, as
well as with other implementations.

Is it okay to fix this?

(In addition to amending the repository styles, a comment should be
added to the layout element in the spec, describing what it does and
how its affixes and formatting attributes are applied to content.)

Frank

Two things:

We’ve run into an interesting problem on the layout element.

To illustrate, the following are drawn from chicago-author-date.csl:

Citation layout:
Bibliography layout:

The first sets affixes on the full set of multiple rendered items, and
sets a delimiter to join them. The second sets an affix to be applied
to each rendered item.

True.

It would be helpful to both implementers and style authors if this
inconsistency were eliminated.

First, a question: is this currently a practical problem? E.g. how
“helpful” would changing this really be?

Unfortunately, doing that would
require that a large number of styles be altered (77 of them, to be
exact). The change would involve wrapping the bibliography layout
content in a group in the affected styles, and moving the affixes
(uniformly suffix=“.”) from the layout to the group element.

Second, a comment:

I’m not sure this solution would clarify things that much, and would
close off other options.

Essentially what we have is that both citations and bibliographies are
lists of items. So to be clear, that seems to suggest:

layout
list
item

That allows other things to get added to cs:list potentially.

But that’s definitely a change.

In any case, I come back to the bigger question: what’s the practical
case that says we need this change?

Bruce

Sorry for the empty message that just went out. Here’s a real response.

Two things:

We’ve run into an interesting problem on the layout element.

To illustrate, the following are drawn from chicago-author-date.csl:

Citation layout:
Bibliography layout:

The first sets affixes on the full set of multiple rendered items, and
sets a delimiter to join them. The second sets an affix to be applied
to each rendered item.

True.

It would be helpful to both implementers and style authors if this
inconsistency were eliminated.

First, a question: is this currently a practical problem? E.g. how
“helpful” would changing this really be?

There’s no immediate use case that requires it, so in that sense
nothing would be harmed by leaving things as they stand. Doing
nothing would – very slightly – complicate citeproc-js (because
layout will need to be context sensitive), but doing nothing would
also save the need to remangle all those style files.

As for “helpful”-ness, it would just lighten burdens around the board.
Straightening this out would make CSL syntax more intuitive, by
eliminating an inconsistency for which there doesn’t seem to be a
clear need. It would simplify processor implementations (including
citeproc-py). It would also simplify things for a style GUI, because
“layout” would have the same meaning everywhere. Clean design makes
for simpler code and all that.

Unfortunately, doing that would
require that a large number of styles be altered (77 of them, to be
exact). The change would involve wrapping the bibliography layout
content in a group in the affected styles, and moving the affixes
(uniformly suffix=“.”) from the layout to the group element.

Second, a comment:

I’m not sure this solution would clarify things that much, and would
close off other options.

What options are those? All I can see is a mild extension to functionality.

It’s not currently possible to tack affixes onto a bibliography (in
the header and footer positions), and you can’t specify delimiters (or
rather, you can specify them, but they will mysteriously have no
effect). Can’t think of a reason why that would be needed, so it’s
not really an issue; but it’s not possible now because of the way
layout in bibliography works. If bibliography-layout worked like
citation-layout, it would be.

Nothing else changes, really.

Essentially what we have is that both citations and bibliographies are
lists of items. So to be clear, that seems to suggest:

layout
list
item

That allows other things to get added to cs:list potentially.

But that’s definitely a change.

In any case, I come back to the bigger question: what’s the practical
case that says we need this change?

Things could be left as they are for the present, although it’s not very pretty.

But at the very least, the spec should say something about it. I had
completely missed out affixes on bibliography layouts until Simon
pointed out they were not turning up in output. If I had gone to the
spec instead of checking the style archive, I would have ended up
implementing them wrongly, and those 77 styles would have broken.

As I say, I know that a sweeping repository-wide edit like this is not
something to be undertaken lightly. But it wouldn’t be painful to
deploy, and it would save extra programming burden for all projects
that handle CSL style code. Looking to the future, I think it’s worth
doing early, before further work on the style GUI is done. But it’s
your call.

As for “helpful”-ness, it would just lighten burdens around the board.
Straightening this out would make CSL syntax more intuitive, by
eliminating an inconsistency for which there doesn’t seem to be a
clear need. It would simplify processor implementations (including
citeproc-py). It would also simplify things for a style GUI, because
“layout” would have the same meaning everywhere. Clean design makes
for simpler code and all that.

Yes, I see all that.

Unfortunately, doing that would
require that a large number of styles be altered (77 of them, to be
exact). The change would involve wrapping the bibliography layout
content in a group in the affected styles, and moving the affixes
(uniformly suffix=“.”) from the layout to the group element.

Second, a comment:

I’m not sure this solution would clarify things that much, and would
close off other options.

What options are those? All I can see is a mild extension to functionality.

am not sure, but, for exampe …

Consider what earlier versions of the schema had, where you could
specify headings for the bib, subsections, etc.

E.g. just saying if we’re going to be explicit about lists vs. items,
let’s be explicit.

As I say, I know that a sweeping repository-wide edit like this is not something to be undertaken lightly.

Well, I’ll write an XSLT to do the conversion from 0.8 to 1.0. If
that’s hard to do, then it might be a hint that the solution is
less-than-ideal.

The bigger issue is managing deployment. I would think every style
would need to be duplicated, with new ids.
.
Bruce

As for “helpful”-ness, it would just lighten burdens around the board.
Straightening this out would make CSL syntax more intuitive, by
eliminating an inconsistency for which there doesn’t seem to be a
clear need. It would simplify processor implementations (including
citeproc-py). It would also simplify things for a style GUI, because
“layout” would have the same meaning everywhere. Clean design makes
for simpler code and all that.

Yes, I see all that.

Unfortunately, doing that would
require that a large number of styles be altered (77 of them, to be
exact). The change would involve wrapping the bibliography layout
content in a group in the affected styles, and moving the affixes
(uniformly suffix=“.”) from the layout to the group element.

Second, a comment:

I’m not sure this solution would clarify things that much, and would
close off other options.

What options are those? All I can see is a mild extension to functionality.

am not sure, but, for exampe …

Consider what earlier versions of the schema had, where you could
specify headings for the bib, subsections, etc.

E.g. just saying if we’re going to be explicit about lists vs. items,
let’s be explicit.

As I say, I know that a sweeping repository-wide edit like this is not something to be undertaken lightly.

Well, I’ll write an XSLT to do the conversion from 0.8 to 1.0. If
that’s hard to do, then it might be a hint that the solution is
less-than-ideal.

The bigger issue is managing deployment. I would think every style
would need to be duplicated, with new ids.

This particular change would be backward compatible. The revised
style would be a drop-in replacement for the old one.

The bigger issue is managing deployment. I would think every style
would need to be duplicated, with new ids.

This particular change would be backward compatible. The revised
style would be a drop-in replacement for the old one.

But regardless, there will almost-certainly be backwards-incompatible
changes with 1.0. So implementations will need a plan to deal with
this.

Bruce