The astute author would note that DocBook permits bibliography elements within appendix, article, book, chapter, glossary, part, preface, sect1, sect2, sect3, sect4, sect5 and section parents. RefDB-lite, should generally work quite happily with those. However, it is technically possible to create a complete nonsense hierarchy without too much effort, such as the following pseudo DocBook structure:

  <set>
    <setinfo>
       <citation/> <!-- With no possible target bibliography -->
    </setinfo>
    <book>
      <bibliography id="bib1"/>
      <chapter>
        <citation/> <!-- definitely pointing to bib2 -->
        <bibliography id="bib2"/>
      </chapter>
      <chapter>
        <citation/> <!-- Which bibliography should this point to?-->
      </chapter>
      <bibliography id="bib3"/>
      <appendix>
        <citation/> <!-- Which bibliography should this point to ?-->
      </appendix>
    </book>
  </set>

Clearly there is ample scope for processing confusion. But, it is to be hoped that the wary author will exercise a modicum of restraint in their placement of bibliographies, despite the flexibility that DocBook provides.

Another major pitfall lies with the mismatch between the RISX, and DocBook "raw" bibliographic formats, and the application of the CITESTYLE formatting thereof. To be clear, RISX is a relatively simple mapping into XML of the aged, but widely supported, RIS bibliographic information format. Although useful, RIS, is rather crude in terms of detailed semantic and formatting information it can handle. The RefDB CITESTYLE formatting specification was designed to reflect the keys and elements of the RDBMS relational tables into which RefDB interally partitions and disects the imported RIS data. In contrast, the capacity of DocBook to hold "raw" bibliographic information, is almost limitless, though not necessarily clear, concise, easy to author or unique.

As a result there are several issues that will need careful consideration. In particular, can the representation of dates in the RefDB exported RISX be standardised in a numerical format? Are there better ways to handle journal series abbreviations? Can use of the USERDEFn and MISCn attributes be standardised across different citation styles? Could corporate authors, editors and publisher items be identified and transformed more consistently? And does the current RefDB-lite RISX (Hoenicka, 2005d) to DocBook "raw" conversion process rigorously capture all the intricacies of the source format?

Other issues will arise in the form of bugs and defects of the current XSL implementation of RefDB-lite, for instance RISX uses an abbreviated journal title compactification scheme whose expansion hasn't yet been implemented here

Another glaring ommission is that ordering of multiple references in a multi-biblioref citation, according to a numeric citation style, does not apply ascending or descending date ordering. Of course you could do it yourself, but this is a computer dammit. It automates things.

A third example arose with the handling of olinks in a handcrafted DocBook "raw" biblioentry, that exposed a deficiency in the underlying DocBook style sheets. If olinks are added within an internal bibliography, resolving those in the DocBook style sheets requires customising the xref.xsl olink template to support <xsl:param name="context" select="/"/>. Then modify its document($target.database.filename,/) statement to use document($target.database.filename,$context) (Potentially this could be remedied in the DocBook XSL stylesheets, but of course noone ever needed it before).

You will have to pass the context parameter to the select.target.database template as well (called within the olink template) and then repeat the above for the common/olink.xsl select.target.database template too. The problem is that the olink is coppied into a temporary result tree with an obscure base:uri, whereas document() needs to resolve the olink with respect to the source DocBook documents identifier in the olink database (hmmm, maybe we could copy the document ID to the rootnode of the temporary tree?).

Thats about it. Enjoy!