public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: John MacFarlane <fiddlosopher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: pandoc/citeproc issues: multiple bibliographies, nocite, citeonly
Date: Tue, 30 Nov 2010 19:25:56 -0800	[thread overview]
Message-ID: <20101201032556.GA28952@protagoras.phil.berkeley.edu> (raw)
In-Reply-To: <4CF43B30.9050400-8UOIJiGH10pyDzI6CaY1VQ@public.gmane.org>

+++ Nathan Gass [Nov 30 10 00:45 ]:
> >>One possibility would be a special attribute on a header:
> >>
> >># Works cited {.bibliography src="mybib.json"}
> >>
> >># References {.bibliography src="foo.bib" include="item2,item3"
> >>                omit="item4" if-year="1999" only-if-type="primary"}
> 
> I like this, especially as this syntax would allow the addition of
> other features without adding new syntax later on.
> 
> >
> >PS.  I'm sorely tempted to put off implementing these complexities
> >til later, and release a simple version of pandoc/citeproc that just
> >constructs a bibliography of works cited in the document and puts
> >them at the end, more or less the way it does now.
> 
> +1 one to that
> 
> The only problem I see with that plan is the following:
> The sensible default now would be to always add a bibliography. On
> the other hand, if we have a syntax to  include the bibliography
> where ever we want, the better default would be to not include any
> bibliography per default.
> 
> But I think an appropriate warning for future incompatible changes
> would be enough in this case, as the documents will be easy enough
> to convert.

I'd like to avoid having documents work now and then fail later,
even if they're easy to convert.

Abstracting from the details, and from the question of whether we're
going to implement fancy filtering now, the main questions we need to decide
are:

1. whether the bibliography file should be specified in the text or as
a command-line option.  (I think having both possibilities would be
confusing -- it should be one or the other, I think.)

2. whether multiple bibliographies should be allowed, or just one
bibliography at the end.

The current implementation answers 1 by "command-line option."
If we want the bibliography file to be specified in the text,
then we need

(a)  a syntax for specifying this in the file
(b)  some architectural changes to account for the fact that
the bibliography file won't be known until after the markdown
parser has been called. (More on this below.)

For (a), I currently favor either the XML syntax or the attribute syntax after
a header that would serve as the header for the bibliography. Example:

    # References { bib="mybib.bib" }

