Adding these links for helpful further reading on the history of importing in WordPress, and some other thoughts:

• https://pento.net/2021/01/18/wordpress-importers-stating-the-problem/
• https://pento.net/2021/01/19/wordpress-importers-getting-our-house-in-order/
• https://pento.net/2021/01/20/wordpress-importers-defining-a-schema/
• https://pento.net/2021/01/21/wordpress-importers-free-as-in-speech/

Having collaborated with @pento on this a few years ago, we created a WXZ format which is a ZIP file consisting of JSON files for posts, authors, categories etc.. Such a ZIP file could also contain media. At the time I created these pieces of code:

• https://github.com/akirk/export-wxz
• https://github.com/akirk/wordpress-importer/tree/import-wxz

the XML format of WXR surely feels tired to people used to JSON serialization, and it's certainly easier to avoid text-encoding issues in JSON since there are universal serializers people use instead of relying on echo. still, I've come to appreciate a few perks of the XML format that in my head keep WXR relevant.

WXR, by means of being XML, is inherently and conveniently extensible. although most WXRs mainly consist of post contents, the format could be extended to provide clarity around what structure is possible. the serialization is a big ugly, but XML writers and readers are fairly ubiquitous, including streaming parsers.

while I think there's good value to be gained with the explorations using a ZIP of an entire site as the export/archive format, I still find that the WXR could continue to play a strong role when paired with that. it's not a good format for storing binary data from wp-content, but it could:

• specify wp-config and php.ini values
• list the installed plugins and themes, noting which are active
• include more comprehensive user information
• define custom post types and include those posts

some ancillary meta could aid in exports and site transfers

• everything can include a content hash for data integrity.
• referenced media items can be listed per post, with a content hash.
  • importers can thus request the "raw" media items instead of fetching and backfilling the versions appearing on the rendered output of the post. for example, an optimized copy of an image hosted on a CDN vs. the original upload.
  • importers can identify the required media and fetch them before importing a post, ensuring that it's consistent from the moment it's available on the destination site.
  • an inbound post can be rewritten in one go to replace media URLs, relieving database load experienced during massive imports.
• files in wp-content can be listed with content hashes, giving the importing site an ability to request content not exposed in exported posts.

Many of these ideas equally apply to a JSON format, but given the existing wealth of WXR content and the fact that extensions to it should be safely ignored by legacy parsers, it seems worth embracing and extending before giving up on it.

the WXR format is amenable also to streaming from inside a ZIP file. I have my own goals for porting the design of the HTML API into a new XML API so that all WordPresses will have their own spec-compliant streaming XML parser. when that time comes, we could directly import a ZIP'd WXR without unpacking it and do so within an arbitrary maximum memory limit

Pulling in this comment from the Make blog post about Data Liberation...

The biggest issue I’ve seen with the current export / import is attached media. If the export for a specific post type could have an option to include attached media (i.e. attachment posts linked to the target posts) that would resolve real problems. There are plugins that help with this, but IMHO it’s a failing in the core exporter.

• @webaware