Another possibility: after doing some test, it turns out that we dont enforce UTF8 encoding.

Which means someone can configure his problem to sent things that are not encoded in UTF8, while they should. And that's indeed a possible cause.

The frontend allows users to insert data that the backend, through XML::Writer, cannot convert.

The database content of is an example
https://savannah.cern.ch/bugs/?func=detailitem&item_id=13860
To really be able to reproduce the problem, one need a sql export as the one attached

The current solution is to deactivate the checks made by sv_export, so it actually accept to make the export even knowing that users will have to update their xml files before giving it an xml parser.

The best solution would be to check for such content, convert it to a neutral thing, add a comment around the impacted data mentioning the issue. On all cases found, such content was here because of copy/paste but was not inserted intentionnaly.

The current workaround to skip the checks is acceptable for the release, but this last solution is the goal in the long run.
(And it would not be ok to imagine that the frontend could refuse characters by himself - when people do a copy an paste, we should in the item provide what they filled in the form)