Hi Denis,
Thank you very much for your message — and especially for your offer to
help. It comes at exactly the right time, since questions of
bibliographic infrastructure are now becoming central to the problem.
I tend to agree with you about |context-sbl|. Including it directly in
the ConTeXt distribution would certainly be attractive, especially
because it would simplify installation, testing, and long-term use. At
the same time, the maintenance question is real for a style as
specialized and technically substantial as SBL.
That said, I do not think inclusion in the distribution is unrealistic
in principle. It could become a reasonable objective once |context-sbl|
has been thoroughly audited, remaining bugs and edge cases have been
corrected, and the implementation has been reviewed and, where
appropriate, simplified or optimized. The real question may therefore be
less whether SBL belongs in the distribution than whether the module has
reached a sufficiently stable and maintainable state.
Until then, a properly structured and easily installable module seems to
me the most realistic solution. It would also provide a useful
intermediate stage, allowing the code to continue evolving independently
while making it easier to install, test, document, and maintain.
As for my phrase “creating a separate bibliography processor,” I realize
that it could be misleading. I did not mean that I had considered
building a new equivalent of BibTeX or Biber. On the contrary, my
intention is to remain within ConTeXt’s existing |publications| system
and to make as much use as possible of what is already there: datasets,
BTX data, enhancers, |dataset.details|, existing rendering styles, the
Lua–ConTeXt interface, etc.
What I am experimenting with is rather a small additional layer for
bibliographic data that may exist in several script or language
representations. A single title, for example, may have:
an original-script form
a transliteration
a translation
and each of these representations may have its own metadata:
language
script
direction
possibly a transliteration scheme, etc.
The idea is then to separate responsibilities more clearly: the data say
which representations exist; a policy chooses which one or ones should
be used; ConTeXt/LMTX handles the actual typesetting — Unicode, fonts,
language, bidi — while the bibliographic style remains responsible for
structure and punctuation.
Schematically, I currently have something like:
bibliographic data
↓
native publications dataset
↓
multiscript metadata in dataset.details
↓
selection policy
↓
native BTX rendering
↓
APA / Chicago / SBL
The latest tests are quite encouraging: I now have the same generic Lua
bridge working with APA, Chicago, and |context-sbl|, with only a small
ConTeXt adapter specific to each style. Greek and Hebrew titles,
including RTL Hebrew, pass through the same mechanism.
The point that is now becoming central is how to represent the metadata
cleanly.
At the moment, in the tests, some of this information is still
hard-coded in Lua. By that I mean that the code explicitly knows certain
individual cases: for example, it knows that the entry
|aristotle-politics| should be treated as a Greek original in |Grek|,
with a transliteration in |Latn|, or that another entry is Hebrew and
should be rendered RTL. This is very useful for validating the
architecture, but obviously not satisfactory in the long run.
The goal is therefore to move towards a more declarative approach: the
bibliographic data themselves, or a metadata layer naturally associated
with them, should declare that a given representation is a Greek
original, a Latin transliteration, an English translation, and so on.
The Lua code would then simply interpret that information generically.
In other words, I would like to move from something like:
Lua knows:
aristotle-politics → Greek original
maimonides-guide → Hebrew original
to something like:
bibliographic data declares:
role = original
language = agr
script = Grek
direction = ltr
and the same code should then work for any entry.
This is precisely where your experience could be especially useful. One
of the next questions is where such multiscript metadata should live
most naturally in ConTeXt’s |publications| model: in additional |.bib|
fields, in a separate metadata layer, in userdata, or in an enriched
structure built by an enhancer.
I would rather not freeze a convention too quickly before looking at
this question from the point of view of the bibliographic infrastructure
itself.
So yes, your offer really does come at the right moment.
Best,
JP
Le 18/08/2026 à 14:06, [email protected] a écrit :
Hi Jean-Pierre
I also think it would be great if context-sbl were part of the
distribution, but that poses maintenenace questions… A module might be
more appropriate.
Regarding this:
> have begun experimenting in that direction as well, still within
ConTeXt’s native |publications|architecture rather than by creating a
separate bibliography processor
What do you mean with “creating a separate bibliography processor”?
Also, I’m very much interested in the bibliographic infrastructures,
so if there’s anything where I might be of any help, count me in.
Best,
Denis
*Von:*Jean-Pierre Delange via ntg-context <[email protected]>
*Gesendet:* Dienstag, 18. August 2026 13:15
*An:* [email protected]
*Cc:* Jean-Pierre Delange <[email protected]>
*Betreff:* [NTG-context] Re: bibliography with certain canonical reference
Hi Hraban,
Yes, I think this is a very reasonable suggestion.
I am currently writing several chapters on bibliography for ANSS-CE,
and I have in fact just completed Draft No. 1 of that part. This work
led me to test |context-sbl|quite extensively. For the moment, it
remains an external module, and these tests also brought me into
contact with its author, Joe McCollum, as well as with Kirk Lowery,
who has considerable experience with |biblatex|and complex
bibliographic modelling.
There seem to be two related questions here.
First, I agree that integrating the SBL module into the ConTeXt
distribution could be a very good thing. At the same time, my recent
tests suggest that there is still a little work to do before the
module can really be considered optimal. I have found a few small
points that could be improved, especially in some of the less common
cases involving ancient texts, canonical references, multilingual
material, and related bibliographic structures.
Whether |context-sbl|should become part of the distribution is of
course something for Hans and Joe to decide. If that is not desirable,
then restructuring the repository so that it can be installed and
updated as a normal ConTeXt module would already be a substantial
improvement.
There is also, I think, a second and more general direction worth
exploring. LMTX now provides very powerful facilities for Unicode,
scripts, language handling and bidirectional typesetting. It might
therefore be possible to make better use of these native capabilities
for genuinely complex bibliographies — complex not because
bibliography is conceptually exotic, but because it is never entirely
simple to typeset a single bibliography containing, for example,
Arabic, Hebrew, Syriac, Greek, English, German, Russian,
transliterations and translations, while keeping the bibliographic
style itself coherent.*
I have begun experimenting in that direction as well, still within
ConTeXt’s native |publications|architecture rather than by creating a
separate bibliography processor. The idea is to distinguish, for
example, the original-script form of a title from its transliteration
and translation, while leaving ConTeXt/LMTX responsible for the actual
script, font, language and direction handling.
I would be happy to help test any reorganization of |context-sbl|, and
I would prefer not to fork Joe’s project independently without first
discussing it with him.
Best,
JP
* See here a PDF of such a test.
Le 17/08/2026 à 09:10, Henning Hraban Ramm a écrit :
Am 17.08.26 um 06:31 schrieb Jean-Pierre Delange via ntg-context:
I use specifications such as APA or Chicago myself, and I
think they are very good tools for ordinary bibliographic
work. But I would still encourage you, when you have the
opportunity, to experiment with | context-sbl|.
SBL see https://github.com/jjmccollum/context-sbl
<https://github.com/jjmccollum/context-sbl>
Wouldn’t it make sense to include the SBL style in the distribution?
If not: Could the author (or maintainer) please restructure the
repository so that we can make it installable as a module?
(Of course we could fork and change it accordingly. I don’t really
want to do it myself, since I never needed a proper bibliography.)
Hraban
___________________________________________________________________________________
If your question is of interest to others as well, please add an
entry to the Wiki!
maillist : [email protected] <mailto:[email protected]>/
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
<https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl>
webpage : https://www.pragma-ade.nl <https://www.pragma-ade.nl>/
https://context.aanhet.net <https://context.aanhet.net>(mirror)
archive : https://github.com/contextgarden/context
<https://github.com/contextgarden/context>
wiki : https://wiki.contextgarden.net
<https://wiki.contextgarden.net>
___________________________________________________________________________________
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : [email protected] /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
