xbiblio-devel Digest, Vol 118, Issue 1

CSL Development
1

Hi Rintze,

Thank you for your good summary of my proposal, and I am sorry for not using the mailing list properly. This is my first time working on a mailing list. :slight_smile:

  1. Is it ever necessary to be able to cite a subset of the reports?

Not every journal requires parallel citations - a citation to the primary reporter may be all that it required. However, within a single document, the citation convention must be consistent. If the first citation contains parallel references, then every subsequent citation must also contain the parallel references.

  1. Is it ever necessary to control the order of the reports?

Publications should be listed according to their relative weight of authority. Within a single document, the ordering of the publications must be consistent. I think that ordering of elements in the containers array

  1. Concerning Hierarchical Item types

I don’t have a good handle on the nuances of hierarchical item types. However, I had given the subject some thought when formulating my proposal. These are my initial thoughts.

My current proposal only allows elements to hold simple fields - it does not allow name fields, date fields, or nested . This limitation makes it much simpler to implement - not only for the CSL processor, but also for user interfaces. But, perhaps it strikes the wrong compromise between simplicity and functionality?
In order to accommodate hierarchical items types, the element would have to at least accommodate name fields. The initial in the array could represent the smallest level of container, and each subsequent element represents the next larger container. For an example of an article cited within a textbook:

<title>The Nature and Value of Rights</title>     <!-- title of the work -->

<issued>2006</issued>

<authors>

    <author>

        <family>Feinberg</family>     <!-- author of excerpt -->

    </author>

</authors>

<containers>

    <container>

        <container-title>Chapter 7: the Nature and Significance of Rights</container-title>     <!-- title of the subcontainer -->

    </container>

    <container>

        <container-title>Jurisprudence: Introduction to the Philosophy of Law</container-title>     <!-- title of book or database -->

        <authors>

            <author>

                 <family>Gottlieb</family>     <!-- author of text book -->

            </author>

        </authors>

    </container>

</containers>

To preserve the compatibility between styles to render the same bibliographic information, the CSL specification would have to include sub-rules about which fields should or should not be included in elements. For instance, does the element become a child element of or should it be a child element of a element?

(I personally think that and elements should always occur under ).

Send xbiblio-devel mailing list submissions to
xbiblio-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
xbiblio-devel List Signup and Options
xbiblio-devel Info Page - SourceForgehttps://lists.sourceforge.net/lists/listinfo/xbiblio-devel
lists.sourceforge.net
This list is for development discussion around the xbiblio project, including schema design for the citation style language (CSL) and implementation discussion.

or, via email, send a message with subject or body ‘help’ to
xbiblio-devel-request@lists.sourceforge.net

You can reach the person managing the list at
xbiblio-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than “Re: Contents of xbiblio-devel digest…”

Today’s Topics:

  1. Re: Proposed change to CSL input XML (Rintze Zelle)
  2. Job posting: Citation Specialist / CSL Expert (Darshan Somashekar)

Message: 1
Date: Thu, 5 Jan 2017 00:52:13 -0500
From: Rintze Zelle <rintze.zelle@…25…>
Subject: Re: [xbiblio-devel] Proposed change to CSL input XML
To: development discussion for xbiblio
xbiblio-devel@lists.sourceforge.net
Message-ID:
<CA+pmmQR=ygg_Th=oZCpvw60Sp23k+Anh7AW8f_9X1ogwJS84iw@…26…>
Content-Type: text/plain; charset=“utf-8”

Hi Tom,

So, to briefly condense your posts on this topic (for myself and others):
Juris-M (formerly Multilingual Zotero, MLZ) extends the official CSL
specification in a number of ways to improve support for legal citations.
One of these extensions is the support for parallel citations, where a
single document is published redundantly in multiple outlets. Juris-M
assumes that each so-called report is stored as a separate item, and
automatically collapses reports to the same document if they are cited
directly next to each other. See pages 6 and 78 of
http://citationstylist.org/public/mlzbook.pdf for more context and examples.
Citations, Out of the Box (PDF) - CitationStylisthttp://citationstylist.org/public/mlzbook.pdf
citationstylist.org
viii Foreword Getting to that day will not be simple. No doubt, there will be some who fight to preserve their particular bit of the inefficiency of today’s …

