From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sun Jan 11 2009 - 17:26:03 CST
On 1/10/2009 2:31 PM, Doug Ewell wrote:
>
> The strong feeling I am getting from this, from everyone in the
> pro-emoji camp, uniformly, is that it makes no difference whatsoever
> what kind of things are being interchanged publicly as plain text. If
> they are being interchanged publicly as plain text, that is sufficient.
>
> So we could see sounds, video clips, program instructions, data,
> anything, and as long as they are being interchanged publicly as plain
> text, there will be a strong motivation to encode them in the UCS, and
> arguments against encoding them will be deemed inappropriate.
>
We've been around this bend before. There's already a precedent (of
sorts) for 'sound', with the BEL character, etc.
The real answer to this is that the more a proposed entity deviates from
the majority of characters, the stronger the justification would have to
be. For compatibility characters, which such an entity would be encoded
as, the justification depends on the level of usage, and the degree to
which added interoperability benefits existing Unicode-based
implementations.
As has been repeated here, many times, the decision is a case-by-case
decision. There are no firm demarcations or hard-and-fast rules.
BEL would not have been coded by itself, had it not been intricately
interwoven with the rest of the ASCII characters, into data streams that
made sense to be able to map to Unicode wholesale. (And most
implementations don't actually ring a bell, so that's fine too).
Membership in a set can push something inside the line, that by itself
would not be considered. Clearly, that's the case in the current
situation as well.
So it's pretty useless to speculate in advance for which strange
outliers it might be possible to make a case somewhere in the future.
But I suspect that the further out the outlier ends up, the stronger the
justification will have to be, and the more compelling the benefits.
Finally, I want to remind you again, that the decision tree for deciding
to encode compatibility characters is different from the decision tree
for ordinary characters. For the latter you start with "are they plain
text". For the former you start with "are they interchanged". That makes
all the difference in the world, and confusing these two cases, as
several participants in this discussion continue to do isn't helping
anyone. Let alone helping UTC come up with a solid decision.
A./
This archive was generated by hypermail 2.1.5 : Sun Jan 11 2009 - 17:28:00 CST