Wrong alert: bibliography-database: is mandatory about asciidoctor-bibliography HOT 10 CLOSED

Thanks @shahryareiv for reporting -- @paolobrasolin could you help check this? Appreciate it!

from asciidoctor-bibliography.

Thanks for the reminder @shahryareiv

@paolobrasolin could we fix it up so we don’t ignore the attributes?

@shahryareiv I’m going to ping you separately about your asciimint toolchain 😉

from asciidoctor-bibliography.

@ronaldtse Sorry for late reply. Yes it works fine. Thanks a lot!

from asciidoctor-bibliography.

@shahryareiv Unfortunately I was unable to reproduce the error with your report. Could you provide a sample document w/ a biblatex file that have this problem? Thanks.

You exposed a (partially related) issue, though: we are using an engine that supports explicitly just BibTeX. I have added a warning that will pop up when loading a *.biblatex file, and I'm writing a clarification to the readme.

That being said, even if your database is using BibLaTeX features absent in BibTeX this should not generate the reported error (and gracefully degrade to using only BibTeX-compatible features). So, if you could produce a sample document that would still be precious.

from asciidoctor-bibliography.

Ok, I guess I found the exact problem. It is not Biblatex file. The problem is how it reads attributes. In my case, in the document, a blank line was keeping attributes out of head region and making them disabled. I was also providing the attributes through CLI but it does not consider them.
So:
asciidoctor -r asciidoctor-bibliography -a bibliography-database=library.bib -a bibliography-style=apa test.txt
with this text:

= A test of biblatex

:bibliography-database: library.bib
:bibliography-style: apa

== Introduction

Articulated through a frequently used set of keywords, such as _acceptance_, _success_, and _satisfaction_ cite:[ammenwerth_evaluation_2003].


[bibliography]
== References

bibliography::[] 

does not work (because of the blank line after the title). In the real life case, my document is quite complicated with multiple files going through pipes to join together later and it is an easy pitfall to insert an extra blank line. It think it would be more robust if the attribute can be read anywhere.
Also, for a text with different outputs it is usually better to provide attributes through CLI to keep the original text untouched. I think it is good to enable CLI attributes (I supposed they have priority over head attributes).

Otherwise, it could read my 1.3M biblatex file with no problem (just for the above test)

from asciidoctor-bibliography.

@shahryareiv thanks for the confirmation!

Unfortunately the structure of AsciiDoc is as such — it prohibits any blank lines between the title and document attributes. I agree that it is an unnecessary inconvenience, but there’s nothing we can do there.

Is there a specific reason why pipes are needed to join the file, instead of using the Asciidoctor include::path[] syntax?

On the other hand, if you don’t mind sharing the basic structure of the document we could try to give some recommendations to get things working better. Sometimes we find it just easier to use a Makefile to glue together parts.

from asciidoctor-bibliography.

Thanks @ronaldtse !

To give you an example why CLI attributes are important (and why sometimes I need piping files together):

I have articles and documents that can become standalone articles or chapter of different books.
Each article might have different title depending on its final publishing version.
I use Scrivener and all of my writings are in a few big bindings, where parts of that should be exported each time.
Articles and books are being published as PDF (through Asciidoc => DocBook => Xe/Latex => PDF), HTML, and Docx (through Asciidoc => HTML => Docx).
I write in English and Persian, for the Persian articles they should be preprocessed to translate the keywords back to their original English versions.
Acronyms and their expansions are not handled in Asciidoc so I should handle them through preprocessing.
Bibliographical things might be needed to be at the end of each chapter or at the end of book.
Graphical files are in Tikz, SVG, PDF, PNG, or even as the output of R codes. They should be compiled into different formats (and updated if needed) for PDF or HTML outputs.
I use lots of styles (inline/block attributes) which should be translated to their equivalent CSS or Latex macros versions.
You can find one of my works entirely in asciidoc here: http://www.diva-portal.org/smash/get/diva2:866706/FULLTEXT03.pdf

To handle the above complexities, I had to write my own toolchain (I call it Asciimint). It used to be some makefiles (https://github.com/shahryareiv/asciimint/tree/master/z_compile_room) but later I changed it to nodejs and its gulp library (have not uploaded that yet).

The important thing about the above model is that many times it is much easier to fill in a configuration file for a new project (and copy most of it from other writing projects) so now there is a YAML file. Some of those configurations are fed into to asciidoc as CLI attributes. For example, the toolchain copies the bibliography file from some source into the project directory and asks Asciidoc-bibliography (or other extensions) or Latex-Biber to consider it when compiling the document. Putting those information in the document itself makes the document inflexible, wired to some specific directory structure, and hard to combine with other documents. That is why CLI attributes are important here.

Also some times I need to stitch files together depending on what ingredients are needed in the final output. Wiring things through include directive is not flexible enough to handle different models without making the documents themselves less readable.

from asciidoctor-bibliography.

@paolobrasolin , @ronaldtse
I just wonder if I should open a new issue regarding ignoring attributes passed through command-line (explained above)?

from asciidoctor-bibliography.

@shahryareiv the issue has been fixed and new gem released -- could you help check if the problem still exists? Thanks!

from asciidoctor-bibliography.

Thanks @shahryareiv for the confirmation!

from asciidoctor-bibliography.