On type & fonts

Type design notes      Font production notes      Type & font tweets

Readable structure, unreadable text

One advantage of XML, even a design goal according to the specification, is that it is human readable as regards data structure.[1]/[2] As a consequence, however, data itself turns out to be less readable:
Data usually means text – a string of characters, accordingly called "character data" in the specification. What makes XML readable in terms of data structure is that this structure is represented via markup which is text too. This implies that some characters may serve two levels: first, the level of data, and second, the (meta) level of data structure, being constitutive of markup since they serve to indicate tags, attribute assignment, etc.[3] To avoid ambiguity, those few characters that are constituive of markup must be escaped when appearing in data – must be replaced by a somewhat longer descriptive character string (< and & becoming "&lt;" and "&amp;"). This makes data or text less readable and, I feel tempted to say, corrupts the text.
This is not news but worth repeating. The ambiguous role of some characters, being part of data and representing data structure, is problematic.

Introducing Data Format Non-Characters

There may be a simple solution for making readable, i.e. text based, data formats more readable and ensuring that all text can be expressed as a string of Unicode characters without need for escaping. Unicode already knows a block of non-characters. These are located near the end of UTF-16, FDD0..FDEF, are meant for internal use in applications, and are "private" as regards the meaning of individual non-characters.[4] In analogy to these non-characters, Unicode could reserve code points for non-characters for use in data formats. Such Data Format Non-Characters are "private" too at the level of Unicode. Their meaning is expected to be defined in individual data formats' specifications.[5]
I leave it open which code points to reserve for them, or how many. A range like FD40..FD4F suggests itself, it is a full column and moreover on the same page as existing non-character.
XML, for example, only needs very few of such non-characters to do the same job, unambiguously, as < > = " do now. Anything else, tag names, property names, etc can be described with normal characters. The same would be true for other text based formats.

Visual representation of Data Format Non-Characters

Visual representation of Data Format Non-Characters is not standardized by Unicode either. For visual representation, I expect Data Format Non-Characters to be mapped to representative normal characters from which they borrow shapes. This mapping, too, is part of each data format's specification.[6]
XML, for example, would map Non-Character code points for tag delimiters, assignment and enclosure to < > = " as representative characters.
Just as text editors do syntax coloring today, they would know a data format's mapping and represent Data Format Non-Characters by representative normal characters but highlight them visually, e.g. by coloring or bolding, so that a user knows that these are not normal characters.
Text editors may even, as a user is editing data of such a format, map Data Format Non-Characters to the representative characters' keys (assuming that the latter are more likely to be used when editing such files) and give access to normal ones via shortcuts. Or the other way round. I am merely pointing out options.

Advantages

Data Format Non-Characters would remove the ambiguity described above. Data Format Non-Characters would be encoded by Unicode yet explicitly considered as not being characters. Representation of data structure would be expected to involve Data Format Non-Characters at least as delimiters, to clearly separate markup from content. And data could, again, make use of the full repertory of characters.
I am not thinking of XML and related formats alone. Actually, any text based format that needs to distinguish between data and data structure would profit from such non-characters, including CSV which may use two of them as column and line separators.

Postscriptum

Why not use existing FDD0..FDEF non-characters? According to Unicode, applications "should never attempt to exchange them." And if they find such a non-character in a text they should "take appropriate action, such as removing it from the text."[7] This implies that applications which are ignorant of the special use of Data Format Non-Characters might open a file of a data format that uses them, remove non-characters, and thus corrupt the file.



Link for your feed reader.