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.
- 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.
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.
Peter
From: Unicode [mailto:unicode-bounces_at_unicode.org] On Behalf Of Erkki I Kolehmainen
Sent: Thursday, July 2, 2015 5:42 PM
To: verdy_p_at_wanadoo.fr; 'Mark Davis ☕️'
Cc: 'Doug Ewell'; 'Unicode Mailing List'
Subject: VS: Adding RAINBOW FLAG to Unicode (Fwd: Representing Additional Types of Flags)
I cannot but agree with Mark! Thus, please…
Sincerely, Erkki
Lähettäjä: Unicode [mailto:unicode-bounces_at_unicode.org] Puolesta Philippe Verdy
Lähetetty: 2. heinäkuuta 2015 12:02
Vastaanottaja: Mark Davis ☕️
Kopio: Doug Ewell; Unicode Mailing List
Aihe: Re: Adding RAINBOW FLAG to Unicode (Fwd: Representing Additional Types of Flags)
The political subject is immediately related to the designation of flags and their association to ISO 3166-1 and -2 encoded entities. Even if you don't like it, this is very political and for a standard seeking for stability, I wonder how any flag (directly bound to specific political entities at specific dates and within some boundaries which may be contested) can be related to ISO 3166 and its instability (and the fact that ISO 3166 entities have in fact also no defined borders, so that ISO 3166-2 is just a political point of view from the current ruler of the current ISO 3166-1 entity).
All this topic is political. In fact the real flags are not even encoded with RIS, not even for current nations (and there's still a problem to know what is a recognized nation, even when just considering the UN definition. Political entities are defined but with fuzzy borders, they just represent in fact some local governments, not necessarily their lands, people, or cultures, and in some cases they are in exil or not even ruling: their seat in the UN is vacant and they exist only on the paper, but even UN members disagree about which treaty they recognize).
Consider the case of Western Sahara (which no longer exists except on the paper as a dependency of Spain that has abandoned it completely) and with two governments competing to control the territory (Morocco controlling most of it, another part claimed by Mauritania then abandonned, another part left without infrastructures, and many refugees left de facto in Mauritania or Algeria). None of the two autorities designate that territory as "Western Sahara". So it no longer exists (and will likely never exist again).
The frozen status of Antarctica has not created any new country or territory, even if there's a sort of joint administration: that adminsitration does not suppresses the existing claims (and new claims that have been made since its creation). So this area has no well defined flag and various falgs are used informally plus national flags for each claim and sometimes specific regional flags created ad hoc. The use of RIS for ISO 3166-1 and its limited extension for ISO3166-2 (slightly modified) does not resolve the problem.
In really there's still no standard way to encode flags unambiguously and in a stable way. We'd like to have FOTW (Flags of the World) contributors to propose their own scheme. But it will not be compatible with the current RIS solution or the proposed extension. If ever such standard emerges, it will require encoding a new set of characters.
An alternative would be to embed an URN (not reencoded) between some pairs of controls (to embed an object by reference) and use that sequence after a White flag symbol with a joiner.
The URN scheme being the best long term solution (and preferable to URLs bound to specific servers), but we could in fact a generic URI encapsulation (supporting URNs and URLs).
It could be used then for representing various kinds of entities, and then link them to specific forms: flags, banners, flying flag, flag over a person face, micni location maps, "flag maps"... Programs not recognizing the encoded entities would have a very simply way to scan over the encasulated URI representing some an specified objects. OTher programs will recognize some specific URI schemes. RIS will then be something of the past, obsoleted because it was non neutral, politcally and culturally oriented, incomplete, and fundamentally unstable since the begining... For now we just have some set of flags promoted only to support the immediate support for interconnecting propriatary messaging services. But all this came without a correct review of what was really needed.
2015-07-02 7:16 GMT+02:00 Mark Davis ☕️ <mark_at_macchiato.com<mailto:mark_at_macchiato.com>>:
Please take political discussions elsewhere; they do not belong on this list.
The point about the boundaries of regions changing over time, and flags being associated with a former set of boundaries could have been made in a few sentences. Not only would it have avoided politics, it would have been more likely that people would actually read it (the likelihood being inversely proportional to the length).
Mark<https://google.com/+MarkDavis>
— Il meglio è l’inimico del bene —
On Thu, Jul 2, 2015 at 4:12 AM, Philippe Verdy <verdy_p_at_wanadoo.fr<mailto:verdy_p_at_wanadoo.fr>> wrote:
…
Received on Thu Jul 02 2015 - 19:57:08 CDT
This archive was generated by hypermail 2.2.0 : Thu Jul 02 2015 - 19:57:08 CDT