Your proposal is to store these separate reports as a single item, and to
make it possible in CSL to properly render the information from the various
reporters of each item (each report will have its own values for fields
like “container-title”, “volume”, “section”, etc.).

After reading your proposal, I have a few questions:

  • assuming that we store all the publication information from the various
    publishers/reporters in a single item, in some form of ordered array, what
    are the exact formatting requirements for parallel citations? For example,
    for an item with multiple reports, is it ever necessary to be able to:
    • cite a subset of the reports?
    • control the order of the reports?
  • for the old-timers here: does anybody know if there are any good
    discussions here or on the Zotero forums about hierarchical item types? Do
    we have an overview of the various cases where hierarchical item types
    would help? E.g. requested_features [Zotero Documentation] only
    requested_features [Zotero Documentation]https://www.zotero.org/support/requested_features
    www.zotero.org
    This page serves as an overview of the status of some of the most frequently requested features for Zotero. This list is unofficial and is principally maintained by …

mentions “chapters as sub-items of an edited volume”. I’m wondering if
there is a lot of functional overlap between hierarchical item types and
parallel legal citations.

Rintze

P.S. Tom, it looks like every time you respond you start a new thread in
this mailing list, which makes this discussion harder to follow (this
discussion is a continuation of
http://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-specification-tp7579492.html
xbiblio-devel - Proposed change to CSL input XML specificationhttp://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-specification-tp7579492.html
xbiblio-devel.2463403.n2.nabble.com
Proposed change to CSL input XML specification. I have a suggestion for adding a data type to the CSL specification. Overview Some of the design goals of a bibliography system are (1)…

and
http://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-tp7579502.html).
xbiblio-devel - Proposed change to CSL input XMLhttp://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-tp7579502.html
xbiblio-devel.2463403.n2.nabble.com
Proposed change to CSL input XML. Sebastian seems to have a solid grasp on the issues. I also often share his frustration with legal citations. Just so that everyone in the conversation knows what the…

Could you try to reply directly next time? You should be able to do this by
replying to the thread via http://xbiblio-devel.2463403.n2.nabble.com/, or
xbiblio-devel | Mailing List Archivehttp://xbiblio-devel.2463403.n2.nabble.com/
xbiblio-devel.2463403.n2.nabble.com
xbiblio-devel forum and mailing list archive. This list is for development discussion around the xbiblio project, including schema design for the citation style language (CSL) and implementation…

by subscribing to the mailing list at
xbiblio-devel List Signup and Options, after which you
xbiblio-devel Info Page - SourceForgehttps://lists.sourceforge.net/lists/listinfo/xbiblio-devel
lists.sourceforge.net
This list is for development discussion around the xbiblio project, including schema design for the citation style language (CSL) and implementation discussion.

should receive future mailing list emails in your inbox.

On Tue, Jan 3, 2017 at 7:29 PM, Thomas O’Reilly <iamio@…231…> wrote:

After giving more thought to my proposed CSL element, I would like to
modify the proposal. I would to rename the proposed element from
to . Other changes will be listed in my answer to the questions
that Bruce raises.

Bruce brings up 2 important concerns with my previous proposal:

QUESTIONS

  1. Is the proposal necessary?

  2. Could the solution be solved by extending the features of the
    element?

  3. Could the proposal be generalized beyond its niche applicability?

ANSWERS
(1) The proposal is necessary in my opinion.

Frank Bennett has done a lot of incredible work with citeproc-js and
Multi-lingual Zotero. In addition to maintaining the processor, he added
experimental support for parallel citations for legal users. However, the
lengths that he has had to go to achieve that support demonstrate why the
construct should be adopted.

“In CSL-M, parallel citations are produced when the item types of two
adjacent citations match, the items are of a legal type, and their titles
and dates also match.” (Bennett, F. “Citations out of the Box”, p. 78).

This approach introduces several problems. First, storing information
about the same item in two different citations allows the possibility of
storing inconsistent information. Second, it relies upon the processor to
imply a relationship between two citations, instead of relying upon an
explicit data structure. This means that CSL Processors need to have
complicated code in order to support parallel citations - which limits
adoption of the feature. Third - from my understanding - the style creators
don’t have the ability give instructions about how parallel citations
should be styled.

In contrast, supporting a element will ensure data integrity,
it is easier for processors to implement, and it gives style creators the
flexibility to target users of parallel citations, if they choose.

(2) Extending the element to support the proposed features would
NOT be an advisable solution.

Just like the proposed element, the element is
primarily used for item data that is logically related. However, it’s
primary function is that it “implicitly acts as a conditional.” (
CSL 1.0.2 Specification — Citation Style Language 1.0.1-dev documentation).
elements are not rendered if it contains a variable, and the
variables are empty. When a element is rendered, it can apply
prefix before the content, apply a suffix after the content, and apply
delimiters in between its variables.

The element has a clearly defined, useful role in styling data.
However, there are several features that the element lacks compared
to the proposed element.
First, the element does not have a variable name. The
element acts as a collection of variables, but it is not a variable itself.
Second, because the element does not correspond to a variable, it
also does not support iterating through complex data. The element
and element are examples of elements that supported complex data -
data that is represented in a nested structure. A element will
iterate through every name that is associated with that variable. The
proposed element is functionally closer to the element
than to the element. In fact, the element is fairly
be described as a more flexible element. Just you would not want to
extend the element to directly render names, I think that it would
be just as unwise to use to directly render information that a
element should render.

(3) The proposal could be generalized beyond supporting only parallel
citations for legal users.

I think that the element should be named a element, instead
of being named . The allowed sub-elements of would be
elements. This would indicate to style designers that the
element is to be used as a “container” for any pieces of information that
are logically related and that are repeatable.

Each element would be composed of elements.
The elements are directly analogous to elements of
a CSL style. elements should follow the variable-naming
conventions for Standard Variables from Appendix IV of the CSL
specification. (http://docs.citationstyles.org/en/stable/specification.
html#standard-variables).

EXAMPLE REPRESENTATION

<container>

    <container-part name="text-variable-name" />

    .....

</container>

ADDITIONAL THOUGHTS

  1. THE PROPOSAL IS PARTIALLY BACKWARDS COMPATIBLE

If adopted, new CSL styles would be able to process old data. I have
already written a patch for citeproc-js that would support
elements in a CSL style sheet. (81 lines of pretty simple code). My
implementation first looks for item data under the variable-name of the
element. If that variable-name is not found, the processor
then looks for item data using the variable names of the
elements. This means that styles that use elements can still
fully process item data, even if that data was not encoded to explicitly
support elements.

  1. THE PROPOSAL IS NOT FULLY BACKWARDS COMPATIBLE, AND IS NOT COMPATIBLE
    BETWEEN STYLES. THE POSSIBLE VARIABLE NAMES FOR ELEMENTS
    SHOULD BE SPECIFIED

Old style sheets would not be able to process new data that would target
the features of CSL - unless the possible variable names for
elements are constrained. Constraining the variable names
would also required for compatibility between new CSL styles.

It is hard to work out which variable names should be allowed for
elements, without anticipating every use case. If I could
speculate about a possible solution. . . Drawing inspiration from
Bibframe’s model (Overview of the BIBFRAME 2.0 Model (BIBFRAME - Bibliographic Framework Initiative, Library of Congress)),
perhaps the variable name for elements should be limited to
names such “Instances”, “Events”, and “Subjects”.

  • Tom

-------------- next part --------------
An HTML attachment was scrubbed…

Message: 2
Date: Thu, 2 Feb 2017 17:25:11 +0000
From: Darshan Somashekar <darshan@…393…>
Subject: [xbiblio-devel] Job posting: Citation Specialist / CSL Expert
To: “xbiblio-devel@lists.sourceforge.net”
xbiblio-devel@lists.sourceforge.net
Message-ID: <753C3296-D2B3-47F2-9AA9-CA7FEF4487FE@…393…>
Content-Type: text/plain; charset=“utf-8”

Hi everyone,

I co-founded EasyBib, which is an online citation platform used by over 30M students. We are looking for a citation specialist that can work with CSL and address citation related issues amongst our customers. You?d make a huge impact to our product and to the majority of students across the United States that use our tools.

The pay is competitive and our goal is to contribute back to the community. Responsibilities include and will not be limited to:

  •      Continually, thoroughly and objectively assessing the performance and quality of our citation formatting services

  •      Updating citation formatting rules based on latest styles and user feedback

  •      Being the resident citation guru, fielding customer support questions around issues related to citation formatting and quality

  •      Communicating with partners (3rd party companies) that utilize our citation formatting APIs

  •      Mapping out projects, deadlines, and managing citation product roadmap

  •      Ensuring our commitment to continuous improvement and world-class customer service levels

EasyBib and our other citation products are part of Chegg, an educational company focused on improving students? lives.

Further details and application for the job are here: https://jobs.chegg.com/job/CHEGA0056405/Citation-Specialist---Product-Manager

Looking forward to hearing from you!

Best,
Darshan

-------------- next part --------------
An HTML attachment was scrubbed…

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net

End of xbiblio-devel Digest, Vol 118, Issue 1

2

(The mailing list doesn’t seem function well when your email notifications
are set to digest. I’d recommend just responding on the Nabble archive to
respond–it’s what I do. Another good reason to move to a new platform?)

Thomas, given your responses to the formatting particulars of parallel
citations, I wonder whether such a major change as you propose is really
necessary? Given that (1) the reporting requirements across styles are
either all reporters or just the first and (2) the ordering of reporters
should always be consistent, it seems to me like it should work for legal
items to just be expected to have multiples of the individual reporter
fields (e.g., multiple ‘publication’ fields). Each field should be
interpreted as an ordered list so that corresponding elements are in the
same order. in clients, the UI could be arranged to “Add reporter” or
similar, which would add new sets of the relevant fields as a unit. Styles
that require just the primary reporter would then just take the first
element from the list, while other styles would use the full lists.–
View this message in context: http://xbiblio-devel.2463403.n2.nabble.com/Re-xbiblio-devel-Digest-Vol-118-Issue-1-tp7579516p7579517.html
Sent from the xbiblio-devel mailing list archive at Nabble.com.

3

Greetings,

Thank you for referring me to Nabble. I definitely feel like I don’t know what I am doing on the mailing list, and Nabble looks like the ticket. I sent a request for access just now. :blush:

In the mean time, I want to send a link to a blog post that I created. http://odf-bibliography.com/blog/csl/csl_future/ . The gist of the post is that CSL styles are amazing, and they fill an unmet need for bibliographic applications. One of the coolest things that CSL styles can do is create User Interfaces based on the citation system a person is targeting. I also lay out some ideas about how CSL styles could be even more useful for applications.

I know the point of a mailing list is to keep a public record. You should visit my blog (http://odf-bibliography.com/blog/csl/csl_future/) to the interact with the demonstration. However, I will post the main text of the blog below for sake of the record.

  • Tom O’reilly

“”""""""
THE POSSIBLE FUTURE FOR CSL

If you are a developer of a bibliography application, you probably want to allow the user to enter their own data. How can you turn user inputs into a format that is usable by citeproc-js? This question is the starting point, but we are going to end up exploring the philosophic under-pinnings of CSL and of bibliography technology stacks. I will show how CSL can already be used to fill existing needs in the bibliography ecosystem. Then, I will offer suggestions as to how CSL can improve its position as the de facto standard for citation styles.

There is something consequential for applications developers to understand about the Citation Style Language. CSL only defines how to create citation styles. CSL does not define how bibliographic information should be formatted.

CSL is interested only in standardizing how to create style sheets - and it avoids the thorny problem of standarding bibliographic records. There are, in fact, probably hundreds of competing standards for encoding records, and a CSL Processor is free to choose the format that works best for it. For the citeproc-js processor, it relies upon a standard called CSL-JSON. JSON is great for a web application, because it is quite efficient over networks. However, desktop publishing applications would probably prefer to use an XML format for bibliographic records for the sake of consistency.

I am not going to duplicate the tutorial concerning CSL-JSON. You can learn more about it herehttp://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html. I think that there may be some value to having the CSL community adopting one or more standards for bibliographic records. This would be helpful for word processors that want to integrate CSL. It would mean styles and records would be cross-platform - and users would not lose any of their hard work by switching applications. Any standard for bibliographic records should also consider possible applications with semantic web technologies. However, these are just my musings. Let’s dive into how powerfully amazing CSL is currently for productivity.

Even though CSL does not fully standardize how to create bibliographic records, it does provide some guidance to ensure that bibliographic records are compatible across styles. Appendices 1 and 2 apply directly to CSL styles, and Appenice 3 and 4 apply to both bibliographic records and CSL styles.

Appendix 3 defines a set of source "type"s that may characterize a record. The source’s “type” is the fundamental piece of information required of any bibliographic record. This is universal to all citation systems: the formatting of a bibliographic record depends on the source type.

Appendix 4 defines a set of variable fields and their corresponding data-type. It gives a list of approved “string” variables, “number” variables, “name” variables, and “date” variables.

When style creators conform to the conventions laid out in the Appendices, they ensure that bibliographic records will be compatible between styles. This is a powerful feature: to allow users to switch citation styles on the fly without losing any information.

Where does CSL fit in the bigger picture?

Let’s draw back and look at a larger perspective of the bibliography field. One of the paradoxes of bibliographic record standards is that there is opposition between “flexibility” and “compatability.” When a standard is very strictly defined, applications that rely on that standard will be compatible, but it is hard to adapt that standard to every citation system. By relaxing the standard to be flexible enough to accomodate unforseen cases, it makes it harder for applications to interpret and use that data. Let’s pretend that we want a strict standard that is comprehensive of every deviation in citation systems, including (naming, numbering, dating conventions, required fields), then we end up with a standard that becomes too “cumbersome” to use. I think that this characterizes the MARC 21 standard. Some standards take a middle ground between “cumbersome” and “comprehensive,” but they have to exercise editorial judgments about what to include, and how to organize what they have included. This approach characterizes standards like Zotero, OOXML, ODF.

I think the Citation Style Language is in a sweet spot to help answer that paradox. There are two layers of a bibliography technology stack: the application on top and bibliographic records on the bottom. Citation style languages insert another layer of abstraction into the middle of the bibliography stack - which helps bridge the application’s need for data compatability and the user’s need for flexibility. If a record represents a source, the CSL style is a representation of the real world citation system. The CSL language defines the CSL styles, which in turn, define the parameters of bibliographic records. The citaiton language layer is also the best layer to make editorial judgments, because citation styles have the best knowledge of the citation systems they model. Editorial judgments could be pushed from the application layer to CSL style layer, which frees application developers from having to become bibliography experts and making editorial judgments about how to organize bibliographic systems.

By embracing CSL as this middle layer of abstraction, we can see how to extend CSL’s current functionality. Not only can CSL styles be used for format bibliography records; it can be used to generate interfaces for user input in applications.

The CSL style determines which variable fields can be displayed - and under which conditions they will be displayed. This makes bibliography UI much more manageable, because we can hide fields that are irrelevant to the user. This also informs the user when they are missing information that is important. Finally, it removes editorial control from the application developer, and places that control with style creators.

How to user-interface generation works

CSL styles are a branching logic flow chart. I created a module called “SetLogic” that can iterate through every logic path, and evaluate what conditions have been cumulatively applied to the statement at the end of those nodes. Thus, the processor knows under what conditions each node will be rendered in output. The processor then pairs which fields will be displayed with which source type. Click herehttp://odf-bibliography.com/static/logic%20validator.odt to read more about how SetLogic works, and other potential applications for SetLogic.

I created a second module called Form Utility. Form Utility depends on the SetLogic module for the relationships between fields and source types, and repackages them into a template for easy form generation. It will return all the source types referenced by the CSL style. It will also return an array of month and season names, based upon the locale file. Calling FormUtility.retrieve() will return an object with the following properties:

  • “fields”: a dictionary of fields, their types, and associated subfields.
  • “menu”: an array of types. Each type is an object with a “label” and “value” property.
  • “dateSelect”: contains an array of seasons and an array of months. Each is represented by an object with a “value” property corresponding to the CSL Appendix II (Months and Seasons). Each object also has a long-form name and short-form name for the month or season (as long as both are supported by the locale). Try the “Russian GOST R 7.0.5-2008 (numeric, sorted alphabetically, Russian)” style to see how date-fields are automatically localized for styles.

Future Development of CSL
Compatability v. Flexibility

One of the limitations of CSL is a return to the perrenial dillema - how do we acheive compatability and flexibility? CSL styles are compatible with each other, because they adhere to the CSL Appendices I-IV. They share the same “types”, the same variable names, the same field categories, and the same terms. Unfortunately, this compatibility undermines flexibility of style creators, and a significant amount of editorial judgments made by the CSL crafters is locked at the application level. We should look for a mechanism to push editorial judgment and autonomy into the style level.

Source Type

One example that I run into is in creating styles for legal users. While CSL has one classification for “legal_case”, the BlueBook citation system distinguishes between Article III Courts, administrative courts, and arbitrations. Where CSL has the “legislation” type, the BlueBook distinguishes constitutions, passed statutes, resolutions, and executive orders. I imagine that this problem is true for every specialized discipline. Style creators are using their editorial judgment to match the types recognized by the citation system to the types defined by CSL. However, if style creators could map the citation system’s type to CSL types, and test against those arbitrary types in a style sheet, then they could create very accurate styles. Moreover, the styles would generate even more tailored UI.

Complexity v. Usability

I think that our technology will have arrived when novices can create high quality citations without ever referring to a citation guide. We have a start on the promise already. By having a UI that only displays fields that are relevant to the source’s type, the application informs the user about the requirements of the citation system. However, we can do much more to make the interface informative to the user. One way of doing this is through tooltips that popup when the cursor or finger hovers over the field name.

The easy way to implement this feature is to use the CSL definition for variables (taken directly from CSL Appendix IV). However, what if these tooltips could offer specific guidance for how to use those variable fields within the citation system. I will demonstrate with another example from BlueBook concerning the “issued” field.

CSL specifies that, generally, the “issued” date variable contains the “date the item was issued/published.” It’s the primary field used for dating items in CSL. However, the BlueBook citation system rules for dating sources is much more complicated. For example:

  • Cases are dated with the date they are decided.
  • Statutes are dated with the date of the code edition cited.
  • In-force Constitutional provisions are not dated, except provisions that have been repealed are dated by the date of the repeal. And superseded constitutions are dated by the year of adopton.

Dating rules are complicated, and style creators are usually experts of a citation system. Style creators could add a ton of value to styles if they could communicate their knowledge of the intricacies of style rules to their users. Such style creators would want tips that are specific to that variable field and item type.________________________________
From: xbiblio-devel-request@lists.sourceforge.net xbiblio-devel-request@lists.sourceforge.net
Sent: Saturday, May 27, 2017 8:29 AM
To: xbiblio-devel@lists.sourceforge.net
Subject: xbiblio-devel Digest, Vol 119, Issue 1

Send xbiblio-devel mailing list submissions to
xbiblio-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
xbiblio-devel Info Page - SourceForgehttps://lists.sourceforge.net/lists/listinfo/xbiblio-devel
lists.sourceforge.net
This list is for development discussion around the xbiblio project, including schema design for the citation style language (CSL) and implementation discussion.

or, via email, send a message with subject or body ‘help’ to
xbiblio-devel-request@lists.sourceforge.net

You can reach the person managing the list at
xbiblio-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than “Re: Contents of xbiblio-devel digest…”

Today’s Topics:

  1. Re: xbiblio-devel Digest, Vol 118, Issue 1 (bwiernik)

Message: 1
Date: Tue, 7 Feb 2017 01:30:04 -0700 (MST)
From: bwiernik <xbiblio@…377…>
To: xbiblio-devel@lists.sourceforge.net
Subject: Re: [xbiblio-devel] xbiblio-devel Digest, Vol 118, Issue 1
Message-ID: <1486456204706-7579517.post@…157…>
Content-Type: text/plain; charset=us-ascii

(The mailing list doesn’t seem function well when your email notifications
are set to digest. I’d recommend just responding on the Nabble archive to
respond–it’s what I do. Another good reason to move to a new platform?)

Thomas, given your responses to the formatting particulars of parallel
citations, I wonder whether such a major change as you propose is really
necessary? Given that (1) the reporting requirements across styles are
either all reporters or just the first and (2) the ordering of reporters
should always be consistent, it seems to me like it should work for legal
items to just be expected to have multiples of the individual reporter
fields (e.g., multiple ‘publication’ fields). Each field should be
interpreted as an ordered list so that corresponding elements are in the
same order. in clients, the UI could be arranged to “Add reporter” or
similar, which would add new sets of the relevant fields as a unit. Styles
that require just the primary reporter would then just take the first
element from the list, while other styles would use the full lists.