I’ve opened a bookmark in the citeproc-js repo for modular legal style
support. This is an initial note on the design I’m contemplating for
This is a very long post, which I’ll be using as a working note while
building out the support in the processor. Comments are welcome - but
I know that everyone is very busy.*****
Legal citation formats vary across jurisdictions. Unification is not
an option for a couple of reasons:
(1) Primary legal materials have a (pretty much) well defined internal
structure that is specific to each jurisdiction, and citation forms
reflect that local structure.
(2) Legal institutions have large stakeholder populations, so local
changes to referencing patterns are expensive to implement.
CSL currently expresses citation styles in a single file. Coding
separate jurisdiction-specific citation formats into a single file is
possible, but there are obvious issues with scalability and
maintainability. On the user side, there is also a problem of
full-line supply - where there are variants of a national
jurisdiction’s citation forms, finding a style with the particular
combination of formats needed for a project becomes the more
The proposed solution is to express jurisdiction-specific citation
forms for primary legal materials (only) in separate modules that can
be loaded on demand by a CSL processor.
If successful, modular legal style support would enable tech-savvy
legal professionals in individual jurisdictions to focus on developing
CSL code that expresses their specific requirements. This would bring
more expertise to the design process, and lighten the maintenance
burden on core CSL maintainers.
The added complexity of modular style support touches processor
development, style designers, and users. Minimizing the impact on all
three is a concern.
Essential features of the proposed design are:
(1) Legal citations are expressed using a fixed set of macro names,
each of which composes one element of a complete citation (the macro
names below are tentative):
(2) A legal style module is composed as standard CSL(-m) style using
only the above-named macros.
(3) The jurisdiction and variant of a legal style module is expressed
in the filename under which it is distributed:
In the examples above, the “juris-” prefix identifies the file as a
legal style module. The prefix is reserved for this purpose within the
CSL ecosystem. In the first example, “us:ak” indicates the
jurisdiction of Alaska within the United States. In the second,
“arb.cls” indicates a private arbitration. These identifiers are drawn
from the Legal Resource Registry, which is (apparently) the only set
of jurisdiction identifiers with worldwide scope that is open to
The “bluebook” and “oscola” name elements allow multiple modules to be
distributed for a single jurisdiction.
(4) In a first-class CSL style file that offers extensible legal style, support:
(a) An attirbute on cs:style optionally declares preferred legal style
<options juris-style-prefs="babyblue,oscola" />
This is parsed to a list:
citeproc.opt.juris_style_prefs = ["babyblue", "oscola"];
(b) Primary legal materials (items with a “jurisdiction” value, which
are of item type “bill,” “legislation,” “legal_case,” “report,” or, in
CSL-m, “gazette,” “regulation,” or “hearing”) are rendered by
combining “juris-” macros exclusively, using the normal CSL semantics,
with certain fixed assumptions about joining punctuation:
This example shows that (i) the first-class style controls the join
between “juris-name” and “juris-tail” and the core of the citation;
(ii) the join between “juris-main” and “juris-pinpoint” is controlled
by the latter macro (the CSL-m validation constraint on leading space
in a prefix attribute is relaxed for this purpose).
(5) When the processor encounters a “juris-” prefixed macro while
processing an item with a “jurisdiction” value, it attempts to
retrieve a corresponding style module. Resolution is attempted using
the following data elements to cast filename candidates:
prefix = “juris”;
jurisdiction = Item.jurisdiction.split(":");
variant = citeproc.opt.juris_style_prefs[i];
Matching is attempted by joining the split elements of jurisdiction to
a string identifier, then attempting to find a file match for each
variant in turn beginning with index 0, then trying the filename with
no variant, and finally attempting to find a filename with any
If a match is not found, one element is removed from the end of the
jurisdiction split, and the match against variants is attempted again.
If a match is found, the style module is instantiated, and the
"juris-" macro code embedded in the style is bypassed.
If jurisdiction elements are exhausted without a match, module
instantiation is aborted, and the embedded macro code is used.
(To avoid unnecessary overhead, a processor should attempt to match a
jurisdiction module only once during a session, caching the result as
success or failure.)
The design described above has the following advantages:
Jurisdiction modules are valid CSL(-m) styles, and can be tested for
accuracy and regressions with existing tools.
First-class styles can function without installing style modules.
The requirements for adding full legal support to existing styles are modest.
Implementation in processors is relatively simple, requiring only
implementation of the style preference node, and a means of
instantiating individual macros as standard executable style code
Note that this assumes the use of standard identifiers in input data.
The most significant burden for legal style support will fall on
calling applications, which must implement user interface and
underlying code to assure that correct jurisdiction identifiers are
sent to the processor for each item.