Upgrade StorageBluebook desiderata
I have finished an initial cut of book types in the Bluebook style, which is available here. While putting it together, I ended up extending the is-numeric test to cover several additional fields, and tweaking the contributor field so that it could be tested for the presence of data. There are some remaining issues, listed at the link above. Here is the lot, with some presumptuous ruminations about each:
Issues affecting style functionality
Incorrect form for ordinals
3rd should be 3d (p. 107).
This is the uniform convention for the Bluebook style, so we need a way to accomodate it. The locales machinery can be used to bind this in the style, but it's a little trickey to do. The ordinal suffixes ("st", "nd", "rd", "th" in English) are already set as a localized property string, that varies depending on the locale under which Firefox is invoked. That means using the default suffix itself as a key for style-specific "localization" is out.
I've worked out a hack that might be a starting point for addressing this one. My (now invalid) BB style file contains localization entries for "ordinal-00" through "ordinal-03", and I've reworked the way that day suffixes are set in cite.js, so that these will override the values provided by the (pre-localized) property if they exist. This should not interfere with other styles, but permits Bluebook to have its own way for these strings. The hack is included in the version 0.2 upload, available from the site linked above. (Turns out I'm not alone; here's another comment from a user with a need to configure ordinals.)
Unrecognized types
"Dictionary entry" and "Encyclopedia article" not recognized as types.
The Bluebook applies a special format to a few resources that are either frequently cited, or widely known (see BB rule 15.7). Handling this special format within the book type would be hard, because the BB csl code for books is already pretty complete.
An easier solution, from both the coding and the explain-to-users perspective, is to apply a special type to these entries. The "entry-dictionary" type in CSL would be ideal for this, but Zotero currently sees this as identical to "book". There has been discussion of this, and further work on the types mechanism is slated for Zotero 2.0, so this issue will be resolved in time. In the meantime, I have added a patch to the cite.js file of the zotero instance I use for testing.
Cannot set typeface for case names, etc.
Not presently any means of setting alternative typefaces for content within a field.
There has been a discussion of this already. Since the typeface for a case name is not fixed (i.e. in a default-roman field it should be italic, and in a default-italic field it should be roman), Dan's idea of setting styles on the fields and applying them in the plugin sounds like the right solution, when development reaches that point.
Cannot specify place of publication for newspapers
No publisher-place field in Newspaper Article type.
This one is kind of important. For newspapers that can't be distinguished by title, the BB requires that their place of publication be given in parens, in a different typeface, following the name of the paper (i.e. scaps_on Times scaps_off (London)). This information is meaningful in its own right, and the field already exists for the book types. Would it be possible to wake it up?
Issues covered by messy workarounds
Multiple date fields not available
No field for supplement date. (p. 111, Schweitzer, p. 112, Williston)
Legal materials frequently have supplements, which are updated more frequently than the main volume. Supplements include amendments to the the original content (much as a patch file, or a statement of errata). Proper citation therefore requires that both the original source and the supplement relied upon be identified. Supplements are identified by date, which raises the need to associate at least one additional date with a citation, with an indication that it applies to a supplement.
In the initial cut of CSL for the book type, I have worked around this by reading the additional string required from the Extra field. This works for now; but a better way to handle it might be to provide date categories in the GUI, similar to the Creator categories offered in the current interface.
This would allow for more graceful handling of this problem, plus some of the issues discussed here. An extended date facility might also be used to handle the original date of republished works, but solving this one through a field in the republishing work's entry has been considered and rejected.
This is not the only abuse of the Extra field in the experimental Bluebook style; the more of them can be replaced with neater solutions, the more friendly and reliable the style will be to use. But that said, this one is a judgement call.
Author of essay in collection cannot be set together with institutional author of collection
No field for container author
There are examples in the Bluebook that require this. The "container-author" in this case is distinct from a publisher or editor, with different presentation characteristics. See examples under Rules 15.5.1 and 15.6. I currently work around this by setting the author as "contributor" and the institutional author as "author", but this is not really satisfactory.
Minor issues
No option to force all authors to be shown
CSL sets names formatting in the header of the `citation` element.
The Bluebook requires that one author be shown followed by "et al.", when there are three or more names to be formatted. But when this would conceal authors whose names are significant in the context, all names are to be shown. It is apparently not possible to modify the formatting of names on the fly in CSL, so this use case cannot currently be accomodated. While uncommon, this will be a mild headache to editors when it arises, because the missing names will need to be retrieved from sources external to the document to rectify the citation.
The required adjustment (forcing the display of a full list of names for a single citation) is completely ad hoc, so it's really something for the Word/OO plugin GUI rather than CSL [edited following mark's comment]. An expand-names companion to the GUI option for suppressing the author name would be helpful; but this is not a high priority item.
Limitation in label mechanism
Cannot produce suffix "ed. & trans." where editor and translator are identical
Handling this automatically would add complexity, but it may be an issue shared by other styles; stating the name once, with the role labels joined seems the elegant way to represent it. Would be nice to have this as an option, although it is not a high priority.
Issues affecting style functionality
Incorrect form for ordinals
3rd should be 3d (p. 107).
This is the uniform convention for the Bluebook style, so we need a way to accomodate it. The locales machinery can be used to bind this in the style, but it's a little trickey to do. The ordinal suffixes ("st", "nd", "rd", "th" in English) are already set as a localized property string, that varies depending on the locale under which Firefox is invoked. That means using the default suffix itself as a key for style-specific "localization" is out.
I've worked out a hack that might be a starting point for addressing this one. My (now invalid) BB style file contains localization entries for "ordinal-00" through "ordinal-03", and I've reworked the way that day suffixes are set in cite.js, so that these will override the values provided by the (pre-localized) property if they exist. This should not interfere with other styles, but permits Bluebook to have its own way for these strings. The hack is included in the version 0.2 upload, available from the site linked above. (Turns out I'm not alone; here's another comment from a user with a need to configure ordinals.)
Unrecognized types
"Dictionary entry" and "Encyclopedia article" not recognized as types.
The Bluebook applies a special format to a few resources that are either frequently cited, or widely known (see BB rule 15.7). Handling this special format within the book type would be hard, because the BB csl code for books is already pretty complete.
An easier solution, from both the coding and the explain-to-users perspective, is to apply a special type to these entries. The "entry-dictionary" type in CSL would be ideal for this, but Zotero currently sees this as identical to "book". There has been discussion of this, and further work on the types mechanism is slated for Zotero 2.0, so this issue will be resolved in time. In the meantime, I have added a patch to the cite.js file of the zotero instance I use for testing.
Cannot set typeface for case names, etc.
Not presently any means of setting alternative typefaces for content within a field.
There has been a discussion of this already. Since the typeface for a case name is not fixed (i.e. in a default-roman field it should be italic, and in a default-italic field it should be roman), Dan's idea of setting styles on the fields and applying them in the plugin sounds like the right solution, when development reaches that point.
Cannot specify place of publication for newspapers
No publisher-place field in Newspaper Article type.
This one is kind of important. For newspapers that can't be distinguished by title, the BB requires that their place of publication be given in parens, in a different typeface, following the name of the paper (i.e. scaps_on Times scaps_off (London)). This information is meaningful in its own right, and the field already exists for the book types. Would it be possible to wake it up?
Issues covered by messy workarounds
Multiple date fields not available
No field for supplement date. (p. 111, Schweitzer, p. 112, Williston)
Legal materials frequently have supplements, which are updated more frequently than the main volume. Supplements include amendments to the the original content (much as a patch file, or a statement of errata). Proper citation therefore requires that both the original source and the supplement relied upon be identified. Supplements are identified by date, which raises the need to associate at least one additional date with a citation, with an indication that it applies to a supplement.
In the initial cut of CSL for the book type, I have worked around this by reading the additional string required from the Extra field. This works for now; but a better way to handle it might be to provide date categories in the GUI, similar to the Creator categories offered in the current interface.
This would allow for more graceful handling of this problem, plus some of the issues discussed here. An extended date facility might also be used to handle the original date of republished works, but solving this one through a field in the republishing work's entry has been considered and rejected.
This is not the only abuse of the Extra field in the experimental Bluebook style; the more of them can be replaced with neater solutions, the more friendly and reliable the style will be to use. But that said, this one is a judgement call.
Author of essay in collection cannot be set together with institutional author of collection
No field for container author
There are examples in the Bluebook that require this. The "container-author" in this case is distinct from a publisher or editor, with different presentation characteristics. See examples under Rules 15.5.1 and 15.6. I currently work around this by setting the author as "contributor" and the institutional author as "author", but this is not really satisfactory.
Minor issues
No option to force all authors to be shown
CSL sets names formatting in the header of the `citation` element.
The Bluebook requires that one author be shown followed by "et al.", when there are three or more names to be formatted. But when this would conceal authors whose names are significant in the context, all names are to be shown. It is apparently not possible to modify the formatting of names on the fly in CSL, so this use case cannot currently be accomodated. While uncommon, this will be a mild headache to editors when it arises, because the missing names will need to be retrieved from sources external to the document to rectify the citation.
The required adjustment (forcing the display of a full list of names for a single citation) is completely ad hoc, so it's really something for the Word/OO plugin GUI rather than CSL [edited following mark's comment]. An expand-names companion to the GUI option for suppressing the author name would be helpful; but this is not a high priority item.
Limitation in label mechanism
Cannot produce suffix "ed. & trans." where editor and translator are identical
Handling this automatically would add complexity, but it may be an issue shared by other styles; stating the name once, with the role labels joined seems the elegant way to represent it. Would be nice to have this as an option, although it is not a high priority.
Initially I am concentrating on setting up full citation output for secondary resources (books, articles, manuscripts, electronic resources). The next step will be to get back-references working. I plan to hold off dealing with primary material (cases and legislative materials) until the secondary stuff is more or less done. Citatiions to primary sources frequently need to be given in parallel, or as a related series of cites reflecting prior or subsequent procedural history, or statutory revision. These thorny problems depend on relational links between resources. This is part of the plan for xbibio and zotero, so these items will be a bridge to cross when it's built.
To get ready for that eventual work, I'll list up here some of the issues that look like they might cause problems, as I come across them.
Require special condition for short title
Cannot limit the scope within which previous references to the same resource are recognized.
Rule 12.9(c) for statutes requires the use of the short form if the full-form citation "can be readily found in one of the preceding five footnotes". This would require that the position="ibid" condition be capable of resetting to false on some condition, on a per-type basis.