RE: Adding RAINBOW FLAG to Unicode

I never said anything about stability of geopolitical entities. I only mentioned stability of encoded character sequences.

Peter

From: Ken Whistler [mailto:kenwhistler_at_att.net]
Sent: Friday, July 3, 2015 11:24 AM
To: Peter Constable
Cc: unicode_at_unicode.org
Subject: Re: Adding RAINBOW FLAG to Unicode


On 7/2/2015 5:56 PM, Peter Constable wrote:
Erkki, in this case, I think Philippe is making valid points.


- For the proposal to be workable requires some means of ensuring stability of encoded representations. The way this would be done would be for CLDR to provide data with all valid sequences --- effectively becoming a registry.

I think that is wrong on a couple of grounds.

First, detailed stability of reference to actual defined geopolitical entities
or particular detailed flag designs is
not *required* for proposal to represent *pictographs* of flags by some
sequence of Unicode characters to be "workable". Sure, more stability
of reference is desirable. But the current RIS pair mechanism for representing
flag pictographs for countries is already "workable" -- it works and is widely deployed
and widely used -- without having guarantees that some particular country may
not decide tomorrow to change its official flag and hence result in some
particular pictographic display being obsolete in some sense, for example.

Second, the horse is already out of the barn regarding the particular
data that CLDR would be referring to. This works by reference to
the ISO 3166-2 scheme of subdivisions:

https://en.wikipedia.org/wiki/ISO_3166-2

and *that* becomes the registry required for stability of representations,
plus whatever grandfathering stability-of-code mechanism BCP 47
adds on top of that. We don't require a further detailed level of
registration, I think, to make this workable. If the New Zealand
Hawke's Bay Regional Council (NZ-HKB) decided it needed a district
flag (or decided to change one it may already have), I'm not going to be
overly concerned about the details there. As long as
<base, tag-N, tag-Z, tag-H, tag-K, tag-B> has a stable definition as
a Unicode extended flag tag sequence, it is up to somebody else to
decide if they want to actually map a Hawke's Bay flag pictograph in a font to
that sequence -- or update the flag pictograph they may have been
using.

Yeah, this could be a giant headache for any vendor that felt they
had to support *every possible* region/subdivision sequence
and keep the exact representations of flag pictographs stable. But
I predict this will very, very quickly result in people making a
"let's cover the 99% case" set of decisions, and then issues like
"Should we display a flag pictograph for the Hawke's Bay Regional
Council?" will be dealt with by the normal methods of triage for
feature requests.




- The concepts being denoted are inherently political, often unstable, and sometimes highly sensitive.



Sensitive issues aside, a better approach would be to have a URN tagging scheme --- which IMO begs the question why this is a Unicode topic as it clearly crosses outside the limits of plain text.

A URN tagging scheme might make sense if what we were trying to
do was delegating all identity concerns to external authority,
and if we didn't care about efficiency of representation, either.

I don't think that is what this is about, as I tried to make clear yesterday.
I don't think we are encoding *flags* -- we are creating a mechanism
for the reliable representation of a set of *pictographs (emoji) for flags*.
And those pictographs for flags need an efficient representation that
can coexist comfortably with the rest of plain text -- the way the RIS
pairs already do.



Sensitive issues considered, though, it begs the question as to whether Unicode should be considering any of this at all, no matter what the scheme for encoded representation may be. Someone helpfully reminded us of this:


>> [...] the UTC does not wish to entertain further proposals for

>> encoding of symbol characters for flags, whether national, state,

>> regional, international, or otherwise. References to UTC Minutes:

>> [134-C2], January 28, 2013.

I believe that that statement (and the referenced decision) refer
specifically to the unwillingness of the UTC to entertain proposals
for encoding an indefinite number of pictographs for flags (of
whatever variety) *as symbol characters* -- that is,
one-by-one encodings as a single, gc=So code point in the standard.
Heading that direction is clearly not an efficient way to deal with
the concern, and would waste everybody's time in one-by-one
proposals and ad hoc decisions for each individual flag pictograph
to be added.

The UTC has a long history of putting a stake in the ground when it
encounters a character encoding problem which requires a *general*
solution, rather than a dribbling in of one-off decisions an item
at a time. And I think the tag proposal for dealing with
the representation of flag pictographs for regional subdivisions
shows precisely the kind of generality that we are looking for --
dealing with hundreds of potentially representable entities
with a general mechanism, rather than trying to encode them
all one-by-one.

Incidentally, back to the ostensible topic of this thread -- I don't
think the extended flag tag proposal currently addresses the
issue of how to represent a pictograph for a rainbow flag.
In that case I think a new registry mechanism might in fact make
sense -- and I have spelled out details of how one could reasonably
work in conjunction with the extended flag tag proposal in
feedback submitted on PRI #299.

--Ken






Peter



Received on Tue Jul 07 2015 - 10:12:00 CDT