Back Table of contents Index Next   BibTool Manual
Reference Manual
Format Specification
Example

Example

To end this section we should have a look at a complete example of key generation specification. For this purpose we define a rule according to which the keys should be generated:

  1. If a field named bibkey is present then the value of this field should be used.
  2. If the type of the entry is a book then the authors/editors are used followed by the year separated by a colon.
  3. If the type of the entry is an article in a journal ( article) then the author, the journal, the number, and the year should be used. Author and journal should be separated by a colon, The journal should be abbreviated with the initials and separated from number and year by a period.
  4. If the type of the entry is a volume of conference proceedings (proceedings) then the editor, the first 5 initials of the title and the year should be used. The editor should be followed by a colon and the year preceded by a period.
  5. If the type of the entry is a contribution in conference proceedings then the author, the initials of the book title and the year should be used.
  6. Otherwise the first three letters of the type, the author and the year should be used. If no author is given then the initials of the title should be used instead---but at most 6 characters.
The names should include up to two names abbreviated to four letters and should be translated to lower case. If an information is missing then the respective part together with the following separator should be omitted.

The disambiguation should be done by appending upper case letters without a preceding string. If everything else fails three question marks should be inserted as key.

To implement this scheme we write the following specification into a resource file:

key.expand.macros = on
key.base = upper
key.number.separator = {}
key.format =
{
    %s(bibkey)
  #
    %0w(@book)
    { %-2.4n(author): # %-2.4n(editor): # }
    { %4d(year)       # }
  #
    %0w(@article)
    { %-2.4n(author): # }
    { %-.1W(journal). # }
    { %4d(year)       # }
  #
    %0w(@proceedings)
    { %-2.4n(editor): # }
    { %-.1W(title).   # %-.1W(booktitle). # }
    { %4d(year)       # }
  #
    %0w(@inproceedings)
    { %-2.4n(author):   # }
    { %-.1W(booktitle). # }
    { %4d(year)         # }
  #
    %3s($type)-
    { %-2.4n(author):
    # %-6.1W(title).
    }
    {%4d(year) # }
  #
    %3s($type)-
    %4d(year)
  # ???
}
Since each part has been explained before we just need some overall remarks. I prefer to use the backtracking-based disjunctions instead of nested if-then-else constructs because they save some braces. They can be read as a switch statement, or even better as a cond statement in Lisp. This means they describe cases. The first successful case terminates the evaluation of the whole cascade.

The constructions like %0w(@book) are use to distinguish the different types. This construction does not produce any output. It just succeeds or fails depending on the type of the current entry. The %0w could also be replaced by other specifiers which serve the same purpose.

The constructions like {%4d(year) # } always succeed. The hash sign (#) catches the failure and inserts the second alternative---which happens to be empty---if the requested field does not exist.



Back Table of contents Index Next   BibTool Manual
Reference Manual
Format Specification
Example
© 1999 Gerd Neugebauer