Would XML have been a better data transfer format if it had been made less usable by humans?

I think that can be argued either way.

All serialization formats are bad except for whatever the new hotness is.

I suppose I agree with the premise sorawee was talking about, namely (in my own words) that read and write have nicer designs when they have a useful inverse relationship. (I wouldn’t go so far as to say they should have precisely an inverse function relationship. Just as pretty-print constructs an approximate representation of how a nested list might have typically looked before it was read, I imagine it would be at least a little bit useful to have “pretty-reading” that constructed an approximation of what structure a bad s-expression like (#<void>) might have had before it was written.)

I don’t see this being only about the kind of user-extensible data transfer concerns that would lead someone to use deserialize and serialize instead. It’s nice to mention they exist in case people aren’t aware, but read and write exist and have their own design pressures to talk about at the same time.

this reminds me, I’m considering making all of the type-definition forms in rebellion/type support serialization by default

@spdegabrielle opaque XML, #<xml>…LOL