Why anyone would want to convert their JSON to base64 so they can store it in their TEI file is beyond me. But I'm pretty myopic, I guess.
The main reason for storing this sort of thing in my projects would be that it's time-consuming and processor-expensive to generate on the fly.
Yes, but why store it in myDoc.tei rather than in myDoc.json? Seems like you'd be making your life harder. But that's just MHO.
We're not actually asking for binary data here; we're just asking for the possibility of non-XML data. I don't forsee any circumstances in which I'd want to include binary data. Mostly we'll be talking about existing metadata standards and transmission-friendly standards such as JSON, I think.
So you're saying that we should explicitly permit non-XML character-based formats (like JSON), but disallow binary formats (that have, by necessity, been converted to a character format, of course)? How do we tell the difference? I suppose if we don't provide @encoding or some other mechanism to say how the binary data has been converted to character data we can just say we disallow it. But even JSON, if I understand correctly, is not XML-safe, as "<" and "&" are permitted as unescaped characters in a JSON string, no? I.e., "Barnes & Noble" would have to be written "Barnes & Noble" or "Barnes \u0026 Noble". Or, as Lou points out, be wrapped in a CDATA marked section.