In both cases here, you are using an Atom construct to define the structure
in non-XML, as well as XML, formats.

That's a mistake to me - our XML, JSON and TXT formats should all share the
same nouns, verbs and attributes, and should also be automatically
translatable into each other, but beyond that each should be well designed
in their own right - I don't want to see things which look awkward in the
JSON or TXT and be told that this is because they're mirroring Atom XML
constructs.

Fair point.

I don't believe this will make JSON or TXT either less flexible or more work
for machines - to the contrary, I believe it's easier to parse if you don't
have to have rules like 'always ignore ||| which is just there as legacy
from the XML'.

That may be fine if we don't mind the text version being lossy, which is something else I was trying to avoid.

Yes, this will mean a little more work for an automatic translator between
the formats, but that's code which is written once at most, whereas a
typical users will start using a single format and find it easier if this
behaves as naturally as they would expect that particular format to do.

Ok so it's definitely an area I need to do more work on...

Sam