<br/>
These three suffixes are understood by the loader. Here the dataset has the name <tt>standard</tt> and the three database files are merged, where later entries having the same tag overload previous ones. Definitions in the document source (coded in TEX speak) are also added, and they are saved for successive runs. This means that if you load and define entries, they will be known at a next run beforehand, so that references to them are independent of when loading and definitions take place.
<div stile="" >
setup definition setupbtxdataset
</div>
<div stile="" >
setup definition definebtxdataset
</div>
<div stile="" >
setup definition usebtxdataset
</div>
<br/>
In this document we use some example databases, so let’s load one of them now:
<br/>
The rendering itself is somewhat complex to set up because we have not only many different standards but also many fields that can be set up. This means that there are several commands involved. Often there is a prescribed style to render bibliographic descriptions, for example <tt>apa</tt>. A rendering is setup and defined with:
<div stile="" >
setup definition setupbtxrendering
</div>
<div stile="" >
setup definition definebtxrendering
</div>
<br/>
And a list of such descriptions is generated with:
<div stile="" >
setup definition placebtxrendering
</div>
<br/>
A dataset can have all kind of entries:
<br/>
Each has its own rendering variant. To keep things simple we have their settings separated. However, these settings are shared for all rendering alternatives. In practice this is seldom a problem in a publication as only one rendering alternative will be active. If this be not sufficient, you can always group local settings in a setup and hook that into the specific rendering.
<div stile="" >
setup definition setupbtxlistvariant
</div>
<div stile="" >
setup definition definebtxlistvariant
</div>
<br/>
Examples of list variants are:
<br/>
The first argument is optional.
<div stile="" >
setup definition cite
</div>
<br/>
You can tune the way a citation shows up:
<br/>
Because we are dealing with database input and because we generally need to manipulate entries, much of the work is delegated to Lua. This makes it easier to maintain and extend the code. Of course TEX still does the rendering. The typographic details are controlled by parameters but not all are used in all variants. As with most ConTEXt commands, it starts out with a general setup command:
<div stile="" >
setup definition setupbtxcitevariant
</div>
<br/>
On top of that we can define instances that inherit either from a given parent or from the topmost setup.
<div stile="" >
setup definition definebtxcitevariant
</div>
<br/>
But, specific variants can have them overloaded:
<br/>
This command has two synonyms: <tt>\nocite</tt> and <tt>\nocitation</tt> so you can choose whatever fits you best.
<div stile="" >
setup definition nocite
</div>