Open main menu

Changes

no edit summary
 
=1 The data­base=
</pre>
this gives:
tagcat­e­goryfieldsdemo{| |+  | tag| | cat­e­gory| | fields| |+  | demo-001bookau­thor 001| | book| | au­thor in­dex ti­tle yeardemoyear| |+  | demo-002bookcross­ref 002| | book| | cross­ref in­dex yeardemoyear| |+  | demo-003bookau­thor 003| | book| | au­thor com­ment in­dex ti­tle yeardemoyear| |+  | demo-004bookau­thor 004| | book| | au­thor com­ment in­dex ti­tle yeardemoyear| |+  | demo-005bookau­thor 005| | book| | au­thor doi in­dex pages se­r­ial ti­tle url year | |}
You can set the cur­rent ac­tive dataset with
<pre detail='typing'>
Ex­am­ples of list vari­ants are:
<tt>setupbtxlistvariant : artauthor</tt> {| |+  | <tt>no specific settings</tt> | |  | |} <tt>setupbtxlistvariant : author</tt> {| |+  | <tt>no specific settings</tt> | |  | |} <tt>setupbtxlistvariant : editor</tt> {| |+  | <tt>no specific settings</tt> | |  | |}
The ex­act ren­der­ing of list en­tries is de­ter­mined by the <tt>alternative</tt> key and de­faults to <tt>apa</tt> which uses de­f­i­n­i­tions from <tt>publ-imp-apa.mkiv</tt> . If you look at that file you will see that each cat­e­gory has its own setup. You may also no­tice that ad­di­tional tests are needed to make sure that empty fields don’t trig­ger sep­a­ra­tors and such.
There are three com­mands to flush data:
{| |+  | <tt>\btxfield</tt> | | fetch a ex­plicit field (e.g. <tt>year</tt> ) | |+  | <tt>\btxdetail</tt> | | fetch a de­rived field (e.g. <tt>short</tt> ) | |+  | <tt>\btxflush</tt> | | fetch a de­rived or ex­plicit field | |}
Nor­mally you can use <tt>\btxfield</tt> or <tt>\btxflush</tt> as de­rived fields just like an­a­lyzed au­thor fields are flushed in a spe­cial way.
</pre>
Keep in mind that nor­mally you don’t need to mess with de­f­i­n­i­tions like this be­cause stan­dard ren­der­ing styles are pro­vided. These styles use a few helpers that in­ject sym­bols but also take care of lead­ing and trail­ing spaces:
{| |+  | <tt>\btxspace</tt> | | be­fore af­ter | |+  | <tt>\btxperiod</tt> | | be­fore. af­ter | |+  | <tt>\btxcomma</tt> | | be­fore, af­ter | |+  | <tt>\btxlparent</tt> | | be­fore (af­ter | |+  | <tt>\btxrparent</tt> | | be­fore) af­ter | |+  | <tt>\btxlbracket</tt> | | be­fore [af­ter | |+  | <tt>\btxrbracket</tt> | | be­fore] af­ter | |}
So, the pre­vi­ous ex­am­ple setup can be rewrit­ten as:
<pre detail='typing'>
</pre>
You can use a (con­fig­urable) de­fault or pass di­rec­tives: Valid di­rec­tives are
con­ver­sionren­der­ing {| |+  | con­ver­sion| | ren­der­ing| |+  | <tt>inverted</tt> | | the Frog jr, Ker­mit | |+  | <tt>invertedshort</tt> | | the Frog jr, K | |+  | <tt>normal</tt> | | Ker­mit, the Frog, jr | |+  | <tt>normalshort</tt> | | K, the Frog, jr| |} 
=5 Ci­ta­tions=
</pre>
There is a whole bunch of cite op­tions and more can be eas­ily de­fined.
keyren­der­ing {| |+  | key| | ren­der­ing| |+  | <tt>author</tt> | | (au­thor) | |+  | <tt>authornum</tt> | | [au­thor [btx er­ror 1]] | |+  | <tt>authoryear</tt> | | (au­thor (year)) | |+  | <tt>authoryears</tt> | | (au­thor, year) | |+  | <tt>doi</tt> | | [todo: doi] | |+  | <tt>key</tt> | | [demo-005] | |+  | <tt>none</tt> | |  | |+  | <tt>num</tt> | | [[btx er­ror 1]] | |+  | <tt>page</tt> | | pages | |+  | <tt>serial</tt> | | [5] | |+  | <tt>short</tt> | | [aut00] | |+  | <tt>type</tt> | | [book] | |+  | <tt>url</tt> | | [todo: url] | |+  | <tt>year</tt> | | (year) | |}
Be­cause we are deal­ing with data­base in­put and be­cause we gen­er­ally need to ma­nip­u­late en­tries, much of the work is del­e­gated to Lua . This makes it eas­ier to main­tain and ex­tend the code. Of course TEX still does the ren­der­ing. The ty­po­graphic de­tails are con­trolled by pa­ra­me­ters but not all are used in all vari­ants. As with most ConTEXt com­mands, it starts out with a gen­eral setup com­mand:
On top of that we can de­fine in­stances that in­herit ei­ther from a given par­ent or from the top­most setup.
But, spe­cific vari­ants can have them over­loaded:
<tt>setupbtxcitevariant : author</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>)</tt>
|
 
