[citeproc-js] Implementation questions and bug reports

[skornblith]

I almost have Zotero working with citeproc-js (at least in a
preliminary form), but I have a couple of questions regarding
implementation, and one apparent bug.

1) What's the best way to include items not cited in citation clusters
in a bibliography?

2) Is there any way to get the item IDs corresponding to the sorted
bibliography output by makeBibliography? This would be useful as far
as allowing users to customize specific entries in the bibliography.

3) Calling makeBibliography twice from the same CSL.Engine instance
with a style that uses subsequent-author-substitute appears to result
in all of the authors being treated as subsequent (i.e., replaced by
"---" in Chicago).

4) In the CSL 1.0 chicago-author-date style, citeproc-js is currently
rendering citations with >4 authors as:

(Smith, et al. 2008)

whereas the correct formatting is:

(Smith et al. 2008)

with no comma between the author name and "et al." I'd suggest we keep
the current default behavior, and allow style developers to add the
comma if necessary using the new et-al element.

Thanks for your help,
Simon

--
Group home: http://groups.google.com/group/citeproc-js?hl=en
To post: citep...@googlegroups.com
To unsubscribe: citeproc-js...@googlegroups.com
Citeproc-js home: home: http://bitbucket.org/fbennett/citeproc-js/wiki/Home

[Bruce D'Arcus]

On Mon, Apr 26, 2010 at 1:51 AM, skornblith <si...@simonster.com> wrote:

...

> 4) In the CSL 1.0 chicago-author-date style, citeproc-js is currently
> rendering citations with >4 authors as:
>
> (Smith, et al. 2008)
>
> whereas the correct formatting is:
>
> (Smith et al. 2008)
>
> with no comma between the author name and "et al." I'd suggest we keep
> the current default behavior, and allow style developers to add the
> comma if necessary using the new et-al element.

Shouldn't this be a question for the CSL spec?

Bruce

[Rintze Zelle]

On Mon, Apr 26, 2010 at 11:03 AM, Bruce D'Arcus <bda...@gmail.com> wrote:

On Mon, Apr 26, 2010 at 1:51 AM, skornblith <si...@simonster.com> wrote:

...

> 4) In the CSL 1.0 chicago-author-date style, citeproc-js is currently
> rendering citations with >4 authors as:
>
> (Smith, et al. 2008)
>
> whereas the correct formatting is:
>
> (Smith et al. 2008)
>
> with no comma between the author name and "et al." I'd suggest we keep
> the current default behavior, and allow style developers to add the
> comma if necessary using the new et-al element.

Shouldn't this be a question for the CSL spec?

Bruce

The spec currently specifies (http://citationstyles.org/downloads/specification.html#name): 'the "et-al" term is appended to the names rendered, preceded by a space (e.g. "Doe et al.").'. This approach is already used by the current Zotero CSL processor, and is correct for most citation styles. With CSL 1.0, styles that need a delimiting comma can use the cs:et-al element (it isn't mentioned in the spec, but with this new element no preceding space should be used), e.g.:

<names variable="author">
  <name/>
  <et-al prefix=", "/>
</names>

to get

(Smith, et al. 2008)

Rintze

[Frank Bennett]

On Apr 26, 2:51 pm, skornblith <si...@simonster.com> wrote:
> I almost have Zotero working with citeproc-js (at least in a
> preliminary form), but I have a couple of questions regarding
> implementation, and one apparent bug.
>
> 1) What's the best way to include items not cited in citation clusters
> in a bibliography?

It's not as easy as it could be yet. If things are working as they
ought in the processor, the updateItems() command should be non-
destructive, so additional cites can be added in that way. That means
shipping the set across after every edit, though, and thrashing with
the removal of cites upon document edit, then restoration of non-cited
items ... awkward.

I could set up a method similar to updateItems(), with the same
interface, that works against uncited bib items. Would that fit the
bill?

>
> 2) Is there any way to get the item IDs corresponding to the sorted
> bibliography output by makeBibliography? This would be useful as far
> as allowing users to customize specific entries in the bibliography.

Not yet. What would you like the returned data structure to look
like?

>
> 3) Calling makeBibliography twice from the same CSL.Engine instance
> with a style that uses subsequent-author-substitute appears to result
> in all of the authors being treated as subsequent (i.e., replaced by
> "---" in Chicago).

I'll take a look at this tomorrow.

>
> 4) In the CSL 1.0 chicago-author-date style, citeproc-js is currently
> rendering citations with >4 authors as:
>
> (Smith, et al. 2008)
>
> whereas the correct formatting is:
>
> (Smith et al. 2008)
>
> with no comma between the author name and "et al." I'd suggest we keep
> the current default behavior, and allow style developers to add the
> comma if necessary using the new et-al element.

