Hi Syd, On 15-07-14 06:12 AM, Syd Bauman wrote:
If the content model allows rng:text (or, I presume, <textNode>), a user can enter non-XML data so long as a) it is proper UTF-8 or whatever, b) it does not contain "<", c) it does not contain "&", and d) user is willing to think through white space issues.
Since base64 encoding only uses A-Z, a-z, 0-9, +, /, and =, that's the typical method of including non-XML data in, say, <binaryData>.
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.
But this reminds me that if we do go this route, we would want to factor out @encoding of <binaryObject> to a class (att.binaryEncoding?), and add <xenoData> to that class. Blech.
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. Cheers, Martin
You can't permit non-XML data unless it's wrapped in a CDATA marked section, methinks (so tough luck if your non-TEI xenodata has something like "]]>" in it at some point :-( ) but otherwise I don't see why this should pose a problem.
Apologies for commenting a bit out of phase on this... my French rural wifi connexion is sporadic