On the message topic – it’s true that with biblatex, bibtex/biber do less than bibtex usually does but they still validate the bib data in certain ways (repeated keys, missing keys etc.) and this is reported by bibtex on STDOUT. AucTeX certainly parses this output and uses it and it’s fairly easy to make Biber produce the same messages which avoids having to write code for AucTeX to integrate Biber nicely. I am sure other TeX tools also parse BibTeX errors/warnings in the same way so I think this is a worthwhile exercise in order to smooth the migration.

As to the type of messages that written to the terminal, this is of course to be considered. But with biblatex the data comes from latex, not bibtex, in any case. So I’m not sure what messages are really needed.

It’s a very good thing that the Biber author provides RNG and W3C schemas for the format. Potentially, with enough abstraction and modular interface design, Biber could read any standard XML bib format which nicely separates the format and biblatex oriented processing requirements. It’s already heading in that direction since Biber can parse .bib files and also biblatexml which are seperate code-paths internally but which converge on a common internal data structure.

However, editing XML by hand is not most people’s idea of a good time, so some kind of visual editor is still needed. For the moment, I’m sticking with JabRef and using the on-the-fly conversion. At least this means I get UTF8 entries with no issues. Once the BibLaTeXML format is sorted out, then *if* it looks good then support in open-source management tools is a must. (I don’t see closed-source people being very interested, unfortunately.)

- The original BibTeX format is extremely limited in terms of entry types and fields. With the original bibtex it’s quite impossible to create a decent bibliography for humanities or languages besides English. – The good thing is though, that the format is extremely simple and you can easily add additional fields without any problem. If the respective bst style or bibliographic app can’t read it it simply gets ignored. By this way, new bibtex styles have added all kind of new fields and types over the years. BibLaTeX also extends the traditional format and adds a plethora of new entry types and fields which already solve many of the traditional problems with BibTeX.

- One important advantage of the simplicity of the bibtex format is that an app like BibDesk or JabRef can easily be adapted by the user to work with biblatex’s additions. I heavily rely on BibDesk and have zero problems using it with BibLaTeX since from the perspective of the file format, BibLaTeX really just uses traditional BibTeX files. Unfortunately, the “flatness” of the BibTeX format also means that some problems simply can’t be solved (as the example you mention). Certain hierarchical structures are just beyond the scope of the BibTeX format. This is where biber and BibLaTeXML (potentially) come in.

- But if we assume that biber and BibLaTeXML can actually solve all or most of the problems of the traditional BibTeX format, we have another problem: While BibDesk et al. can easily handle the bibtex version of BibLaTeX they know nothing about BibLaTeXML. While I’m sure that they could be adapted this would mean much more work than using the BibTeX version of BibLaTeX (which can basically be used out of the box). And once we dabble with hierarchical fields, there are also not so easy questions regarding the user interface (how are hierarchies best presented in an interface?). As I said I heavily rely on BibDesk; if I actually had to choose between using BibLaTeX’s bibtex version together with BibDesk or BibLaTeX with no proper editor, I would always go for the first option; I guess many users would feel the same. To make a long story short: If a new file format wants to succeed in this area, support from the bibliography managers is the key.