Lists Home |
Date Index |
Title: RE: [xml-dev] Supporting Unicode (was Some comments on the 1.1 draft)
Wasn't one of the design goals of XML to be human readable?
How do I do that? I display the document on my screen,
or I print it out. Surely having the least number of control
characters in the document makes that more readily achieveable.
I don't want to have to use a hex editor to see the 'real'
contents of a document. Nor have my printer go ballistic
or print blocks in place of control characters.
If serializers want to use XML then they should obey the
rules. OK, it's less efficient to have to encode all the
control characters as character references, but after all
they chose a relatively inefficent format in the first
Web site: http://www.quest.com
> -----Original Message-----
> From: Rick Jelliffe [mailto:email@example.com]
> Sent: Thursday, December 20, 2001 4:23 PM
> To: firstname.lastname@example.org
> Subject: [xml-dev] Supporting Unicode (was Some comments on the 1.1
> From John Cowen:
> > However, the control characters are *characters*, not really very
> > different from other control characters in the Unicode space
> > which are already allowed: not only the ISO C1 controls, but
> > also such things as: the Mongolian variant controls (and the
> > Unicode 3.2 generic variant controls); the bidi marks, overrides,
> > etc; and the music symbol begins/ends.
> The Unicode recommendations w.r.t. control characters are in
> That makes it clear that control characters are unlike other
> for which Unicode provides "semantics". The only C0 or C1
> characters for
> which Unicode provides "semantics" are TAB, CR, LF and NEL.
> Unicode completely defers the use and semantics of the other control
> characters to whatever makes sense for the application in question.
> There is no justification for saying "we need to support the
> C0 and C1
> characters in order to support Unicode" because Unicode does not
> require any such thing.
> But what if we do decide to support these control characters:
> what does
> it mean? It means that we recognize their semantics,
> according to which
> it is inappropriate to embed most of them (e.g. EOF, BS,
> BELL, flow control,
> etc) in a text file for transmission anyway.
> Rick Jelliffe