Tidying up for 1.0

If there aren’t any complaints, I’d like to:

  • rename the “is-numeric” conditional to “numeric” for consistency. The
    "is-date" conditional has been removed from CSL 1.0, and none of the other
    conditional attributes (“type”, “variable”, “uncertain-date”, “position”)
    have “is-” prepended.
  • move the “original-publisher” variable from cs-names to cs-variables, and
    remove “publisher” from cs-names (“publisher” is currently part of both
    cs-names and cs-variables). Hierarchical name support has been pushed to CSL
    1.1 (
    http://bitbucket.org/bdarcus/csl-schema/issue/15/move-publisher-to-cs-names),
    so for CSL 1.0 there won’t be any benefit of using cs:names over
    cs:text
    to display the contents of either variable. Once hierarchical name support
    has been added we can move both variables (back) to cs-names, but that is of
    later concern.

Rintze

If there aren’t any complaints, I’d like to:

  • rename the “is-numeric” conditional to “numeric” for consistency. The
    “is-date” conditional has been removed from CSL 1.0, and none of the other
    conditional attributes (“type”, “variable”, “uncertain-date”, “position”)
    have “is-” prepended.

But you’re comparing apples and oranges; aren’t you? The “is-numeric”
attribute is testing the value of a variable.

  • move the “original-publisher” variable from cs-names to cs-variables, and
    remove “publisher” from cs-names (“publisher” is currently part of both
    cs-names and cs-variables). Hierarchical name support has been pushed to CSL
    1.1 (
    http://bitbucket.org/bdarcus/csl-schema/issue/15/move-publisher-to-cs-names
    ), so for CSL 1.0 there won’t be any benefit of using cs:names over cs:text
    to display the contents of either variable. Once hierarchical name support
    has been added we can move both variables (back) to cs-names, but that is of
    later concern.

Seems reasonable.

Bruce

Doesn’t the same hold for “variable” (you’re testing for a non-empty value)
and (the newly added) “uncertain-date”.

Rintze

Well, the baseline shouldn’t be a new attribute; it’s equally
reasonable to suggest that ought to be changed to “is-uncertain-date.”

For me, the main thing is just that the markup is fairly
self-explanatory. I worry a little that removing the “is” prefix may
negatively impact that (testing for the presence of a variable seems
different to me), but don’t have a really strong opinion on it.

Bruce

Is it okay for me to add a companion “original-publisher-place” variable
when I make this change? I think it would increase the value of having
"original-publisher" around.

Rintze

  • move the “original-publisher” variable from cs-names to cs-variables,
    and
    remove “publisher” from cs-names (“publisher” is currently part of both
    cs-names and cs-variables). Hierarchical name support has been pushed to
    CSL
    1.1 (

http://bitbucket.org/bdarcus/csl-schema/issue/15/move-publisher-to-cs-names
), so for CSL 1.0 there won’t be any benefit of using cs:names over
cs:text
to display the contents of either variable. Once hierarchical name
support
has been added we can move both variables (back) to cs-names, but that
is of
later concern.

Seems reasonable.

Is it okay for me to add a companion “original-publisher-place” variable
when I make this change? I think it would increase the value of having
“original-publisher” around.

I would support this (adding original-publisher-place). It seems good
policy to keep the publisher data aligned.

Yes. OTOH, nobody can support it now.

Bruce

What exactly do you mean with the latter statement? I’m not following.

Rintze

Yeah, I wasn’t very clear. I just mean that none of the CSL
applications currently support a notion of an original publisher.

Bruce

Right. Well, I committed the changes:

Renaming uncertain-date to is-uncertain-date for consistency with is-numeric

Removed “publisher” from cs-names, moved “original-publisher” from cs-names
to cs-variables and added “original-publisher-place” variable to
cs-variables.

Rintze