<msg>Deposited XML is not well-formed or does not validate: Error on line 37: An invalid XML character (Unicode: 0x2) was found in the element content of the document.: Error on line 37: An invalid XML character (Unicode: 0x2) was found in the element content of the document.</msg>
Hello, and thanks for your question.
That kind of error means that there’s an invalid - or improperly encoded - character in the xml file you submitted. Sometimes these can be invisible, or sometimes you’ll see it as a replacement character, depending on where you’re viewing the contents.
The error message tells you the line number of the error, in this case line 37.
In order for us to help you, we’ll need to look at the contents of your submitted xml file. Could you email us at email@example.com? Either include the submission ID number from the submission log where you got that error message, or attach the xml file you submitted to the email.
Thanks for sending the submission ID.
The invalid character occurs in the title
<title>decomposition of 2-propanol over Alumina supported Thoria and Potassium ion modified catalysts</title>
It’s in between “modi” and "fied’. When I open your xml in a text editor it appears as a question mark, which is a [replacement character](Specials (Unicode block) - Wikipedia. In other contexts, you might see it as a white question mark in a black diamond, or a hollow square, or just a blank space. In other contexts it can be totally invisible.
Since you submitted this metadata using the Web Deposit Form, the invalid character was likely brought over when you copy-pasted some text with formatting.
You will need to resubmit the metadata, but ensure that you paste the text in without formatting. You can use command+shift+V on a Mac, or control+shift+V on Windows, to paste plain text without formatting.
عند ظهور خطا في الايداع ما معنها
Record not processed because submitted version: 1704539208 is less or equal to previously submitted version 20240105072246102
Each time a given DOI is updated, our system requires that the value in the xml is numerically larger than the previous submission’s . The purpose of this is to prevent someone from accidentally overwriting newer metadata with older metadata, if they happen to submit an outdated xml file.
Ensuring that each timestamp is numerically higher than the last is typically accomplished by using a standard date-time format to construct the timestamp when the xml files are created.
However, different systems use different date-time formats, so when a DOI needs to be updated by a different organization than the one that first registered or last updated it, or if you’re using a different system to produce the xml, there can be instances where a smaller timestamp value is used after a larger one. This will cause the deposit to fail.
We can reset the timestamp when necessary, after a title transfer or system change, etc. If you can send me a list of DOIs that need to be reset, I’ll change their timestamps to something smaller. Then, you can proceed with your update submissions.
If you ever need to check the most recent timestamp for a given DOI, you can find it in the previous metadata deposits, the xml api record, or the depositor report for the relevant journal.
In this case, you submitted an xml file with the timestamp “1704539208” but it’s trying to update a DOI which was previously submitted with a much longer timestamp “20240105072246102”. That will necessarily fail.
If you need us to reset your timestamps, please send us an email at firstname.lastname@example.org with a list of DOIs that you need reset.