If the existing behavior is to be preserved, is it et-al-use-first > 1
that triggers the comma, or the actual rendering of more than one name
in the cite?

[Frank Bennett]

On Apr 27, 12:44 am, Frank Bennett <biercena...@gmail.com> wrote:
> On Apr 26, 2:51 pm, skornblith <si...@simonster.com> wrote:

> > 3) Calling makeBibliography twice from the same CSL.Engine instance
> > with a style that uses subsequent-author-substitute appears to result
> > in all of the authors being treated as subsequent (i.e., replaced by
> > "---" in Chicago).
>
> I'll take a look at this tomorrow.

I just tried this in the demo page (single instance of the processor
rendering two identical bibliographies in sequence with the
makeBibliography() command), and get two identical bibliography
listings. If you're using an earlier version of the processor, this
might be a bug that's been fixed. The interfaces haven't changed in
the past month (at least I'm pretty sure not). The xmle4x.js module
now needs to be loaded separately from citeproc.js, and that's about
it.

If your processor is up to date, we'll have to figure out what in the
new environment it's unhappy with.

Frank

[Frank Bennett]

On Apr 27, 12:44 am, Frank Bennett <biercena...@gmail.com> wrote:

> On Apr 26, 2:51 pm, skornblith <si...@simonster.com> wrote:

[snip]

> > 4) In the CSL 1.0 chicago-author-date style, citeproc-js is currently
> > rendering citations with >4 authors as:
>
> > (Smith, et al. 2008)
>
> > whereas the correct formatting is:
>
> > (Smith et al. 2008)
>
> > with no comma between the author name and "et al." I'd suggest we keep
> > the current default behavior, and allow style developers to add the
> > comma if necessary using the new et-al element.
>
> If the existing behavior is to be preserved, is it et-al-use-first > 1
> that triggers the comma, or the actual rendering of more than one name
> in the cite?

For the present, I've dropped the comma from the join preceding an
implicit "et al." term.

My question above obviously didn't make any sense. If a comma is
desired when the "et al." term follows two or more names, the
processor could be rigged to use the inter-names delimiter in that
case. That approach would cover both implicit "et al." terms, and
cases where the explicit cs:et-al node is used.

I'll post a query to xbiblio-devel on this shortly.

Frank

[Frank Bennett]

On Apr 27, 12:44 am, Frank Bennett <biercena...@gmail.com> wrote:

> On Apr 26, 2:51 pm, skornblith <si...@simonster.com> wrote:

> > 2) Is there any way to get the item IDs corresponding to the sorted
> > bibliography output by makeBibliography? This would be useful as far
> > as allowing users to customize specific entries in the bibliography.
>
> Not yet. What would you like the returned data structure to look
> like?

In the latest changeset, I've added an "entry_ids" field in the header
returned by makeBibliography(). The value of entry_ids is not a
straight list of item IDs, but a list of sublists of IDs, so you'll
need to unpack the values for each entry when it's used. The nested
list structure is needed to cope with parallel citations, where a
single bibliography entry might consist of multiple items, and the set
needs to be handled in lock-step.

I haven't tested the code directly (header values are still beyond the
scope of the test harness), but all tests pass so it should be
working. If the interface or return values need adjustment, let me
know.

Frank

[Frank Bennett]

On Apr 27, 12:44 am, Frank Bennett <biercena...@gmail.com> wrote:

> On Apr 26, 2:51 pm, skornblith <si...@simonster.com> wrote:
>

> > 1) What's the best way to include items not cited in citation clusters
> > in a bibliography?
>
> It's not as easy as it could be yet.  If things are working as they
> ought in the processor, the updateItems() command should be non-
> destructive, so additional cites can be added in that way.  That means
> shipping the set across after every edit, though, and thrashing with
> the removal of cites upon document edit, then restoration of non-cited
> items ... awkward.
>
> I could set up a method similar to updateItems(), with the same
> interface, that works against uncited bib items.  Would that fit the
> bill?

I've added a command .updateUncitedItems(), which should cover this.
It's still untested and hasn't been added to the manual yet, but it's
meant to take a list of item IDs to treat as uncited, add any missing
items to the registry, and reconcile everything for names
disambiguation et cetera. To add or remove items from the uncited
list, run the command again with the full modified list of IDs. Items
removed from the uncited list will actually be removed from the
registry (and the bibliography) when the next updateItems or citation
editing command is run.

If bugs turn up, let me know and I'll get to work testing this, but it
should work (it says here).

Frank