ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>,
	Rik Kabel <context@rik.users.panix.com>
Subject: Re: Bibliography in MKIV, custom rendering
Date: Sun, 13 Aug 2017 09:34:57 +0200	[thread overview]
Message-ID: <5b4f9e3a-9d5d-cb2b-b323-5dea965e5fbe@wxs.nl> (raw)
In-Reply-To: <ddb89860-5cf8-55e3-6dde-ea37abe00766@rik.users.panix.com>

On 8/13/2017 5:13 AM, Rik Kabel wrote:
> On 2017-08-12 22:38, Alan Braslau wrote:
>> On Fri, 11 Aug 2017 14:58:53 -0400
>> Rik Kabel <context@rik.users.panix.com> wrote:
>>
>>> The lack of either an author or an editor is currently flagged in
>>> ConTeXt as an error for books and perhaps other bibtex entry types as
>>> well. Or do you mean to apply this recommendation to only the
>>> electronic type or some other limited subset of types?
>> This will be corrected for types other than electronic when I look into
>> a consistent set.
>>
>>> Perhaps it is better to use the association name as an author and
>>> protect it with a layer of curlies or quotation marks, as {{Apple,
>>> Inc.}}, "{Apple, Inc.}", or '{Apple, Inc.}', any one of which will do
>>> the job and also serve to prevent what would surely be unwanted
>>> abbreviation for styles that abbreviate what are parsed as given
>>> names.
>> This won't happen. We made a design choice not to follow such sloppy
>> bibtex/LaTeX use and to require clean datasets. Apple Inc. is NOT a
>> named author, it is an organization, and the APA specification is clear
>> about this (it even has screwy rules about the first citation and then
>> the following when one should abbreviate names [such as APA]). Of
>> course, the specifications have to be fixed to handle this correctly
>> and consistently, also trying to be consistent with the fields that are
>> defined by the original bibtex documentation and followed by many
>> bibtex manipulating tools (such as jabref). The problem is that the use
>> of bibtex in the real world is a big mess!
>>
>> ALan
> 
> So organization will simply become a stand-in for author but with 
> different parsing rules. A book will require an author or editor or 
> organization. The first two will be parsed for surname, given name, and 
> so on, while the last will not, and precedence rules will apply when 
> more than one is present, as they do already.
> 
> But until that point, as Hans said, using the author field and 
> protecting it with curlies will work.
> 
> How will other screwy rules be handled? Will there be an override 
> mechanism, or is it your belief that a compliant subsystem can be 
> developed? (Yes, I know that is a false dichotomy.)
there is actually a concept of field sets and a lookup order

concerning authors, there are many issues there: upto 6 snippets and the 
number determines what is expected (mostly inherited from the mess but 
we added some in order to deal with complex combinations of names)

also, keep in mind that there's more than english names

all revealed in the manual (and we wil make some demos)

as one can export one can also easily generate one's one variant of the 
database for whatever purpose

(another nightmare is embedded tex: absolutely not standardized and a 
pain when trying to collapse and sort)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2017-08-13  7:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 14:01 Alan Braslau
2017-08-11 18:58 ` Rik Kabel
2017-08-12  8:54   ` Hans Hagen
2017-08-12 15:28     ` Rik Kabel
2017-08-12 15:48       ` Rik Kabel
2017-08-12 16:10         ` Hans Hagen
2017-08-13  2:38   ` Alan Braslau
2017-08-13  3:13     ` Rik Kabel
2017-08-13  7:34       ` Hans Hagen [this message]
2017-08-14  2:50       ` Alan Braslau
  -- strict thread matches above, loose matches on Subject: below --
2017-07-31  2:23 Gerion Entrup
2017-07-31 19:28 ` Gerion Entrup
2017-08-01 14:26   ` Hans Hagen

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=5b4f9e3a-9d5d-cb2b-b323-5dea965e5fbe@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=context@rik.users.panix.com \
    --cc=ntg-context@ntg.nl \
    /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).