|+
 
|
<tt>middle</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>(</tt>
|
 
|}
<tt>setupbtxcitevariant : authornum</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>middle</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : authoryear</tt>
{|
 
|+
 
|
<tt>compress</tt>
|
 
|
<tt>yes</tt>
|
 
|+
 
|
<tt>inbetween</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>)</tt>
|
 
|+
 
|
<tt>middle</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>(</tt>
|
 
|}
<tt>setupbtxcitevariant : authoryears</tt>
{|
 
|+
 
|
<tt>compress</tt>
|
 
|
<tt>yes</tt>
|
 
|+
 
|
<tt>inbetween</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>)</tt>
|
 
|+
 
|
<tt>middle</tt>
|
 
|
<tt>, </tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>(</tt>
|
 
|}
<tt>setupbtxcitevariant : doi</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : key</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : none</tt>
{|
 
|+
 
|
<tt>no specific settings</tt>
|
 
|
 
|
 
|}
<tt>setupbtxcitevariant : num</tt>
{|
 
|+
 
|
<tt>compress</tt>
|
 
|
<tt>yes</tt>
|
 
|+
 
|
<tt>inbetween</tt>
|
 
|
<tt>--</tt>
|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : page</tt>
{|
 
|+
 
|
<tt>inbetween</tt>
|
 
|
<tt>–</tt>
|
 
|}
<tt>setupbtxcitevariant : serial</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : short</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : type</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : url</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>]</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>[</tt>
|
 
|}
<tt>setupbtxcitevariant : year</tt>
{|
 
|+
 
|
<tt>right</tt>
|
 
|
<tt>)</tt>
|
 
|+
 
|
<tt>left</tt>
|
 
|
<tt>(</tt>
|
 
|}
A ci­ta­tion vari­ant is de­fined in sev­eral steps and if you re­ally want to know the dirty de­tails, you should look into the <tt>publ-imp-*.mkiv</tt> files. Here we stick to the con­cept.
<pre detail='typing'>
\startsetups btx:cite:author
\btxcitevariant{author}
\stopsetups
</pre>
You can over­load such se­tups if needed, but that only makes sense when you can­not con­fig­ure the ren­der­ing with pa­ra­me­ters. The <tt>\btxcitevariant</tt> com­mand is one of the build in ac­ces­sors and it calls out to Lua where more com­plex ma­nip­u­la­tion takes place if needed. If no ma­nip­u­la­tion is known, the field with the same name (if found) will be flushed. A com­mand like <tt>\btxcitevariant</tt> as­sumes that a dataset and spe­cific tag has been set. This is nor­mally done in the wrap­per macros, like <tt>\cite</tt> . For spe­cial pur­poses you can use these com­mands
<pre detail='typing'>
\setbtxdataset[example]
\setbtxentry[hh2013]
</pre>
But don’t ex­pect too much sup­port for such low level ren­der­ing con­trol.
Un­less you use <tt>criterium=all</tt> only pub­li­ca­tions that are cited will end up in the lists. You can force a ci­ta­tion into a list us­ing <tt>\usecitation</tt> , for ex­am­ple:
<pre detail='typing'>
\usecitation[example::demo-004,demo-003]
</pre>
This com­mand has two syn­onyms: <tt>\nocite</tt> and <tt>\nocitation</tt> so you can choose what­ever fits you best.
=6 The LUA view=
 
