Tracker wish-list

Here is my own list of tracker favorites, from most- to least-wanted.

Top of the list: things that affect content in the client

  1. #17 – Identifiers
    Adding these identifiers will help styles give orderly treatment
    to these reference details. By setting them as specific variables
    now, we prevent loss of information and abuse of other fields
    in database storage, which makes it a high priority.

  2. #9 – Add coordinator role, for "Director of Publication"
    I like this one because it’s a simple change that eliminates an ambiguity
    that tempts people to abuse other fields for this purpose, and reflects
    what LoC does

  3. #16 – Institution names
    This is a big change, but it greatly simplifies the task of building
    styles that can cope with institutional names. The only way to
    this currently in Zotero is by type-based discrimination, using
    things like the Report type. This extension is backward compatible,
    so existing styles needn’t be changed if it is deployed.

  4. #15 – Move publisher to cs:names
    If cs:institution goes forward, the case for this is strengthened,
    because cs:names can then do things with institution names that
    are not possible with cs:text.

Middle of the list: changes to improve or streamline style authoring and output

  1. #7 – Extend scope of et-al settings to cs:name
    This is a big change, but a complete schema patch is ready,
    it has been implemented in citeproc-js, and the extensive tests
    in citeproc-js have been validated against the schema. The test
    suite says that it has no adverse effects on processing.

  2. #11 – Allow locale element in style with no xml:lang attribute
    This streamlines style authoring. Like #7, a schema patch is
    available, test have been built and validated against the schema,
    the enhanced locales support has been implemented and tested in
    citeproc-js.

The bottom of the list: changes that could be pushed to a future
release without much complaint

  1. #8 – Add range-delimiter option to date-part element
    This is not a critical item for 1.0, but citeproc-js does handle ranged
    dates now, and it seems likely that there will be demand for control
    over the range delimiter once it is deployed.

  2. #5 – Decide how to handle fuzzy dates in CSL
    As noted on the ticket, a conditional for fuzzy dates would save us
    the trouble of figuring out which of the several idiosyncratic schemes
    that styles use to represent them should be implemented in the
    processor. This needn’t be high priority, but the demand for it will
    continue, so it might make sense to include it now.

The basement: changes that address uncommon issues and peripheral tickets

  1. #14 – List last author’s name in truncated authors listing
    This is important for the sciences. It can wait, but the demand for it
    will continue, so it should probably be slated for the next
    release if it doesn’t
    make 1.0.

  2. #4 – Settle input values for fuzzy dates
    As noted on the ticket, this can be dropped; for the present, offering
    "circa" is enough.

  3. #10 – Limiter for cs:name: suppress-min
    This is a corner case, or at least an issue that doesn’t come up
    that often.
    Could be put off to a future release if the 1.0 plate proves too crowded.

  4. #12 – Extend schema to cover locales-xx-XX.xml files
    This might already have been taken care of. In any case, it needn’t
    affect the release of 1.0.

Can I suggest everyone take a look at these and add their comments to
the respective tickets?

http://bitbucket.org/bdarcus/csl-schema/issues/?status=new&status=open

A few random things …

Here is my own list of tracker favorites, from most- to least-wanted.

Top of the list: things that affect content in the client

  1. #17 – Identifiers
    Adding these identifiers will help styles give orderly treatment
    to these reference details. By setting them as specific variables
    now, we prevent loss of information and abuse of other fields
    in database storage, which makes it a high priority.

I’m not so sure about all these. I’m really dubious about the “UN sale
number” for example.

  1. #9 – Add coordinator role, for "Director of Publication"
    I like this one because it’s a simple change that eliminates an ambiguity
    that tempts people to abuse other fields for this purpose, and reflects
    what LoC does

My only issue about this is I’ve never seen this.

  1. #16 – Institution names
    This is a big change, but it greatly simplifies the task of building
    styles that can cope with institutional names. The only way to
    this currently in Zotero is by type-based discrimination, using
    things like the Report type. This extension is backward compatible,
    so existing styles needn’t be changed if it is deployed.

Will take a look.

  1. #15 – Move publisher to cs:names
    If cs:institution goes forward, the case for this is strengthened,
    because cs:names can then do things with institution names that
    are not possible with cs:text.

This is not a small change though. Does this mean we need to also add
"place" to names support, and deprecate “publisher-place”?

That’s all for now; will put any other comments on the tickets.

Bruce

Just to underline this point, some of the proposals on the tickets
require changes to how to client app would store and serve data, as
well as changes to client UIs.

Bruce

  1. #9 – Add coordinator role, for "Director of Publication"
    I like this one because it’s a simple change that eliminates an
    ambiguity
    that tempts people to abuse other fields for this purpose, and
    reflects
    what LoC does

My only issue about this is I’ve never seen this.

Perhaps we should use “editorial-director” instead of “coordinator”? See
also

http://dictionary.reverso.net/french-english/directeur%20de%20la%20publication
http://forum.wordreference.com/showthread.php?t=1537569
http://catalogue.nla.gov.au/Record/1266713/Cite (citation examples)
and for the French-reading among us:
http://fr.wikipedia.org/wiki/Directeur_de_la_publication

Rintze

So I think we’re about ready for 1.0 RC2, after Frank and Rintze and I
pushed some of the more difficult issues to 1.1.

Bruce