From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vaidheeswaran Subject: Re: Citation syntax and ODT Date: Mon, 23 Feb 2015 11:52:18 +0530 Message-ID: <54EAC71A.6080502@gmail.com> References: <87zj85s1vf.fsf@berkeley.edu> Reply-To: vaidheeswaran.chinnaraju@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPmNM-0003GN-JP for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 01:20:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPmNJ-0005P5-CL for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 01:20:16 -0500 Received: from mail-pd0-x233.google.com ([2607:f8b0:400e:c02::233]:35577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPmNJ-0005Ox-0s for emacs-orgmode@gnu.org; Mon, 23 Feb 2015 01:20:13 -0500 Received: by pdbfl12 with SMTP id fl12so23121136pdb.2 for ; Sun, 22 Feb 2015 22:20:11 -0800 (PST) In-Reply-To: <87zj85s1vf.fsf@berkeley.edu> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Richard Lawrence Cc: emacs-orgmode@gnu.org On Monday 23 February 2015 09:41 AM, Richard Lawrence wrote: > Hi Vaidheeswaran, > > Thanks for your input about citations! > > Vaidheeswaran writes: > >> Those working on the citation syntax should make it clear that the >> "lowest common" cite syntax does NOT also IMPOSE (or GUARANTEE) a >> specific style on the produced document. >> >> When I say this, I specifically mean: >> >> 1. I want my citation and references to be carried over FAITHFULLY to >> the exported document. >> >> 2. I DON'T CARE how (1) is styled. > > I'm afraid I don't quite understand your concern here. What does it > mean to export a citation faithfully, but without imposing a particular > style (or without giving it any specific formatting properties)? > > My understanding (based on the LaTeX world) is that a `style' defines a > broad set of conventions for formatting citations and bibliographies in > the output document. For example, a style might define citations to be > author-year, or numerical. Within a style, individual citations can > still have different formatting properties, such as whether it appears > inside parentheses or not. User: I want 'Style Newyork'. ODT/Jabref: I don't have 'Style Newyork'. I can give you 'Style Chicago'. It is all that I have. > We haven't really discussed how styles should be specified (yet), or the > formatting of bibliographies. But we have been discussing a syntax that > lets you specify those formatting properties which commonly differ > between individual citations. IMO, it is better to roll out the citation feature WITHOUT any formatting properties. The specific formatting chosen is at the mercy of capabilities of the export backend or citation engine it works with. >> ---------------------------------------------------------------- >> >> The above observations would translate to: >> >> The Cite object in it's SIMPLEST form specifies just a citekey (or a >> set of citekeys). The Cite-object is qualified with a footnote saying >> that any key-value pair -- including "type" -- that is specified with >> Cite object MAY BE IGNORED by a backend. >> > > If I understand what you're saying here correctly, I think this is too > little to expect. If *all* the formatting information in a citation can > be ignored by any backend, there isn't very much to be gained by having > a citation syntax in Org. In Network protocols, the client and server can negotiate the parameters of a service. The actual service is at the intersection of client and server capabilities. The RFC itself states what every compliant client and server implementation should provide at the minimum. i.e., There is a basic service which is guaranteed. In our specific case, a backend like ODT will guarantee a readable and well-styled document limited from among the choice of styles that the citation engine -- for eg., Jabref -- itself supports. The document so produced may not be acceptable to a publishing house (Focus here is on a specific style). Neverthless, document will be respectable enough to be circulated among peers (for a review) or distributable to wider public (Focus here is on content rather than SPECIFIC style). >> ---------------------------------------------------------------- >> Note that I am not speaking against Bells and Whistles. I am only >> saying that Bells and Whistles MUST NOT be imposed upon a backend like >> ODT where the available tools are NOT AS RICH OR AS MATURE AS that >> available with other backends like HTML or LaTeX. > > I don't really know anything about ODT. In particular, I don't know if > ODT makes room for a distinction between the overall citation style and > the formatting properties of individual citations. Can you say a bit > more about what you think its limitations are? > Obviously, we can't impose anything on the formatting of citations which > the output document format is incapable of expressing. But I can't > think of anything we've discussed for the main syntax that seems likely > to be inexpressible in ODT. The question is not about expressibility. The question is about what is expressible using the current set of tools that are available off-the-shelf. Do you think of a scenario where: 1. Org acts like a citation engine. (A self-contained Org-ecosystem) 2. Org-backends interfaces with a 3rd-party engine (like pandoc, zotero, JabRef) If the current effort is to build (1), ODT backend will have no reason to complain. If the effort is geared more towards (2), the ground reality is that JabRef's style catalog is not as extensive or mature as, say Zotero's or LaTeXs. The implication is that the PDF document produced via the LaTeX document WILL DIFFER IN STYLE from the PDF document produced via the ODT backend. I am imagining something along a mix of (1) and (2), with more initial thrust in favor of (2). > Have you had a chance to read the proposal that I sent around last > weekend? Are there specific features of the main syntax described there > (ignoring the `%%(...)' part, which it now appears will be dropped) that > you don't think ODT or other backends can support? If so, I think that > is a concern, and should be discussed. Let me state my position this way: There was a recent thread (see http://lists.gnu.org/archive/html/emacs-orgmode/2015-02/msg00650.html) where a user was having a specific expectation on the ODT engine dictated by his own (extensive) experience with LaTeX. Since the ODT engine, behaved differently, he concluded that "ODT engine was fragile". I am not faulting the user's remarks. I am only saying that the people who work on the specification take sufficient care to TEMPER what a user can reasonably expect when he moves between different backends. My primary motivation is to draw the attention of people like you (who are hammering out the syntax) to factor the case of a backend-like ODT. ---------------------------------------------------------------- That said, Why don't you give us an example an Org-file that uses the new syntax in it's more BARE MINIMAL FORM (together with it's accompanying .bib file). I will pass it via the existing ODT/JabRef backend and circulate the resulting ODT file to the list. We can use THIS specific Org-file as an use-case to think through what each of us are arguing for and against. My focus in not so much on syntax-richness but on quick roll-out of citation support. I have been in this list mostly as a lurker for a long time. The citation proposal never gained much traction as much as it is seen right now. More importantly I see Nicolas willing to make the necessary modifications to export engine. My only suggestion is to MERELY TO TAKE COGNIZANCE of the need for bells-and-whistles without the current momentum being dragged down by an attempt to arrive at a consensus that will keep all parties happy.