Be­cause we man­age data at the Lua end it is tempt­ing to ac­cess it there for other pur­poses. This is fine as long as you keep in mind that as­pects of the im­ple­men­ta­tion may change over time, al­though this is un­likely once the mod­ules be­come sta­ble.
The en­tries are col­lected in datasets and each set has a unique name. In this doc­u­ment we have the set named <tt>example</tt> . A dataset ta­ble has sev­eral fields, and prob­a­bly the one of most in­ter­est is the <tt>luadata</tt> field. Each en­try in this ta­ble de­scribes a pub­li­ca­tion:
<pre detail='typing'>
t={
["author"]="Hans Hagen",
["category"]="book",
["index"]=1,
["tag"]="demo-001",
["title"]="\\btxcmd{BIBTEX}, the \\btxcmd{CONTEXT}\\ way",
["year"]="2013",
}
</pre>
This is <tt>publications.datasets.example.luadata["demo-001"]</tt> . There can be a com­pan­ion en­try in the par­al­lel <tt>details</tt> ta­ble.
<pre detail='typing'>
t={
["author"]={
{
["firstnames"]={ "Hans" },
["initials"]={ "H" },
["original"]="Hans Hagen",
["surnames"]={ "Hagen" },
["vons"]={},
},
},
["short"]="Hag13",
}
</pre>
These de­tails are ac­cessed as <tt>publications.datasets.example.details["demo-001"]</tt> and by us­ing a sep­a­rate ta­ble we can over­load fields in the orig­i­nal en­try with­out los­ing the orig­i­nal.
You can loop over the en­tries us­ing reg­u­lar Lua code com­bined with MkIV helpers:
<pre detail='buffer'>
local dataset = publications.datasets.example
</pre>context.starttabulate { "|l|l|l|" }
for tag, entry in table.sortedhash(dataset.luadata) do
local detail = dataset.details[tag] or { }
context.NC() context.type(tag)
context.NC() context(detail.short)
context.NC() context(entry.title)
context.NC() context.NR()
end
context.stoptabulate()
This re­sults in:
{|
 
|+
 
|
<tt>demo-001</tt>
|
 
|
Hag13
|
 
|
bibTEX , the ConTEXt way
|
 
|+
 
|
<tt>demo-002</tt>
|
 
|
Hag14
|
 
|
bibTEX , the ConTEXt way
|
 
|+
 
|
<tt>demo-003</tt>
|
 
|
HO96
|
 
|
Type­set­ting ed­u­ca­tion doc­u­ments
|
 
|+
 
|
<tt>demo-004</tt>
|
 
|
Sca21
|
 
|
De­sign­ing high speed trains
|
 
|+
 
|
<tt>demo-005</tt>
|
 
|
aut00
|
 
|
ti­tle
|
 
|}
 
=7 The XML view=
 
