Yes, and that only difference is important, and it makes XML more open than SQLite. Perhaps not enough to matter (depending on your needs), but it is more open.

You may not want to look at XML without a tool, but you could. Or, most likely, you could build a tool to look at the XML. This is a crucial design consideration of XML - even if all XML tooling, open or not, is lost forever, you can still read the XML. Not so with SQLite.

Especially for a document format, this point seems important. That said, OpenDocument is zipped, which, while a simpler and even more ubiquitous format, is still a binary format that requires a library to read, so that detracts somewhat from the point. It's difficult to imagine a future where zip libraries survive but SQLite libraries don't.

Strictly speaking you can’t read XML without software either. Even a simple text editor is software of course, but you’ll also find XML files in arbitrary character encodings, and you absolutely do need non-trivial software to parse and display “plain” text in UTF-8.

You don't need a text editor, you just need to be able to read a sequence of bytes. XML anchors at the almost lowest possible point: you have the stream of characters. It's a pointless exercise to consider a format except on the premise that you have access to data in some way, and sequence of bytes is the simplest possible abstraction of data, a sequence of characters the second simplest.

ASCII encoded text is simpler than UTF-8, but there is content that can't be represented in ASCII. Zip comes a bit up the food chain from there, and SQLite comes quite a bit further.

XML is about being meaningful without tooling at the lowest possible level. Any added required tooling or documentation by definition makes the data less 'open'.

In the event of catastrophic loss of human knowledge to the scale that it makes it difficult or impossible to recreate a ZIP or SQLite driver, I would presume that maintaining the replacing the hardware on which XML/text files are stored would be an even bigger problem. Catastrophic collapse of civilization IMO would pretty much doom all our digital knowledge. Only books can survive such an event.

You don't need a catastrophic loss of human knowledge for this to be a problem. Running a piece of software written in the 80s, even with the source code available, can be quite a challenge. Support for some features of the current SQLite format might deprecated, then removed, over the next many versions. Or perhaps a subtle bug is introduced that renders certain ancient versions unreadable (https://news.ycombinator.com/item?id=15531489) and sticks around for long enough that you end up in a situation where you need to invest very significantly in software archaeology.

> Support for some features of the current SQLite format might deprecated, then removed, over the next many versions. Or perhaps a subtle bug is introduced that renders certain ancient versions unreadable (https://news.ycombinator.com/item?id=15531489) and sticks around for long enough that you end up in a situation where you need to invest very significantly in software archaeology.

At this point, you've side-tracked into an argument that anyone could make against any software.

Bingo. Which is why it's a quality not to have dependencies on any specific software when designing a format for longevity. XML has an absolute minimum of such dependencies, Open Document has only zip added to the mix, which is a format with tons of different and independent implementations, plenty of documentation for how to implement it - on top of being a fairly simple format to begin with.

SQLite for all it's significant qualities are none of that, and thus you shouldn't use it if designing for file format longevity.