On any given day in our submission queue, we are typically processing hundreds of thousands of submissions. Due to the scale of our system, we have two endpoints that receive submissions: a synchronous endpoint that processes submissions immediately and an asynchronous endpoint that accepts and queues submissions, then processes them in order of receipt. Which endpoint your submission uses depends on which deposit method you use.
Submissions sent using OJS and Metadata Manager are processed in real time using our synchronous deposit endpoint. Those files are sent and processed with one DOI per XML file and, as a result, generate files smaller in size.
Comparatively, the submission of a very large file size (e.g., 5 MB), manually uploaded or posted to us in bulk, that includes dozens of DOI records and even more references, will take us some time to process (likely greater than 30 minutes). We do validate the XML at the time of submission to confirm it is structured correctly, but files can and do fail during the more robust submission processing that follows the basic validation that occurs at the time of submission.
For instance, if a member includes identical ORCID iDs for two different contributors in a single DOI record, we will fail the submission wholesale because ORCID iDs are unique identifiers for contributors; we know that when matching ORCID iDs are included in your submissions for more than one contributor there is a mistake in the record itself. But we do not conduct that robust validation at the exact time of submission for XML submissions. XML submissions are those made manually through our admin tool and those sent in bulk using HTTPS POST (those posted submissions may return a 200 status code message indicating that we have successfully accepted the files for processing). Submissions made via our web deposit form helper tool are also processed asynchronously. That’s because XML submissions and web deposit form registrations can and are often larger files containing a number of DOI records in bulk, making it more challenging for us to process them synchronously and return a real-time confirmation of the status of the submission.
More about that success message returned in the admin tool
This basic truth of how our system operates means that when you submit a metadata record to us via our admin tool or web deposit form, the success message you receive means only that we have accepted the XML for processing. Our system has confirmed that your deposit meets the basic structure required of the file in order to be accepted. But, a more thorough asynchronous validation will follow. This success message does NOT mean that your DOIs have been successfully registered.
For XML submissions, we do send a detailed submission log, like the one screenshotted below, to the email address entered into the <email_address> element of the XML submitted to us:
And, the web deposit form success message?
Equally, the success message in the web deposit form means the same thing: we have accepted the XML created by the web deposit form for processing. Not that the complete metadata record has completed the registration process (and, that the DOIs are now registered).
Like the submission of XML, there are errors that can occur after we have accepted the XML created for processing. For instance, in my example here, I entered a journal title into the web deposit form that did not match the journal title previously registered for the ISSN I submitted. That’s a common error message that we see. When our system processed the file, with our more robust verification, it determined there was a discrepancy that needed review, so it failed the submission. I receive an email with the error message to the email address I entered into the last page of the web deposit form. That error message, within the submission log for this registration, looks like this:
Thus, the full story of submission 1755181840 is that it was accepted for processing by our system, but the registration itself failed. As you can see from the screenshot above, the journal title and ISSN combination I used in my submission did not match exactly what had previously been submitted for this journal and thus triggered the failure message (i.e., we have a different journal title and ISSN in our system).
Thanks for reading,
Isaac