First of all, the xml document seems mal-formed (maybe due to some artifact in posting?). This is an example.
><Title>Tropical medicine & international health : TM & IH</Title> The ampersands are not escaped... There are a couple of instances like this. This must be rectified before doing anything else.
 Then the main functionality of DefaultHandler pose problem, as far as I can see (as it is not easy reading, in particular there involves some user-defined type Abstract...).
[1.1] Your DefaultHandler is written as (local) anonymous inner class. This is very hard to debug in particular when it involves many lines of codes. It would be fine if it is fairly short or its functionality is very plain and easy to track. This is not the case. Hence, I would say put the whole subclassing of DefaultHandler into a separate class, an inner class if need be and inner to StringToXML class.
[1.2] And then, there seems to be a big problem in the scope and visibility of objAbstract. It is declared in the outer class. But, the code seems tasking to make change to it inside the anonymous inner class. That poses problem. (If I recall the error be asking the reference need be declared final in the first place and that's put the situation into a dilemma...)
[1.3] If still keeping in the same scheme, an objAbstract need to be declared inside the (extension of) DefaultHander. Also the setting should then be fine within the DefaultHandler. The problem is to retrieve it in the outer class. This can be done by reflection, adding obscurity to the approach. Something like this (recall that objAbstract would be declared within the handler)
 I would say, repeating [1.1], it would gain more clarity and less obscurity if you separate the subclass of DefaultHandler into a named inner class to StringToXML. Declare the objAbstract inside the handler. Then, the return statement would then be as simple as this with much clarity.