[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote:
>
> Nothing to do with old or new editors. The editor I use is
> more than capable of taking an input string of →
> (or anything else I
> choose) and inserting the relevant unicode character or
> character reference. However I don't want it to do that as
> then it is much harder for people to edit the document (it's
> easier for machines, but I care less about machines).
You are (rightly) restating that there is a user requirement out there. I
am not denying the existence of that requirement. The point I am making is
that the proposed solution doesn’t properly solve that requirement.
I believe that the problem should be regarded as a local problem of the
system where a document is visualized or edited, not as a representation
problem. In other words, it is an application-level problem that should be
addressed by enhancing the software.
For example, if there is an existing document, encoded in UTF-8, that
contains a lot of "difficult" characters, some users may want to be able to
display/edit that document using character names (or with the assistance of
some user-interface thing that shows the name of the characters). The
proposal does not address this use case.
On the other hand, if somebody creates a document, encoded in UTF-8+names,
that contains a lot of & n b s p ; & e a c u t e ; pseudo-references
and other such bit patterns, some users may want to be able to display/edit
that document with those characters (or a subset of them) shown in their
usual Unicode display form.
Given an XML document, consisting in a given sequence of Unicode characters
(which are the same Unicode characters regardless of the encoding), why
should *my* visualization preferences affect the way *you* see the document?
Alessandro
|