Re: pandoc/citeproc issues: multiple bibliographies, nocite, citeonly

[John MacFarlane <fiddlosopher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

+++ Andrea Rossato [Nov 25 10 09:09 ]:
> On Wed, Nov 24, 2010 at 11:42:40PM -0800, John MacFarlane wrote:
> > +++ Andrea Rossato [Nov 24 10 21:51 ]:
> > > Can we do it now? If no I'm not going to work on the citeproc side any
> > > longer for the time being.
> > 
> > There's at least one thing that needs to be done anyway -- the
> > spacing issue between multiple locators.  (See the failing
> > tests when you do 'make test'.)
> 
> I mean that I'm not going to work on this specific issue anymore (I'll
> leave it for the next release), to concentrate on the remaining issues
> (page ranges, which involves also the problem you reported, style
> version recognition, rich text formatting and flip-flopping, etc.).
> 
> > > For the syntax: I like the xml syntax you proposed.
> > 
> > I'm a bit uncertain how to proceed, because the xml syntax seems
> > unpopular (judging from responses on the list), and I don't have
> > a good alternative in mind.
> > 
> > Also, I'm not *sure* that the select/include/exclude/quash system
> > is the best way to go on filtering.  It works pretty well with
> > the xml syntax, but less well with some of the other options.
> > 
> > Hence the temptation to avoid solving all these problems and
> > just release something workable. But let me think on it some more.
> 
> If you want to wait I have no objections. Still I would like to change
> the type signature of citeproc to include the ProcOpts parameter, so
> that we don't need to change it at a latter time.
> 
> Related to that: in pandoc.cabal the citeproc-hs dependency has been
> set to:
> 
> citeproc-hs >= 0.3 && < 0.4
> 
> Do we want to drop the upper bound?

I think these upper bounds are generally a good idea.  This way you
can release a new version of citeproc-hs with an incompatible API,
and pandoc will still build.

I was looking a bit at the code in citeproc that parses locators.

    parseLocator :: String -> (String, String)
    parseLocator s
        | "b"    `isPrefixOf` formatField s = mk "book"
        | "ch"   `isPrefixOf` formatField s = mk "chapter"
        | "co"   `isPrefixOf` formatField s = mk "column"
        | "fi"   `isPrefixOf` formatField s = mk "figure"
        | "fo"   `isPrefixOf` formatField s = mk "folio"
        | "i"    `isPrefixOf` formatField s = mk "issue"
        | "l"    `isPrefixOf` formatField s = mk "line"
        | "n"    `isPrefixOf` formatField s = mk "note"
        | "o"    `isPrefixOf` formatField s = mk "opus"
        | "para" `isPrefixOf` formatField s = mk "paragraph"
        | "part" `isPrefixOf` formatField s = mk "part"
        | "p"    `isPrefixOf` formatField s = mk "page"
        | "sec"  `isPrefixOf` formatField s = mk "section"
        | "sub"  `isPrefixOf` formatField s = mk "sub verbo"
        | "ve"   `isPrefixOf` formatField s = mk "verse"
        | "v"    `isPrefixOf` formatField s = mk "volume"
        | otherwise                         =    ([], [])
        where
          mk c = if null s then ([], []) else (,) c . concat . tail . words $ s

Am I right that this will work for English and Italian, but not
Swedish and Chinese? Is there a way to localize this and make it less
language-centric?

John