Another question, about the name-part elements

I have names importing to a manageable internal structure now. I’m
thinking about output … and (of course!) I have another question.

If I recall correctly, the new approach to names elements will be
something like:

There are maybe four possible “name-part” elements: family name, given
name, articular (like “van”), and suffix (like “Jr.”).
The sequence is fixed by some hinting mechanism that provides the
possibility of overriding the Western order of
names when generating the display form, and the possibility of setting
a literal string for organization names and
the like.

What I’m wondering is whether the name-part elements should be
interpreted not as “insert here” or "insert this"
operators, but as “when setting this part of the name, treat it like
this” formatting hooks. In other words,
even with a bare environment, you
would get names as output, in
whatever the default CSL format for names is.

Is that understanding correct? Or should elements not specifically
included in the environment be omitted
altogether (so that a style that omitted the articular element, say,
would return Werner Braun instead of
Werner von Braun)?

Frank

I have names importing to a manageable internal structure now.

Can we put the tests in place before you go much farther, now that
we’ve narrowed the problem? This another example where we could just
write a test.

I’m thinking about output … and (of course!) I have another question.

If I recall correctly, the new approach to names elements will be
something like:

There are maybe four possible “name-part” elements: family name, given
name, articular (like “van”), and suffix (like “Jr.”).
The sequence is fixed by some hinting mechanism that provides the
possibility of overriding the Western order of
names when generating the display form, and the possibility of setting
a literal string for organization names and
the like.

What I’m wondering is whether the name-part elements should be
interpreted not as “insert here” or “insert this”
operators, but as “when setting this part of the name, treat it like
this” formatting hooks. In other words,
even with a bare environment, you
would get names as output, in
whatever the default CSL format for names is.

I’m not following you on the last sentence.

Is that understanding correct? Or should elements not specifically
included in the environment be omitted
altogether (so that a style that omitted the articular element, say,
would return Werner Braun instead of
Werner von Braun)?

Again; maybe I need coffee, but am not quite understanding what you’re asking.

Bruce

I have names importing to a manageable internal structure now.

Can we put the tests in place before you go much farther, now that
we’ve narrowed the problem? This another example where we could just
write a test.

I’m thinking about output … and (of course!) I have another question.

If I recall correctly, the new approach to names elements will be
something like:

There are maybe four possible “name-part” elements: family name, given
name, articular (like “van”), and suffix (like “Jr.”).
The sequence is fixed by some hinting mechanism that provides the
possibility of overriding the Western order of
names when generating the display form, and the possibility of setting
a literal string for organization names and
the like.

What I’m wondering is whether the name-part elements should be
interpreted not as “insert here” or “insert this”
operators, but as “when setting this part of the name, treat it like
this” formatting hooks. In other words,
even with a bare environment, you
would get names as output, in
whatever the default CSL format for names is.

I’m not following you on the last sentence.

Is that understanding correct? Or should elements not specifically
included in the environment be omitted
altogether (so that a style that omitted the articular element, say,
would return Werner Braun instead of
Werner von Braun)?

Again; maybe I need coffee, but am not quite understanding what you’re asking.

I’ll write a test. :slight_smile: