But it doesn't really say why they chose to build on docx.
Having worked directly with their teams in the past (although not on this), a lot of their systems seemed to evolve naturally over time based on the needs present. In that industry, a large majority of the documents being passed back and forth are DOCX. So my semi-educated guess is someone built a system to handle some simple intake tasks for DOCX applications because a large majority already were, it evolved over a few years, and when they finally decided to fully automate the process, they decided to build upon what they have which only supported DOCX and it was cheaper/easier to mandate everyone submit in that format than to build a new system or add support for others.
Regulatory processes, business systems, and international integration are plagued by PDF OCR complexities. OCR creates systemic issues and an anatomy of complex system architectures. Im sure XML is a typical downstream for parsing anyways. Use DOCX to enhance quality of the overall scope of integrations.
I don't necessarily disagree with your point (since it makes complete sense), just wanting to point out that they already have a system in place for this using other means (although even there they are moving toward XML instead, likely because of what a pain it is to deal with text that exceeds the area of the input in PDFs)
It seems more like rationalization than reason.
Interestingly, a section in the wiki article linked mentioned the standard proposal was controversial because ODF already existed (and ODF was considered less complicated as a specification).
Nevertheless, good point. It depends on what you mean by "open".
[1] https://github.com/jsvine/pdfplumber/blob/stable/pdfplumber/...
[2] https://trepo.tuni.fi/bitstream/handle/123456789/21520/Nurmi...
A 6000-page spec and attributes that specify if the data is tabular data based on various properties (be it columns and rows or just plain text with start and stop pointers) and then may or may not render it visually as a table is error prone, even on first-party implementations (first-party desktop versions within Windows vary, as wel as on macOS, Android, iOS and their web offering).
If there was one simple data structure describing the table and all other aspects being optional, then yes, a XML based format is easier than OCR. But that's not the case I was pointing at.
Not really, or at least not all that specialized. You need:
a: a pdf-to-raster-image converter (ie any working PDF viewer, plus maybe the X server it talks to)
b: a reasonably decent OCR system capable of scanning tables (definitely nontrivial, but hardly "highly specialized" since things other than PDFs display data in tables).
I wrote DDEX parsers in the past and I wish it never existed...
https://support.microsoft.com/en-us/office/differences-betwe...
The list was only a few lines the last time I looked years ago, so maybe they're actually trying to make a complete list.
[edit: but I will grant that almost anything is better than attempting to parse useful content from PDF.]
In fairness though this a really good point.
I expect that whatever tooling the USPTO uses can probably just ignore those things. They're extracting metadata, not actually rendering it.
edit: ninja'd.
Is requiring the DOCX format just adding another step in the process for applicants?
Actually, it's the opposite. The USPTO conducted a study and found that over 80% of applicants are authoring their applications in DOCX format (through writing tools such as Microsoft Word). Because the files are originally in a DOCX format, uploading the original file eliminates the step for the applicant to convert the document to PDF prior to submission. Instead, the applicant is able to save the step of converting because our system will do that automatically.I used to be able to eke out accurate page layout in MS Word, but it was always fraught and more difficult. But if you’re not perfectionist about layout precision, MS Word provides the same meta-data encoding function through the application of style (‘this is a heading’, ‘this is a definition’, etc).