bibtex-1.0, or maybe not

Norman Gray gray at nxg.name
Thu May 23 18:03:54 CEST 2024


Karl, hello.

On 22 May 2024, at 2:25, Karl Berry wrote:

>>     A final fragment of my motivation was that this might start a
>>     conversation about bibliographies, in a world where bibtex v0.99 has
>>     been current, and v1.0 has been anticipated, since 1988.
>
> I've talked with Oren from time to time about the putative 1.0. It seems
> like there's an insuperable compatibility problem to making any
> meaningful changes.

Thanks for this report from the source (!).  However, the example you select, about the 'url' field, doesn't seem a knock-down argument.

> As a basic example: a "url" field is obviously
> needed nowadays. But if he adds a url field to the standard styles,
> there will inevitably be usage conflicts (at the bib level, the bst
> level, the tex level, wherever) with the existing url fields that have
> been added by many other styles.

Is there really a practical problem there?

If I want to include URLs in references, then plain.bst isn't going to help me, so I pick another bibstyle from the numerous available, which does implement support for a url field, and I'm sorted.  Or I can hack in that support to a style I want, and carefully rename the result (and I have form here: <https://ctan.org/pkg/urlbst>).  If url field support were to appear in the .bst files included in a putative bibtex-1.0, then nothing would change for me, except that I'd now have the option to change my source files back to using plain.bst once more.

Thinking instead of .bib files, there doesn't seem to be a lot of scope for incompatibility there, either.  A url={} field would contain... a URL, and while that will have been reinvented on numerous occasions, I have difficulty imagining how it could be invented in an incompatible way.  OK, perhaps someone will have added .bst support for the url={} field including a sequence of URLs, and that would be an issue.  But that's all I can think of.  Am I just being unimaginative here?

> If one takes compatibility as paramount, which we do, together with the
> fact that virtually everything of interest has already been implemented
> one way or another, it seems there's no way to make a useful 1.0.

I think that 'everything of interest' is doing quite a lot of work in that sentence!

The @alias and @modify ideas in the 1994 bibtex-1.0 article are thought-provoking, as is the idea of 'better documentation'.  Also, for what it's worth, that document anticipates adding new fields, adjusting the .bst language, and making what look like (at least slightly) backward-incompatible changes.

One thing I might wish for (based on my experiments over the last few months) would be a little more clarity about BibTeX syntax and .bst semantics.  The btxdoc.pdf document doesn't fully commit itself to what the grammar of a .bib file actually is (Nelson Beebe's 1993 article <https://tug.org/TUGboat/tb14-4/tb41beebe.pdf> lamented this, too, and Patashnik's document promises such a grammar in 1.0's documentation), and there are a couple of other ambiguities which surface on an implementer's close reading.

> So, barring some brilliant new idea about how to proceed, I think 0.99
> is the end of the line for original BibTeX. It does its job, which is
> still good enough for a large percentage of real-world cases. OTOH, if
> anyone does have an idea for something that could be added to original
> bibtex while retaining compatibility, Oren is ready to listen.

I wouldn't necessarily disagree with this.

I do sometimes wonder, though, if we in the TeX world might not be accused of fetishising backward compatibility in some areas.  If there is one area where a little breakage would be tolerable -- for example because in my personal experience the bibliography is where I anticipate and tolerate a certain free variation -- it is in the context of a still-not-yet-1.0 program.

One could imagine distributions including a `bibtex` program at v1.0 alongside a bibtex99 program scrupulously unchanged from v0.99d, for those occasions where a precisely reproducible workflow is desirable.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk



More information about the texhax mailing list.