XBib

So I've applied and committed the 00-near-note.patch. If there's an error,
feel free to correct it yourself Frank.

Have uploaded a schema patch, near_note.diff, that adds this facilty as a
"near-note" position operator, together with a related option to control
what constitutes "nearness". The comments in the patch (I hope) explain
how it works.

assigning to Frank, to propose spec language and schema changes

Sorry, that was me immediately below. There's a typo in the post:
"disambiguaton-add-year-suffix" should have read
"disambiguate-add-year-suffix", that misspelling was mine, not a c&p from
the repository.

If this seems like a special favor to the note styles, maybe that's just
because they are coming to the table late in the day.

There are currently just 26 note styles in the repository, against 118
in-text styles. A quick scan and comparison of the options used in each
turns up one condition, five options and a variable that are used
exclusively by the in-text styles. As far as I can tell, no options,
variables or conditions are currently used only by in-note styles. This
would be the first.

The items currently found only among in-text styles are:

<if disambiguate="true">

<option name="disambiguaton-add-year-suffix" value="true"/>
<option name="line-spacing" value="..."/>
<option name="second-field-align" value="true"/>
<option name="collapse" value="citation-number"/>
<option name="collapse" value="year-suffix"/>

<text variable="citation-number"/>

I'll read this more carefully later, but to clarify my #1 point, I'm just
really leery of adding a conditional that is specific to only one class of
styles.

Absolutely agree on the need to pin down exactly what the CSL would look
like and how it should behave. On the two issues:

"1) but can we not assume previous note distance = previous citation
distance?"

Not in a note style, unfortnately. I tried to make a case several months
ago for requiring footnotes to always be generated with Zotero, but after
you objected that it would be too paternalistic, and Simon pointed out that
it was not necessary, I've thought again and changed my mind. If users can
generate footnotes independently of Zotero, there might be quite a few
commentary footnotes between two that contain citations.

In an Author-Date style, it could, and maybe should, evaluate on the
citation distance to the most recent reference. But I don't think it would
be needed to suppress Ibid. As far as I know, ibid is only used where the
immediately preceding reference in the same citation is to the same source,
or where the cite is the first in the current citation, and the immediately
preceding citation contains only one reference, and it is a reference to
the same source and the current cite. If the two cites referring to the
source are separated by one or more other citations, the subsequent form
would be used.

Maybe there would be another use case where it would be needed, but I
can't think of one off the top of my head.

"2) ... We might need to consider this as we think about testing, and
conformance, and allow for different levels. And it follows that whatever
solution would need to avoid breaking code that doesn't support this
feature."

Thinking out loud, and sort of at length as well ...

Might we call the capability sets "layers" rather than levels, to avoid
implying a quality evaluation? (In some applications, a processor with a
smaller feature set and greater speed or a smaller footprint might be just
as good or better.)

I can think of three considerations around differing layer support. One
is to accurately and concisely describe the capabilities of a processor for
the benefit of integrators (i.e. "The ClamPress Processor supports the
Bibliography and Disambiguation Level 1 layers of the CSL specification.").
I suppose that would be a more general topic than this one, appropriate
for the thread you have started on xbiblio-devel.

Another question is how layers of support should be handled in the syntax
of styles. I guess the threshold question would be whether (A) it should
be required that all attributes be defined even if they are not supported,
or whether (B) there should instead be a "layer" or "level" condition that
style designers must use to screen them from the processor entirely in the
event that support is not intended.

In this case, those two alternatives could work like this. If we choose
in impose (A), this option could be required always to return "false" by
applications that do not support max-notes-to-last-reference, which would
have the effect of forcing the "full" form of the cite. If we choose to
impose (B), there would be a supporting option, which might be something
like "has-max-notes-to-last-reference" (or "has-layer-16" or something).
That condition could be used, for example, to apply ibid/supra cite forms
if the distance to the most recent reference cannot be measured.

(A) and (B) are not alternatives; they could both be offered, with (A)
providing reasonable fallback behavior if the option is not supported, with
no need for the designer to provide special handling in the style. The use
of (B), even if always possible, could be optional.

On balance, for this particular case, I would favor sticking with (A)
only, requiring that processors not crash on the option, and allowing them
to return always "false" if they do not support this functionality. The
resulting output would still be useful, and might not be that far off of
style requirements, depending on the context.

Oh, and by details, I don't mean at the level of, say, Zotero and Word. I
mean conceptually WRT to CSL and the spec.

I'm not totally averse to this, but you need to respond to my latest two
points/questions. I don't want to implement something this hairy unless
we're crystal clear on what it means, and how it will work. I also want to
make sure any such styles can gracefully degrade for processors that may
not support this feature.

It would be a terrific if this could be implemented. Let me know if there
is anything that I can do in citeproc-js to help prepare the ground. In
the second para of your description, assuming that there is a UID for each
citation cluster, would it be sufficient to simply cache the item IDs, and
parameters supplied by the user (like page locator), and by the integration
layer (like first/ibid/subsequent position), and return a set of UIDs (or
rendered data) for citations that show some difference?

Sorry, I wasn't logged in before, so, in case it wasn't clear, that last
anonymous post was mine.

After thinking about it carefully, I think that this is possible without a
major performance hit. Zotero could keep track of the footnote number for
each citation that's in a footnote, which would require another
COM/UNO/appscript call for each field. My impression is that these calls
are relatively cheap in COM and UNO, but more expensive in appscript.
However, this might be desirable anyway for better handling of Ibid. when
users have non-Zotero footnotes interspersed with Zotero footnotes. Zotero
could then check the footnote number of the closest preceding reference to
the citation in the document, which would be very easy, and pass this to
the CSL processor.

This is pretty trivial as long as we don't care about citations inserted
between citations. If we do, every time the document is updated, we'd have
to call some function in citeproc-js that takes the data properties of the
old and new citation clusters and determines whether the citation needs to
be updated as a result. If implemented properly, the performance cost of
such a function should be relatively small, and if we use the same function
to check whether a citation needs to be updated when its position has
changed (i.e., first to subsequent), we could potentially save cycles in
the long run, since right now we always regenerate in this case even when
it's unnecessary (e.g., ibid to subsequent in an author-date style).

In short, I think that this is doable and am not strictly opposed to
implementing it on the Zotero side. The route I've outlined above wouldn't
dirty the citeproc-js API too much, and would (I think) allow us to
implement the desired behavior.

OK, two things:

1) but can we not assume previous note distance = previous citation
distance? E.g. do we really need to restrict this logic only to note
styles? I could imagine an author-date style might, for example, want to
turn off ibid handling after a certain distance. This hinges, I guess, on
whether there may be more than one reference to the same source per
citation/note.

