From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/433 Path: news.gmane.org!not-for-mail From: John MacFarlane Newsgroups: gmane.text.pandoc Subject: Re: textual citation Date: Sat, 13 Nov 2010 08:27:02 -0800 Message-ID: <20101113162702.GC1212@protagoras.phil.berkeley.edu> References: <20101111014927.GP24988@eeepc.istitutocolli.org> <20101112063622.GA8676@protagoras.phil.berkeley.edu> <20101112084314.GA15038@protagoras.phil.berkeley.edu> <20101113011105.GJ19143@eeepc.istitutocolli.org> <20101113033806.GA27595@protagoras.phil.berkeley.edu> <20101113131538.GO19143@eeepc.istitutocolli.org> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1289665780 24580 80.91.229.12 (13 Nov 2010 16:29:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 13 Nov 2010 16:29:40 +0000 (UTC) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-X-From: pandoc-discuss+bncCO38oIeaEBDm-frmBBoEz5DaqQ-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sat Nov 13 17:29:36 2010 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane.org Original-Received: from mail-pz0-f58.google.com ([209.85.210.58]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PHIys-0005Rc-Sd for gtp-pandoc-discuss@m.gmane.org; Sat, 13 Nov 2010 17:29:35 +0100 Original-Received: by pzk27 with SMTP id 27sf1535805pzk.3 for ; Sat, 13 Nov 2010 08:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:received:date:from:to:subject :message-id:references:mime-version:in-reply-to:x-pgp-key:user-agent :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type :content-disposition:content-transfer-encoding; bh=qGdkGtTJGEpalo9Iyv9+9Co9Ss0adVXFnFYUK737vAs=; b=G+Somj/sXIKEIsfsn+vCDlibN3oBLzh09EV7DYPLn4V9EZm9bS7uqChnUKwGDitek7 zodECka5wgoMHA5idc4HSVExtnpF9wgtBxw9EmXoYGXvg/TUqzSLKdGdORnuqaZDzjlw 1fBJxPQRhO35ofLwhI9V2t7zIFrXWMeXAZtK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:date:from:to:subject:message-id:references :mime-version:in-reply-to:x-pgp-key:user-agent:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type:content-disposition :content-transfer-encoding; b=zHCDNVdt/XuJZ6BVbCS6S+uGBC7Uek9syaD/s2fjK0//DPtAWgEMUTDoLzRXsU88xR xtCutvSVrrmh2+i1TG6VRmaeCK1KtpWLqjLOc6jYwMnSad+pkpxisjaKybRpJa3TqAmd Uh68gFp+m3AmmHdeUDWpTNsgy3bprgsLaPgok= Original-Received: by 10.142.65.4 with SMTP id n4mr88806wfa.54.1289665766141; Sat, 13 Nov 2010 08:29:26 -0800 (PST) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 10.142.6.9 with SMTP id 9ls5695260wff.3.p; Sat, 13 Nov 2010 08:29:25 -0800 (PST) Original-Received: by 10.142.210.2 with SMTP id i2mr2264207wfg.45.1289665765482; Sat, 13 Nov 2010 08:29:25 -0800 (PST) Original-Received: by 10.142.210.2 with SMTP id i2mr2264206wfg.45.1289665765463; Sat, 13 Nov 2010 08:29:25 -0800 (PST) Original-Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by gmr-mx.google.com with ESMTP id y8si7477983wfj.1.2010.11.13.08.29.25; Sat, 13 Nov 2010 08:29:25 -0800 (PST) Received-SPF: pass (google.com: domain of jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org designates 169.229.218.143 as permitted sender) client-ip=169.229.218.143; Original-Received: from protagoras.phil.berkeley.edu ([128.32.137.142]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (auth plain:jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org) (envelope-from ) id 1PHIyi-00024g-7K for pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; Sat, 13 Nov 2010 08:29:25 -0800 Original-Received: by protagoras.phil.berkeley.edu (Postfix, from userid 1000) id 58DD1131777; Sat, 13 Nov 2010 08:27:02 -0800 (PST) In-Reply-To: <20101113131538.GO19143-j4W6CDmL7uNdAaE8spi6tJZpQXiuRcL9@public.gmane.org> X-PGP-Key: http://johnmacfarlane.net/jgm.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Original-Sender: fiddlosopher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org designates 169.229.218.143 as permitted sender) smtp.mail=jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: List-Post: , List-Help: , List-Archive: Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Subscribe: , List-Unsubscribe: , Content-Disposition: inline Xref: news.gmane.org gmane.text.pandoc:433 Archived-At: +++ Andrea Rossato [Nov 13 10 14:15 ]: > On Fri, Nov 12, 2010 at 07:38:06PM -0800, John MacFarlane wrote: > > A couple of issues: > >=20 > > 1. What to do about nonexistent keys? Currently the parser checks > > keys only when they're in initial in-text position (i.e. not within > > brackets). That's why, in the tests, '@nonexistent' comes across as > > '@nonexistent', while '[@nonexistent]' gives 'Anon. (error)' or somethi= ng like > > that. > >=20 > > Of course, it seems inconsistent to check keys when they don't occur > > within []s, but not when they do. The rationale was this: > >=20 > > * If I don't check keys outside of brackets, we may get things treated > > as citations when they shouldn't be. Maybe this isn't a great concern; > > but then again, people do sometimes use @ at the beginning of a word. > >=20 > > * If I do check all the keys inside of brackets, then there's the > > question what to do if some are found but not others. Do we return > > a Cite, or not? What do we do about the non-found keys? > >=20 > > So I wasn't sure what to do here. >=20 > The citeproc side will check if the citation has a corresponding > bibliographic reference: if not an empty reference with the title set > to "citationId was not found!" is generated. No other variable is set, > this is why you get an "Anon." with the chicago-author-date (the term > is used when the 'author' variable is not set). Maybe some fake but > descriptive author's field should be set too. >=20 > If you run the example with the apa-x.csl style that comes with the > test-suite, you'll see that for: >=20 > [@nonexistent] >=20 > you get: >=20 > (=93nonexistent not found!,=94 nd) >=20 > My opinion is that either we choose never to check or we always check: > either way you have a way of spotting errors. The present > implementation seems a bit confusing to me. >=20 > >=20 > > 2. As we discussed before, I'd like to make prefix and locator have typ= e > > [Inline] rather than String. Is this doable on the citeproc-hs side? > > I think it would have many advantages (and, keeping them as raw strings > > has some disadvantages). >=20 > This is fine for me, even though I think will we have to wrap the > [Inline] in some type before passing it to the processor: >=20 > data Affixes =3D PandocString [Inline] > | PlainString String >=20 > I'd prefer you to parse the suffix (which should be an [Inline]). I > think we should have a single locator between commas: >=20 > [see @item, p. 1, suffix;] >=20 > 'see' and 'suffix' would [Inline], 'p. 1' a string to be passed to > parseLocator. It shouldn't be difficult, is it? How would the parser distinguish the locator from the suffix? Just splitting on commas won't work, because: - sometimes there will be multiple commas in the locator [see @item, pp. 33-35, 38, 250n3] (can citeproc even handle this kind of case?) - sometimes there will be a suffix but no locator [see @item, which was retracted in 2004] I don't see how the parser can reliably separate locator from suffix without knowing e.g. that 'pp.' means 'pages'. And I'd like to keep this kind of locale-specific stuff in citeproc-hs if possible. One possible solution would be to introduce a distinction in punctuation: [prefix @key: locator, suffix] [prefix @key: locator only] [prefix @key, suffix only] But this leaves us with problems in the case where the locator itself contains commas ('pp. 33, 35, 38'). I guess I need to know how citeproc deals with such cases. Another idea would be to have pandoc treat everything as 'suffix', and not use the locator at all. This would have the drawback that style-specific ways of printing the locator (e.g. whether 'pp.' is used for pages) would have no effect. But this is more or less how it works in natbib and biblatex. Any ideas? John --=20 You received this message because you are subscribed to the Google Groups "= pandoc-discuss" group. To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@go= oglegroups.com. For more options, visit this group at http://groups.google.com/group/pandoc= -discuss?hl=3Den.