The <tt>luadata</tt> ta­ble can be con­verted into an xml rep­re­sen­ta­tion. This is a fol­low up on ear­lier ex­per­i­ments with an xml -only ap­proach. I de­cided in the end to stick to a Lua ap­proach and pro­vide some sim­ple xml sup­port in ad­di­tion.
Once a dataset is ac­ces­si­ble as xml tree, you can use the reg­u­lar <tt>\xml...</tt> com­mands. We start with load­ing a dataset, in this case from just one file.
<pre detail='buffer'>
\usebtxdataset[tugboat][tugboat.bib]
</pre>
The dataset has to be con­verted to xml :
<pre detail='buffer'>
\convertbtxdatasettoxml[tugboat]
</pre>
The tree is now ac­ces­si­ble by its root ref­er­ence <tt>btx:tugboat</tt> . If we want sim­ple field ac­cess we can use a few se­tups:
<pre detail='buffer'>
\startxmlsetups btx:initialize
\xmlsetsetup{#1}{bibtex|entry|field}{btx:*}
\xmlmain{#1}
\stopxmlsetups
</pre>\startxmlsetups btx:field
\xmlflushcontext{#1}
\stopxmlsetups
\xmlsetup{btx:tugboat}{btx:initialize}
The two se­tups are pre­de­fined in the core al­ready, but you might want to change them. They are ap­plied in for in­stance:
<pre detail='buffer'>
\starttabulate[|||]
\NC \type {tag} \NC \xmlfirst {btx:tugboat}
{/bibtex/entry[string.find(@tag,'Hagen')]/attribute('tag')}
\NC \NR
\NC \type {title} \NC \xmlfirst {btx:tugboat}
{/bibtex/entry[string.find(@tag,'Hagen')]/field[@name='title']}
\NC \NR
\stoptabulate
</pre>
{|
 
|+
 
|
<tt>tag</tt>
|
 
|
Ha­gen:TB17-1-54
|
 
|+
 
|
<tt>title</tt>
|
 
|
PPCHTEX: type­set­ting chem­i­cal for­mu­las in TEX
|
 
|}
<pre detail='buffer'>
\startxmlsetups btx:demo
\xmlcommand
{#1}
{/bibtex/entry[string.find(@tag,'Hagen')][1]}{btx:table}
\stopxmlsetups
</pre>\startxmlsetups btx:table
\starttabulate[|||]
\NC \type {tag} \NC \xmlatt{#1}{tag} \NC \NR
\NC \type {title} \NC \xmlfirst{#1}{/field[@name='title']} \NC \NR
\stoptabulate
\stopxmlsetups
\xmlsetup{btx:tugboat}{btx:demo}
 
{|
 
|+
 
|
<tt>tag</tt>
|
 
|
Ha­gen:TB17-1-54
|
 
|+
 
|
<tt>title</tt>
|
 
|
PPCHTEX: type­set­ting chem­i­cal for­mu­las in TEX
|
 
|}
Here is an­other ex­am­ple:
<pre detail='buffer'>
\startxmlsetups btx:row
\NC \xmlatt{#1}{tag}
\NC \xmlfirst{#1}{/field[@name='title']}
\NC \NR
\stopxmlsetups
</pre>\startxmlsetups btx:demo
\xmlfilter {#1} {
/bibtex
/entry[@category='article']
/field[@name='author' and (find(text(),'Knuth') or find(text(),'DEK'))]
/../command(btx:row)
}
\stopxmlsetups
\starttabulate[|||]
\xmlsetup{btx:tugboat}{btx:demo}
\stoptabulate
 
{|
 
|+
 
|
Knuth:TB10-1-31
|
 
|
Type­set­ting Con­crete Math­e­mat­ics
|
 
|+
 
|
Knuth:TB10-1-8
|
 
|
TEX would find it dif­fi­cult …
|
 
|+
 
|
Knuth:TB10-3-325
|
 
|
The new ver­sions of TEX and MF
|
 
|+
 
|
Knuth:TB10-4-529
|
 
|
The er­rors of TEX
|
 
|+
 
|
Knuth:TB11-1-13
|
 
|
Vir­tual Fonts: More Fun for Grand Wiz­ards
|
 
|+
 
|
Knuth:TB11-2-165
|
 
|
Ex­er­cises for TEX: The Pro­gram
|
 
|+
 
|
Knuth:TB11-4-489
|
 
|
The fu­ture of TEX and MF
|
 
|+
 
|
Knuth:TB11-4-497
|
 
|
Arthur Lee Samuel, 1901--1990
|
 
|+
 
|
Knuth:TB11-4-499
|
 
|
An­swers to Ex­er­cises for TEX: The Pro­gram
|
 
|+
 
|
Knuth:TB12-2-313
|
 
|
Fixed-point glue set­ting: Er­rata
|
 
|+
 
|
Knuth:TB14-4-387
|
 
|
Icons for TEX and MF
|
 
|+
 
|
Knuth:TB17-1-29
|
 
|
Im­por­tant mes­sage re­gard­ing CM fonts
|
 
|+
 
|
Knuth:TB2-3-5
|
 
|
The cur­rent state of things
|
 
|+
 
|
Knuth:TB3-1-10
|
 
|
Fixed-point glue set­ting­Dash an ex­am­ple of WEB
|
 
|+
 
|
Knuth:TB31-2-121
|
 
|
An Earth­shak­ing An­nounce­ment
|
 
|+
 
|
Knuth:TB4-2-64
|
 
|
A note on hy­phen­ation
|
 
|+
 
|
Knuth:TB5-1-4
|
 
|
TEX in­cunab­ula
|
 
|+
 
|
Knuth:TB5-1-67
|
 
|
Com­ments on qual­ity in pub­lish­ing
|
 
|+
 
|
Knuth:TB5-2-105
|
 
|
A course on MF pro­gram­ming
|
 
|+
 
|
Knuth:TB6-1-36
|
 
|
Recipes and frac­tions
|
 
|+
 
|
Knuth:TB7-2-101
|
 
|
The TEX logo in var­i­ous fonts
|
 
|+
 
|
Knuth:TB7-2-95
|
 
|
Re­marks to cel­e­brate the pub­li­ca­tion of Com­put­ers & Type­set­ting
|
 
|+
 
|
Knuth:TB8-1-14
|
 
|
Mix­ing right-to-left texts with left-to-right texts
|
 
|+
 
|
Knuth:TB8-1-6
|
 
|
It hap­pened: an­nounce­ment of TEX 2.1
|
 
|+
 
|
Knuth:TB8-1-73
|
 
|
Prob­lem for a Sat­ur­day af­ter­noon
|
 
|+
 
|
Knuth:TB8-2-135
|
 
|
Fonts for dig­i­tal halftones
|
 
|+
 
|
Knuth:TB8-2-210
|
 
|
Sat­ur­day morn­ing prob­lem­Dash so­lu­tion
|
 
|+
 
|
Knuth:TB8-2-217
|
 
|
Re­ply: Print­ing out se­lected pages
|
 
|+
 
|
Knuth:TB8-3-309
|
 
|
Macros for Jill
|
 
|+
 
|
Knuth:TB9-2-152
|
 
|
A Punk Meta-Font
|
 
|}
A more ex­ten­sive ex­am­ple is the fol­low­ing. Of course this as­sumes that you know what xml sup­port mech­a­nisms and macros are avail­able.
<pre detail='buffer'>
\startxmlsetups btx:getkeys
\xmladdsortentry{btx}{#1}{\xmlfilter{#1}{/field[@name='author']/text()}}
\xmladdsortentry{btx}{#1}{\xmlfilter{#1}{/field[@name='year' ]/text()}}
\xmladdsortentry{btx}{#1}{\xmlatt{#1}{tag}}
\stopxmlsetups
</pre>\startxmlsetups btx:sorter
\xmlresetsorter{btx}
% \xmlfilter{#1}{entry/command(btx:getkeys)}
\xmlfilter{#1}{
/bibtex
/entry[@category='article']
/field[@name='author' and find(text(),'Knuth')]
/../command(btx:getkeys)}
\xmlsortentries{btx}
\starttabulate[||||]
\xmlflushsorter{btx}{btx:entry:flush}
\stoptabulate
\stopxmlsetups
\startxmlsetups btx:entry:flush
\NC \xmlfilter{#1}{/field[@name='year' ]/context()}
\NC \xmlatt{#1}{tag}
\NC \xmlfilter{#1}{/field[@name='author']/context()}
\NC \NR
\stopxmlsetups
\xmlsetup{btx:tugboat}{btx:sorter}
 
{|
 
|+
 
|
1984
|
 
|
Knuth:TB5-1-67
|
 
|
Don Knuth
|
 
|+
 
|
1984
|
 
|
Knuth:TB5-1-4
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1984
|
 
|
Knuth:TB5-2-105
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1985
|
 
|
Knuth:TB6-1-36
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1986
|
 
|
Knuth:TB7-2-101
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-2-135
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-3-309
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1988
|
 
|
Knuth:TB9-2-152
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1989
|
 
|
Knuth:TB10-3-325
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1989
|
 
|
Knuth:TB10-4-529
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1990
|
 
|
Knuth:TB11-4-489
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1993
|
 
|
Knuth:TB14-4-387
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1996
|
 
|
Knuth:TB17-1-29
|
 
|
Don­ald E. Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-1-14
|
 
|
Don­ald Knuth and Pierre MacKay
|
 
|+
 
|
1981
|
 
|
Knuth:TB2-3-5
|
 
|
Don­ald Knuth
|
 
|+
 
|
1982
|
 
|
Knuth:TB3-1-10
|
 
|
Don­ald Knuth
|
 
|+
 
|
1983
|
 
|
Knuth:TB4-2-64
|
 
|
Don­ald Knuth
|
 
|+
 
|
1986
|
 
|
Knuth:TB7-2-95
|
 
|
Don­ald Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-1-6
|
 
|
Don­ald Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-1-73
|
 
|
Don­ald Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-2-210
|
 
|
Don­ald Knuth
|
 
|+
 
|
1987
|
 
|
Knuth:TB8-2-217
|
 
|
Don­ald Knuth
|
 
|+
 
|
1989
|
 
|
Knuth:TB10-1-8
|
 
|
Don­ald Knuth
|
 
|+
 
|
1989
|
 
|
Knuth:TB10-1-31
|
 
|
Don­ald Knuth
|
 
|+
 
|
1990
|
 
|
Knuth:TB11-1-13
|
 
|
Don­ald Knuth
|
 
|+
 
|
1990
|
 
|
Knuth:TB11-2-165
|
 
|
Don­ald Knuth
|
 
|+
 
|
1990
|
 
|
Knuth:TB11-4-497
|
 
|
Don­ald Knuth
|
 
|+
 
|
1990
|
 
|
Knuth:TB11-4-499
|
 
|
Don­ald Knuth
|
 
|+
 
|
1991
|
 
|
Knuth:TB12-2-313
|
 
|
Don­ald Knuth
|
 
|+
 
|
2010
|
 
|
Knuth:TB31-2-121
|
 
|
Don­ald Knuth
|
 
|}
The orig­i­nal data is stored in a Lua ta­ble, hashed by tag. Start­ing with Lua 5.2 each run of Lua gets a dif­fer­ent or­der­ing of such a hash. In older ver­sions, when you looped over a hash, the or­der was un­de­fined, but the same as long as you used the same bi­nary. This had the ad­van­tage that suc­ces­sive runs, some­thing we of­ten have in doc­u­ment pro­cess­ing gave con­sis­tent re­sults. In to­day’s Lua we need to do much more sort­ing of hashes be­fore we loop, es­pe­cially when we save multi--pass data. It is for this rea­son that the xml tree is sorted by hash key by de­fault. That way lookups (es­pe­cially the first of a set) give con­sis­tent out­comes.
=8 Stan­dards=
 
The ren­der­ing of bib­li­o­graphic en­tries is of­ten stan­dard­ized and pre­scribed by the pub­lisher. If you sub­mit an ar­ti­cle to a jour­nal, nor­mally it will be re­for­mat­ted (or even re- keyed) and the ren­der­ing will hap­pen at the pub­lish­ers end. In that case it may not mat­ter how en­tries were ren­dered when writ­ing the pub­li­ca­tion, be­cause the pub­lisher will do it his or her way. This means that most users prob­a­bly will stick to the stan­dard apa rules and for them we pro­vide some con­fig­u­ra­tion. Be­cause we use se­tups it is easy to over­load specifics. If you re­ally want to tweak, best look in the files that deal with it.
Many stan­dards ex­ist and sup­port for other ren­der­ings may be added to the core. In­ter­ested users are in­vited to de­velop and to test al­ter­nate stan­dard ren­der­ings ac­cord­ing to their needs.
Todo: maybe a list of cat­e­gories and fields.
=9 Clean­ing up=
 
Al­though the bibTEX for­mat is rea­son­ably well de­fined, in prac­tice there are many ways to or­ga­nize the data. For in­stance, one can use pre­de­fined string con­stants that get used (ei­ther or not com­bined with other strings) later on. A string can be en­closed in curly braces or dou­ble quotes. The strings can con­tain TEX com­mands but these are not stan­dard­ized. The data­bases of­ten have some­what com­plex ways to deal with spe­cial char­ac­ters and the use of braces in their de­f­i­n­i­tion is also not nor­mal­ized.
The most com­plex to deal with are the fields that con­tain names of peo­ple. At some point it might be needed to split a com­bi­na­tion of names into in­di­vid­ual ones that then get split into ti­tle, first name, op­tional in­be­tweens, sur­name(s) and ad­di­tional: <tt>Prof. Dr. Alfred B. C. von Kwik Kwak Jr. II and P. Q. Olet</tt> is just one ex­am­ple of this. The con­ven­tion seems to be not to use com­mas but <tt>and</tt> to sep­a­rate names (of­ten each name will be spec­i­fied as last­name, first­name).
We don’t see it as chal­lenge nor as a duty to sup­port all kinds of messy de­f­i­n­i­tions. Of course we try to be some­what tol­er­ant, but you will be sure to get bet­ter re­sults if you use nicely setup, con­sis­tent data­bases.
Todo: maybe some ex­am­ples of bad.
=10 Tran­si­tion=
 
In the orig­i­nal bib­li­og­ra­phy sup­port mod­ule us­age was as fol­lows (ex­am­ple taken from the con­textgar­den wiki):
<pre detail='typing'>
% engine=pdftex
\usemodule[bib]
\usemodule[bibltx]
\setupbibtex
[database=xampl]
\setuppublications
[numbering=yes]
\starttext
As \cite [article-full] already indicated, bibtex is a \LATEX||centric
program.
\completepublications
\stoptext
</pre>
For MkIV the mod­ules were partly rewrit­ten and ended up in the core so the two com­mands are not needed there. One ad­van­tage of ex­plic­itly load­ing a mod­ule is that a job that doesn’t need ref­er­ences to pub­li­ca­tions doesn’t suf­fer from the as­so­ci­ated over­head. Nowa­days this over­head can be ne­glected. The first setup com­mand in this ex­am­ple is needed to boot­strap the process: it tells what data­base has to be processed by bibTEX be­tween runs. The sec­ond setup com­mand is op­tional. Each ci­ta­tion (tagged with <tt>\cite</tt> ) ends up in the list of pub­li­ca­tions.
In the new ap­proach again the code is in the ConTEXt ker­nel, so no mod­ules need to be loaded. But, as we no longer use bibTEX , we don’t need to setup bibTEX . In­stead we de­fine dataset(s). We also no longer set up pub­li­ca­tions with one com­mand, but have split that up in ren­der­ing-, list-, and cite-vari­ants. The ba­sic <tt>\cite</tt> com­mand re­mains.
<pre detail='typing'>
\definebtxdataset
[document]
\usebtxdataset
[document]
[mybibfile.bib]
\definebtxrendering
[document]
\setupbtxrendering
[document]
[numbering=yes]
\starttext
As \cite [article-full] already indicated, bibtex is a \LATEX||centric
program.
\completebtxrendering[document]
\stoptext
</pre>
So, we have a few more com­mands to set up things. If you use just one dataset and ren­der­ing, the above pre­am­ble can be sim­pli­fied to:
<pre detail='typing'>
\usebtxdataset
[mybibfile.bib]
\setupbtxrendering
[numbering=yes]
</pre>
But keep in mind, that com­pared to the old MkII de­rived method we have moved some of the setup op­tions to set­ting up the list and cite vari­ants.
An­other dif­fer­ence is the use of lists. When you de­fine a ren­der­ing, you also de­fine a list. How­ever, all en­tries are col­lected in a com­mon list tagged <tt>btx</tt> . Al­though you will nor­mally con­fig­ure a ren­der­ing you can still set some prop­er­ties of lists, but in that case you need to pre­fix the list iden­ti­fier. In the case of the above ex­am­ple this is <tt>btx:document</tt> .
=11 ML­BIBTEX=
 
Todo: how to plug in ML­bibTEX for sort­ing and other ad­vanced op­er­a­tions.
=12 Ex­ten­sions=
 
As TEX and Lua are both open and ac­ces­si­ble in ConTEXt it is pos­si­ble to ex­tend the func­tion­al­ity of the bib­li­og­ra­phy re­lated code. For in­stance, you can add ex­tra load­ers.
<pre detail='typing'>
function publications.loaders.myformat(dataset,filename)
local t = { }
-- Load data from 'filename' and convert it to a Lua table 't' with
-- the key as hash entry and fields conforming the luadata table
-- format.
loaders.lua(dataset,t)
end
</pre>
This then per­mits load­ing a data­base (into a dataset) with the com­mand:
<pre detail='typing'>
\usebtxdataset[standard][myfile.myformat]
</pre>
The <tt>myformat</tt> suf­fix is rec­og­nized au­to­mat­i­cally. If you want to use an­other suf­fix, you can do this:
<pre detail='typing'>
\usebtxdataset[standard][myformat::myfile.txt]
</pre>