2) this is the bigger thing: I think if we do add this, it's unlikely to
be widely implemented; citeproc-js may be the only supporting code for at
least a long while. We might need to consider this as we think about
testing, and conformance, and allow for different levels. And it follows
that whatever solution would need to avoid breaking code that doesn't
support this feature.

Law review articles are very densely cited, and because pinpoint references
are required for every assertion in the main text, just about everything is
cited multiple times.

The backreference rules for books and articles are uniform, using author
or short title, "supra", the note number, and the pinpoint location in the
cited source. Law cases and legislative materials do not (normally) use
"supra", but (as per the notes quoted in the ticket) a short form that
contains only the essential details for identifying the reference. The
long form must be repeated whenever the reference has been "sleeping" for
more than 5 notes.

For better or worse, those are requirements, not loose conventions.
Citation styles in law are extremely strict, in part because law review
editorial work is a training ground for courtroom practice. For reading
efficiency (not automated processing), each court has a very specific style
for citing authorities in legal memoranda. Judges have heavy reading
burdens, and many of them are quite strict about citation forms. A lawyer
submitting a non-conforming brief is likely to have it thrown back at him
at the hearing, and be told to go home and do it again, with a few caustic
remarks within earshot of the client. So law review styles tend to be
complex and unforgiving, and they're meant to be that way -- it's a test of
the review editors' (and now my own) eye for detail.

Personally, I like keeping things simple and easy, but unfortunately
that's not the result of the dynamics in this case.

So for backreferences in Bluebook, we need access to the first reference
note number, plus a condition to check the note distance to the most recent
reference to the same source.

As for implementation, Simon has suggested and I have agreed that citation
position state will be maintained in the integration layer of Zotero
(integration.js), while bibliography ordering, sub-citation sorting and
disambiguation state awareness will reside in the CSL processor itself.
For this item, the CSL processor can either derive the value from the note
numbers, if these are sent to it when individual cites are rendered, or it
can receive a "note distance to last reference" with each rendering request
made by the integration layer. But it's not much more trouble to manage
than first reference note numbers, and much simpler than disambiguation and
sort key management.

Tracking page numbers as discussed on comp.text.tex is very difficult,
perhaps that can be left to another day, once note number back references
are working.

Oh, I see the rule says this is for legislative materials.

Can you speculate on whether we need to read this literally, or whether
it's written this way because people using Bluebook typically don't cite
anything but legislative material multiple times? In other words, if
someone cited some book many times, would it be wrong to give the full form
after x previous citations?

E.g. for sake of argument, is it feasible an option like
"reset-first-citation-condition-after-value" (I know, ugly and wordy) could
work for BB, but also then be usable for other kinds of styles?

<citation reset-first-citation-condition-after-value="5">...</citation>

Another point on the implementation angle that's related to the question of
whether this is a more generic problem: keeping track of citation
references and optionally resetting the "first" condition every n
occurrences seems like a PITA, but feasible. But I'm really not sure how a
processor can reliably count notes directly.

Also, consider a thread on comp.text.tex [1], where the author of biblatex
pointed out that one can configure ibid handling to be limited to the scope
of the page. This suggests the context may not only be so specific as
"max-notes-to-last-reference."

Finally, as I suggest in that thread on comp.text.tex, this could be a
parameter (if we answer the implementation question I asked).

[1]

Irrespective of how to configure this in CSL, the big issue that stands out
to me is "not an easy thing to implement." Can you talk about how you would
do this, and what the performance implications might be?