I never said anything about stability of geopolitical entities. I only mentioned stability of encoded character sequences.
Peter From: Ken Whistler [mailto:[email protected]] Sent: Friday, July 3, 2015 11:24 AM To: Peter Constable Cc: [email protected] 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
