Re yesterday’s check-in,
note: one issue unique to note-based styles is that a citation reference
effectively may become a full sentence. Implementers should consider this in
their design and insert the final formatted citation in the correct
title form.
For example, if a citation is footnoted without any additional
text, the first
character of the output should be uppercased. By contrast, if the citation is
within a pre-existing footnote, and preceded by non-citation text,
then it should
be printed as is.
Digging into the document text directly is hard, because it may
contain formatting codes that are unknown or difficult to interpret
without the full document context (Andrea’s point in his last mail).
This case will probably be handled with some sort of hinting specific
to a CSL implementation. Zotero will probably just look as far as the
user-entered prefix field in the citation form, and possible to the
suffix of an preceding cite in a cluster. Andrea may be able to add
some sort of hint to the in-text keys that his system uses, so that
citeproc-hs knows what to do. That’s not a quibble, just a comment;
the need is there, and it’s good that this note is in the
specification.
Frank
My plan is to specifically add a prefix field in the data received by
the main processing function, that is to say: a citation in a list of
citation groups will be made of a citation key, the locator, a prefix,
a suffix, and some local modifier, for suppressing the author name or
for adding parenthesis, etc.
So it is the application calling citeproc which will have to provide
those information, like the Zotero prefix field in the citation form.
Which makes me think that probably will should think that any
implementation should adhere to a common standard.
Frank, since you are in the process of writing your implementation you
could probably use this opportunity to suggest something in this
direction. I hope to start coding again in the next few days, to
update citeproc-hs to these latest changes, so I could provide some
feedback too.
Andrea
…
My plan is to specifically add a prefix field in the data received by
the main processing function, that is to say: a citation in a list of
citation groups will be made of a citation key, the locator, a prefix,
a suffix, and some local modifier, for suppressing the author name or
for adding parenthesis, etc.
So it is the application calling citeproc which will have to provide
those information, like the Zotero prefix field in the citation form.
Which makes me think that probably will should think that any
implementation should adhere to a common standard.
Yup.
BTW, a vaguely related aside:
I wrote something over the weekend on my blog that argues that
processing code needs to be put closer to the word-processor, etc.
than to the bibliographic application. So in this model, apps like
Zotero provide data to the plug-in, but the data is stored in the
document (in cases like ODF, OOXML and such) and processed from there.
http://community.muohio.edu/blogs/darcusb/archives/2009/03/01/the-babel-of-citations
I think that’s the only way we’re likely solve the currently
completely unacceptable lack of interoperability of these tools (e.g.
two Zotero users can’t even collaborate on a document, much less with
people using other bib applications).
Got an interesting response from one of the KOffice devs (who I know
from the ODF TC work).
Bruce
Re yesterday’s check-in,
note: one issue unique to note-based styles is that a citation reference
effectively may become a full sentence. Implementers should consider this in
their design and insert the final formatted citation in the correct
title form.
For example, if a citation is footnoted without any additional
text, the first
character of the output should be uppercased. By contrast, if the citation is
within a pre-existing footnote, and preceded by non-citation text,
then it should
be printed as is.
Digging into the document text directly is hard, because it may
contain formatting codes that are unknown or difficult to interpret
without the full document context (Andrea’s point in his last mail).
This case will probably be handled with some sort of hinting specific
to a CSL implementation. Zotero will probably just look as far as the
user-entered prefix field in the citation form, and possible to the
suffix of an preceding cite in a cluster. Andrea may be able to add
some sort of hint to the in-text keys that his system uses, so that
citeproc-hs knows what to do. That’s not a quibble, just a comment;
the need is there, and it’s good that this note is in the
specification.
My plan is to specifically add a prefix field in the data received by
the main processing function, that is to say: a citation in a list of
citation groups will be made of a citation key, the locator, a prefix,
a suffix, and some local modifier, for suppressing the author name or
for adding parenthesis, etc.
So it is the application calling citeproc which will have to provide
those information, like the Zotero prefix field in the citation form.
Which makes me think that probably will should think that any
implementation should adhere to a common standard.
Frank, since you are in the process of writing your implementation you
could probably use this opportunity to suggest something in this
direction. I hope to start coding again in the next few days, to
update citeproc-hs to these latest changes, so I could provide some
feedback too.
Very glad to, if it will help. I think that as you say it’s just
about taking hints from the punctuation of external prefixes and
suffixes, and some sort of hint about what to do with the very first
character in the cluster (ah, and author names). The only headache is
to specify the possibilities – there will be lots of them in the
splicing stuff, since it’s not a simple nested join.
Test cases will give us a concise way of expressing the possibilities,
so I’ll work on setting that up first. Tests will also help me to
keep the coding under control, since then things can be torn up
without risk of losing the thread.
Frank