Well for now a reasonnably stable standard exists: URLs, that can point to
a collection of pagenames (each site can choose its own registry to
name/encode the flags)
URLs are then returening images (you can make a site that can return images
in several formats and with variable sizes as well or with some transforms
such as rotations, flips, animations...
Instad of just isolated URLs, you can organize them into a base URL or
static URL with query (acting as a resolver address), and then append the
URN (name or code of the flags, which can include historic variants), and
then allow the base URL to be replaced : keep just the part of the URL (end
of pathname, or part of the query string) as "standard" and you get what is
generally termed a "mirror". Mirrors however are not nececessarily bound to
remain in the web, they can be any locals store (e.g in a local IP file, or
a folder in your filesystem).
Basically, even the existing FOTW site (and its mirrors) can be already
seen as supporting these relatively stable URNs (provded that the site is
not retructuring constantly its URLs and file names are kept or at least
resolved by keeping internally redirecting links)
So what is need is just a way to support URLs. However URLs today can be
IRIs and contain most of Unicode and we cannot duplicte this code. It is
however possible to do that by using the chracter sets used by Punycode
(for domain names). But if FOTW just designs a naming convnetion for the
paths it supports, so that it will use only a restricted set (ASCII
letters, digits, and punctuation, with only some restrictions on slashs and
controls) it is possible to use them as partial path names (excluding also
file extension in file names) that can be used as URNs, and act as
identifiers (all other parameters: size, transforms, image formats...
should be separate parameters). And with this restricted set, it is
possible to encode them in a stable (but still very extensible) way.
2015-05-20 19:35 GMT+02:00 Doug Ewell <doug_at_ewellic.org>:
> William_J_G Overington <wjgo underscore 10009 at btinternet dot com>
> wrote:
>
> > Hopefully the people in charge of the codes to be used for the flags
> > will agree never to reuse a code.
>
> Normally I would completely agree about the need for archival stability.
>
> In this case, however, we are talking about flags used primarily as
> emoji, like the one in my signature block. People will pop these flags
> into their text messages alongside "party" or "celebration" icons. I'm
> not sure the requirement for stability is quite as critical as it might
> be.
>
> However...
>
> > Whether they do or not, would it be good to add an option into the tag
> > coding of the flags whereby at the end one may optionally add TAG
> > COLON then at least four TAG DIGIT characters, those TAG DIGIT
> > characters representing the year?
>
> It's remarkable how similar this suggestion is to a discussion between
> Philippe and me two years ago. There is currently no well-known coding
> system for flags -- the owner of the "Flags of the World" site doesn't
> know of one -- and there should be. (The term "flag code" already has
> two meanings that are very different from this, which makes it hard to
> find information.)
>
> Getting UTC to accept the extended syntax of a standard like this would,
> of course, require that the standard gain reasonable acceptance and
> popularity beforehand. Requiring it to become an ISO standard might not
> be unreasonable.
>
> If you want to discuss this specific idea further, please write to me
> privately and *not to the list*.
>
> --
> Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
>
>
>
Received on Wed May 20 2015 - 13:39:45 CDT
This archive was generated by hypermail 2.2.0 : Wed May 20 2015 - 13:39:45 CDT