Re: xbiblio-devel Digest, Vol 118, Issue 1

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Re: xbiblio-devel Digest, Vol 118, Issue 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. :)

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.

2. 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

3. 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 <container> elements to hold simple fields - it does not allow name fields, date fields, or nested <containers>. 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 <container> element would have to at least accommodate name fields. The initial <container> in the array could represent the smallest level of container, and each subsequent <container> 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 -->




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





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



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



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






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 <container> elements. For instance, does the element <issued> become a child element of <item> or should it be a child element of a <container> element?

(I personally think that <title> and <issued> elements should always occur under <item>).

- Tom

From: [hidden email] <[hidden email]>
Sent: Thursday, February 2, 2017 4:58 PM
To: [hidden email]
Subject: xbiblio-devel Digest, Vol 118, Issue 1
Send xbiblio-devel mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
Subject: Re: [xbiblio-devel] Proposed change to CSL input XML
To: development discussion for xbiblio
        <[hidden email]>
        <CA+pmmQR=ygg_Th=oZCpvw60Sp23k+[hidden email]>
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 for more context and examples.
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. only
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.


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
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)...

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, or
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, after which you
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 <[hidden email]> 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 <serials>
> to <containers>. Other changes will be listed in my answer to the questions
> that Bruce raises.
> Bruce brings up 2 important concerns with my previous proposal:
> 1) Is the proposal necessary?
> 2) Could the solution be solved by extending the features of the <group>
> element?
> 3) Could the proposal be generalized beyond its niche applicability?
> (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
> <containers> 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 <containers> 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 <group> element to support the proposed features would
> NOT be an advisable solution.
> Just like the proposed <containers> element, the <group> element is
> primarily used for item data that is logically related. However, it's
> primary function is that it "implicitly acts as a conditional." (
> <group> elements are not rendered if it contains a variable, and the
> variables are empty.  When a <group> element is rendered, it can apply
> prefix before the content, apply a suffix after the content, and apply
> delimiters in between its variables.
> The <group> element has a clearly defined, useful role in styling data.
> However, there are several features that the <group> element lacks compared
> to the proposed <containers> element.
> First, the <group> element does not have a variable name. The <group>
> element acts as a collection of variables, but it is not a variable itself.
> Second, because the <group> element does not correspond to a variable, it
> also does not support iterating through complex data. The <names> element
> and <date> element are examples of elements that supported complex data -
> data that is represented in a nested structure. A <names> element will
> iterate through every name that is associated with that variable. The
> proposed <containers> element is functionally closer to the <names> element
> than to the <group> element. In fact, the <containers> element is fairly
> be described as a more flexible <names> element. Just you would not want to
> extend the <group> element to directly render names, I think that it would
> be just as unwise to use <group> to directly render information that a
> <containers> 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 <containers> element, instead
> of being named <serials>. The allowed sub-elements of <containers> would be
> <container> 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 <container> element would be composed of <container-part> elements.
> The <container-part> elements are directly analogous to <text> elements of
> a CSL style. <container-part> elements should follow the variable-naming
> conventions for Standard Variables from Appendix IV of the CSL
> specification. (
> html#standard-variables).
> <containers name="variable-name">
>     <container>
>         <container-part name="text-variable-name" />
>         .....
>     </container>
> </containers>
> If adopted, new CSL styles would be able to process old data. I have
> already written a patch for citeproc-js that would support <containers>
> 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
> <containers> element. If that variable-name is not found, the processor
> then looks for item data using the variable names of the <container-part>
> elements. This means that styles that use <containers> elements can still
> fully process item data, even if that data was not encoded to explicitly
> support <containers> elements.
> Old style sheets would not be able to process new data that would target
> the <containers> features of CSL - unless the possible variable names for
> <containers> 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
> <containers> elements, without anticipating every use case. If I could
> speculate about a possible solution. . . Drawing inspiration from
> Bibframe's model (,
> perhaps the variable name for <containers> 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 <[hidden email]>
Subject: [xbiblio-devel] Job posting: Citation Specialist / CSL Expert
To: "[hidden email]"
        <[hidden email]>
Message-ID: <[hidden email]>
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:

Looking forward to hearing from you!


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


Check out the vibrant tech community on one of the world's most
engaging tech sites,!


xbiblio-devel mailing list
[hidden email]

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

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
xbiblio-devel mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: xbiblio-devel Digest, Vol 118, Issue 1

Brenton Wiernik
(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.