(Though this forces you to have a header before the bibliography,
as the XML doesn't.)

This would also go well with multiple bibliographies (question 2).
And it could be extended to allow filtering when this is available
(it might already be available, in the latest darcs citeproc):

    # Primary sources { bib="mybib.bib" include-type="primary" }

Another alternative (and the only way to go if we don't allow
multiple bibliographies) would be to add a metadata block and
put the bibliography filename there.  I'm probably going to add
a metadata block at some point, but it would be nice to avoid
doing it just yet, as it would require many more decisions.

If we allow multiple bibliographies, we'll also need to change
the code in Text.Pandoc.Biblio, but I think this should be
fairly straightforward.

I guess I'm tempted to:
- allow multiple bibliographies
- specify the source file in the markdown text, as above

I'm not positive this will work, though. As I mentioned, there are technical
hurdles to having the bibliography file specified in the text. The markdown
reader itself can't do IO, so it can't read the file. So we can't read the
bibliography (or even verify that it can be found) until we've parsed the
markdown source. That means that we can't check potential citations as we
parse, to see if they're in the bibliography; instead, we have to parse
everything that might be a citation as a citation. But what if we have a
citation with id "foo" (from "@foo" in the text), but the bibliography
contains no corresponding item? Then we need to reinsert the literal text.
It's easy enough to generate "@foo" from a Cite inline, but what if the Cite
was generated by parsing latex + bibtex? This gets complicated.

I did think of one solution, which I'd like to get Andrea's feedback on (as
it might require citeproc changes). Currently when we parse a citation, we
just leave the [Inline] part empty; this gets filled in by citeproc when it
processes the citations with the bibliography.

My suggestion: instead of leaving it empty, fill in the [Inline] part of the
Cite with the literal text that should be included in the document if the
citation isn't found in the database. This way, if citeproc doesn't find the
item, it can simply leave the Cite alone (rather than raising an error). That
seems simple; it just adds a bit of complexity to the parsers, which have to
generate the "replacement text" when they parse a Cite.

Thoughts?

John


  parent reply	other threads:[~2010-12-01  3:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-21 19:32 John MacFarlane
     [not found] ` <20101121193229.GB25657-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-21 21:46   ` Bruce
     [not found]     ` <0ebd5c02-7660-4f20-8da0-ee93a034850a-bhUrjG+0PUy4o898BNfOI1YGCWtFR9XvQQ4Iyu8u01E@public.gmane.org>
2010-11-22 16:02       ` Nathan Gass
     [not found]         ` <4CEA93FE.8070502-8UOIJiGH10pyDzI6CaY1VQ@public.gmane.org>
2010-11-22 16:36           ` John MacFarlane
2010-11-21 23:26   ` Tillmann Rendel
     [not found]     ` <4CE9AABB.1070705-jNDFPZUTrfTbB13WlS47k8u21/r88PR+s0AfqQuZ5sE@public.gmane.org>
2010-11-24  1:29       ` Nathan Gass
     [not found]         ` <4CEC6A61.1000309-8UOIJiGH10pyDzI6CaY1VQ@public.gmane.org>
2010-11-24  3:33           ` John MacFarlane
     [not found]             ` <20101124033315.GC25133-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-24  5:06               ` John MacFarlane
     [not found]                 ` <20101124050631.GA28014-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-24 20:51                   ` Andrea Rossato
     [not found]                     ` <20101124205114.GB23284-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org>
2010-11-25  7:42                       ` John MacFarlane
     [not found]                         ` <20101125074240.GC12387-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-25  8:09                           ` Andrea Rossato
     [not found]                             ` <20101125080907.GD23284-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org>
2010-11-27 15:23                               ` John MacFarlane
     [not found]                                 ` <20101127152352.GB535-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-27 19:01                                   ` Andrea Rossato
     [not found]                                     ` <20101127190139.GE32527-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org>
2010-11-27 19:34                                       ` John MacFarlane
2010-11-29 23:45                   ` Nathan Gass
     [not found]                     ` <4CF43B30.9050400-8UOIJiGH10pyDzI6CaY1VQ@public.gmane.org>
2010-12-01  3:25                       ` John MacFarlane [this message]
     [not found]                         ` <20101201032556.GA28952-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-12-01 13:03                           ` Andrea Rossato
     [not found]                             ` <20101201130317.GI10338-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org>
2010-12-01 16:00                               ` John MacFarlane
     [not found]                                 ` <20101201160037.GC3038-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2017-07-27  8:18                                   ` siram.berlin-Re5JQEeQqe8AvxtiuMwx3w
     [not found]                                     ` <9802cbc1-fa98-43f9-b42b-b7781066f375-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2017-07-30 20:57                                       ` John MacFarlane
2020-11-19 13:14                                       ` Pranesh Prakash
     [not found]                                         ` <19e3868a-6e4e-42a3-8636-75a95e925946n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-11-20  8:50                                           ` AW: " denis.maier-FfwAq0itz3ofv37vnLkPlQ
2010-11-22 23:21   ` Andrea Rossato
     [not found]     ` <20101122232135.GG13438-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org>
2010-11-23  6:30       ` John MacFarlane
     [not found]         ` <20101123063011.GD8500-nFAEphtLEs+AA6luYCgp0U1S2cYJDpTV9nwVQlTi/Pw@public.gmane.org>
2010-11-23 10:04           ` Nathan Gass
     [not found]             ` <4CEB91AA.5050801-8UOIJiGH10pyDzI6CaY1VQ@public.gmane.org>
2010-11-23 15:58               ` John MacFarlane
2010-11-23 18:39               ` Bruce
     [not found]                 ` <68cb6920-d51b-4139-913b-4ca4e96e160c-LFpOzkg5VSKSsatCSt0dimB/v6IoIuQBVpNB7YpNyf8@public.gmane.org>
2010-11-23 19:02                   ` John MacFarlane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101201032556.GA28952@protagoras.phil.berkeley.edu \
    --to=fiddlosopher-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).