Re: [docbook] Biblioentry markup standards -- identifying the type of entry

[Peter Flynn <peter@silmaril.ie>]

On 11/06/2020 01:55, Richard Hamilton wrote:
> Regarding LaTeX, do you use this tool chain in place of the DocBook
> XSLT .fo/.html stylesheets or do you integrate the two somehow? 

I was using LaTeX before FO, so we stuck with it; so the XSLT is all our 
own work.

> If itâs the former, thatâs not going to work for us because we have 
> stylesheet customizations for both .fo and epub that I wouldnât want 
> to try and duplicate in LaTeX.

Then definitely stick with what you've got. If you're outputting HTML 
and EPUB, LaTeX is no use to you, except for one thing: bibliographic 
references (more on this below).

> Regarding marking the type on biblioentry, I agree that this should 
> be done on the top-level biblioentry element. I was wondering about 
> using the @typeof RDF attribute, but that seems to be abusing RDF 
> markup (as opposed to abusing @role:-). The one advantage of abusing 
> @role is that the existing iso690 customization uses @role.

Yep, stick with it. I used @type because I wanted the token list so
that it provided an extra safety blanket.

> The list of biblatex types you pointed me to looks comprehensive. It 
> certainly didnât miss any type that I would ever use. I could see 
> using that list, though Iâm not sure Iâd want to try and implement 
> all of them.

Article, book, inbook, incollection, manual, and thesis cover most of 
what we need. Occasionally 'misc' :-)

> I wasnât thinking of requiring biblioset on both parts of an
> inclusion. 

Only for those needing the separation. DocBook has no journaltitle or 
booktitle element type, so if you use title for the title of the 
article, what do you then use for the title of the journal? I guess you 
could use titleabbrev (we use if for the biblatex shorttitle field), or 
you could use citetitle (we use it for titles-within-titles).

> The biblatex types probably make that unambiguous, but I had been
> thinking that the biblioentry âtypeâ would refer to the actual thing
> youâre referring to (article, etc.), and biblioset would be used for
> the publication it was included in (journal, proceedings, etc).

Yes, you could use just one biblioset, and everything outside it is
the parent or child document.

> What is the advantage of enclosing authors, editors, etc., in
> authorgroup? Is it just to make the processing easier 

Always :-) Especially if you're *not* using biber, which does a good job 
on multiple names. One of the many good things in Eve Maler's and Jeanne 
el Andaloussi's book on designing SGML DTDs all those years ago was 
their insistence that if you had more than one consecutive occurrence of 
something, you almost certainly needed to put it in a wrapper :-)

Now: HTML (and EPUB XHTML). Bib reference formats are picky, to say the 
least. The advantage of biblatex is that it already knows the formats, 
and they have been written by people in the field, and used by millions 
of users, so they are for all practical purposes correct, which means 
you don't need to write anything.

But within a fully-formatted entry there are still three typographic 
considerations apart from punctuation: fonts. Bold, italic, and 
smallcaps are most of what the publishers want. Rather than implement 
dozens of conflicting XSLT nests of choose-when and if, the lazy way is 
to output the entries to BiBTeX format, run an 8-line LaTeX document 
over it, through biber, lather, rinse, repeat, and create the PDF.

\documentclass{article}
\usepackage[backend=biber,style=authoryear]{biblatex}
\usepackage[a4paper,margin=2cm,nohead,nofoot]{geometry}
\addbibresource{client.bib}
\begin{document}
\nocite{*}
\printbibliography
\end{document}

Then push the PDF through Apache PDFbox ExtractText -html and the output 
will preserve case, punctuation, and bold and italics in all the right 
places. Sadly, PDFbox doesn't understand smallcaps: that does have to be 
flagged somehow if you are using a format that requires it.

But it's not for everyone, and if you already have code implementing the 
different formats, I'd stick with it.

Peter