Clarification q on decor for names

I’m reworking the citeproc-js output queue, to eliminate a bunch of ad
hoc stuff that was getting hopelessly complicated. To simplify
things, I’m doing what I should have done in the first place, writing
the output as a nested list that reflects the structure of the CSL.
For names, I’m just slightly uncertain about what the scope of the
elements is for the purpose of applying prefixes and suffixes, so I’d
like to confirm some things. Here is how I think things work. Please
correct if any of this is wrong.

(1) For the name-part element, affixes apply to the name-part only,
and delimiter has no effect. Spacing within Western names is
implicit:

== John [Doe]Jane [Roe]

(2) For the name element, affixes apply to the nameset (variable), and
delimiter is used to join fully composed names within the set. There
is no implicit spacing for labels, and labels are not within the scope
of the affixes:

== [John Doe,Jane Roe][Tom Smith,Robert Jones]eds

(3) For the names element, affixes apply to the full set of variables,
and delimiter is used to join fully composed namesets:

== [John DoeJaneRoe,Tom SmithRobertJones(eds)]

(4) There is no means of applying affixes to individual names –
that’s not a criticism, I can’t see any reason for doing so. I just
want to confirm that I’m understanding the meaning of the parameters
correctly before recasting the code.

Frank

This is something I’ve not thought about in awhile, and it’s a moving
target, but in the interest of moving forward …

I’m reworking the citeproc-js output queue, to eliminate a bunch of ad
hoc stuff that was getting hopelessly complicated. To simplify
things, I’m doing what I should have done in the first place, writing
the output as a nested list that reflects the structure of the CSL.
For names, I’m just slightly uncertain about what the scope of the
elements is for the purpose of applying prefixes and suffixes, so I’d
like to confirm some things. Here is how I think things work. Please
correct if any of this is wrong.

(1) For the name-part element, affixes apply to the name-part only,
and delimiter has no effect. Spacing within Western names is
implicit:

== John [Doe]Jane [Roe]

I wonder if we should disallow them on cs:name-part, given the tricky
issue on how commas are handled in Western names, vs. others?

(2) For the name element, affixes apply to the nameset (variable), and
delimiter is used to join fully composed names within the set. There
is no implicit spacing for labels, and labels are not within the scope
of the affixes:

== [John Doe,Jane Roe][Tom Smith,Robert Jones]eds

Ugh; am not sure, but that seems (?) to match this comment in the schema:

Delimiter between names (delimiter between variables is on

tag, where it should be). This is ", " in “J. Doe, S. Smith.”

I wonder if part of the issue here is that the semantics of cs:names
vs. cs:name isn’t as clear as it could be?

(3) For the names element, affixes apply to the full set of variables,
and delimiter is used to join fully composed namesets:

== [John DoeJaneRoe,Tom SmithRobertJones(eds)]

That would seem to make sense.

(4) There is no means of applying affixes to individual names –
that’s not a criticism, I can’t see any reason for doing so. I just
want to confirm that I’m understanding the meaning of the parameters
correctly before recasting the code.

Bruce

This is something I’ve not thought about in awhile, and it’s a moving
target, but in the interest of moving forward …

I’m reworking the citeproc-js output queue, to eliminate a bunch of ad
hoc stuff that was getting hopelessly complicated. To simplify
things, I’m doing what I should have done in the first place, writing
the output as a nested list that reflects the structure of the CSL.
For names, I’m just slightly uncertain about what the scope of the
elements is for the purpose of applying prefixes and suffixes, so I’d
like to confirm some things. Here is how I think things work. Please
correct if any of this is wrong.

(1) For the name-part element, affixes apply to the name-part only,
and delimiter has no effect. Spacing within Western names is
implicit:

== John [Doe]Jane [Roe]

I wonder if we should disallow them on cs:name-part, given the tricky
issue on how commas are handled in Western names, vs. others?

Could do, might not hurt to allow them just in case someone finds a
use for them. (Partly these questions are about getting a handle on the
scope of other the decoration attributes (@font-style etc), which would
stay either way.)

(2) For the name element, affixes apply to the nameset (variable), and
delimiter is used to join fully composed names within the set. There
is no implicit spacing for labels, and labels are not within the scope
of the affixes:

== [John Doe,Jane Roe][Tom Smith,Robert Jones]eds

Ugh; am not sure, but that seems (?) to match this comment in the schema:

Delimiter between names (delimiter between variables is on

tag, where it should be). This is ", " in “J. Doe, S. Smith.”

I wonder if part of the issue here is that the semantics of cs:names
vs. cs:name isn’t as clear as it could be?

It does accord with the schema note, it’s comforting that I seem to
have gotten this right.

(3) For the names element, affixes apply to the full set of variables,
and delimiter is used to join fully composed namesets:

== [John DoeJaneRoe,Tom SmithRobertJones(eds)]

That would seem to make sense.

Good, that’s done.

(4) There is no means of applying affixes to individual names –
that’s not a criticism, I can’t see any reason for doing so. I just
want to confirm that I’m understanding the meaning of the parameters
correctly before recasting the code.

I sounds like I’ve got a workable structure for this, then. The refactoring
work I’ve run into will take a couple of weeks (teaching term has started,
so there’s less time to steal), but the program should be easier to
understand and to debug when it’s done.

Cheers,
Frank

(1) For the name-part element, affixes apply to the name-part only,
and delimiter has no effect. Spacing within Western names is
implicit:

== John [Doe]Jane [Roe]

I wonder if we should disallow them on cs:name-part, given the tricky
issue on how commas are handled in Western names, vs. others?

Could do, might not hurt to allow them just in case someone finds a
use for them.

Right, but then how would you process them, and what happens if you
have people regularly adding a ", " prefix because they assume Western
names?

(Partly these questions are about getting a handle on the
scope of other the decoration attributes (@font-style etc), which would
stay either way.)

Yes, I’m wondering about splitting pre/suffixes from the other
formatting attributes in the schema. The current monolithic patterns
means the pre/suffixes appear where there wasn’t necessarily a
conscious choice to put them there.

Bruce

(1) For the name-part element, affixes apply to the name-part only,
and delimiter has no effect. Spacing within Western names is
implicit:

== John [Doe]Jane [Roe]

I wonder if we should disallow them on cs:name-part, given the tricky
issue on how commas are handled in Western names, vs. others?

Could do, might not hurt to allow them just in case someone finds a
use for them.

Right, but then how would you process them, and what happens if you
have people regularly adding a ", " prefix because they assume Western
names?

No strong views here. Punctuation affixes in that position would not
render correctly in that position (you’d get something like “John ,
Doe”). Someone might have occasion to use braces I guess. But no
objection if you would prefer to block them in the schema.

(Partly these questions are about getting a handle on the
scope of other the decoration attributes (@font-style etc), which would
stay either way.)

Yes, I’m wondering about splitting pre/suffixes from the other
formatting attributes in the schema. The current monolithic patterns
means the pre/suffixes appear where there wasn’t necessarily a
conscious choice to put them there.

The choice would be your call, I think, as the one herding the cats. :slight_smile: