JabRef is not an addon to a recommender system, but a recommender system might be an addon to the reference manager.
I can definitely agree to this point of view
However, IMHO there are many more issues to consider than Functionality and Maintainability. I will explain all issues in detail, but first let me mention that Mr. DLib does not only delivers HTML code but XML with HTML embedded. See, for instance, here https://api-dev.mr-dlib.org/v1/documents/ubk-opac-HL000670928/related_documents/. So, there is the option to deliver some additional structured information in addition to the HTML if needed.
I agree with you that some functions will be more difficult to implement when Mr. DLib delivers (primarily) HTML (and a few things might be even impossible). Nevertheless, most functions should still be rather easy to implement. For instance, selecting an article in Jabref after clicking a recommendation should be possible with a URL handler like jabref://article/#bibtexkey instead of opening a URL like http://arxiv.org/…
Our goal is to make our recommender system as effective as possible for every partner. This also includes an optimal presentation of the recommendations – and the presentation may have a really big effect on user satisfaction with a recommender system. However, finding the ideal presentation is not trivial. We need to do many experiments for this in which we vary all kind of variables. If we generate the presentation on our server, it will be very easy to change variables and analyze the effect. We would not have the manpower to implement those experiments separately for each partner. In other words: If you want the presentation primarily to be implemented in JabRef then we would have to take just one presentation and stick to it.
Mr. DLib is a new project, and most likely there will be some changes in the XML format. The more of the presentation is implemented in JabRef (based on the XML or whatever), the higher the probability that one day a new version of Mr. DLib is not compatible any more with an old version of JabRef.
As mentioned, we do not have the resources to implement an individual presentation for each partner. Consequently, the JabRef developers would have to support us here. I know that currently you are quite active but this has not always been the case in the past years. If in e.g. one or two years the development resources of JabRef would be limited again, probably no one could take care of required changes in the presentation.
Maintainability / Ease of bug fixing / need for organization
The more recommendation functionality is implemented in JabRef, the more dependent we become in our release cycles on JabRef. For instance, if we want to test a new way of presenting recommendations, we would have to wait until a new version of JabRef is released. This is not ideal. Similarly, as mentioned, but fixing would take much longer.
Also you could change the formatting at your end any time and thus inject a new look into JabRef that we have no control over.
Even if we did this (which we won’t), would this really so bad? I mean, the integration of e.g. MathSciNet also doesn’t exactly look like the other JabRef layout.
Moreover, various ways of shooting down JabRef with invalid HTML might become feasible
I am sure there are good JAVA libraries to validate HTML code, so this risk would be very low. In addition, by sending XML, the same problem theoretically would exist.
Whereas it even might be acceptable for us to show the HTML version provided by Mr. DLib this will be inacceptable for other potential partners
I am optimistic that I will convince other partners to use HTML, too
My suggestion is, we try the HTML way (especially since it is already implemented). And when we start to think about the “advanced” JabRef recommender system in which users also should be able to register an account and receive personalized recommendations, we talk again about if to continue using HTML or not.