On 10/30/2019 10:41 AM, wjgo_10...@btinternet.com via Unicode wrote:
At present I have a question to which I cannot find the answer.
Is the QID emoji format, if approved by the Unicode Technical
Committee going to be sent to the ISO/IEC 10646 committee for
consideration by that committee?
No.
As the QID emoji format is in a Unicode Technical Standard and does
not include the encoding of any new _atomic_ characters, I am
concerned that the answer to the above question may well be along the
lines of "No" maybe with some reasoning as to why not.
As you surmised.
Yet will a QID emoji essentially be _de facto_ a character even if not
_de jure_ a character?
That distinction is effectively meaningless. There are any number of
entities that end users perceive as "characters", which are not
represented by a single code point in the Unicode Standard (or 10646) --
and this has been the case now for decades.
Yet if QID emoji are implemented by Unicode Inc. without also being
implemented by ISO/IEC 10646 then that could lead to future problems,
notwithstanding any _de jure_ situation that QID emoji are not
characters, because they will be much more than Private Use characters
yet less than characters that are in ISO/IEC 10646.
What you are missing is that *many* emoji are already represented by
sequences of characters. See emoji modifier sequences, emoji flag
sequences, emoji ZWJ sequences. *None* of those are specified in 10646,
have not been for years now, and never will be. And yet, there is no de
jure standardization crisis here, or any interoperability issue for
emoji arising from that situation.
I am in favour of the encoding of the QID emoji mechanism and its
practical application. However I wonder about what are the
consequences for interoperability and communication if QID emoji
become used - maybe quite widely - and yet the tag sequences are not
discernable in meaning from ISO/IEC 10646 or any related ISO/IEC
documents.
There may well be interoperability concerns specifically for the QID
emoji mechanism, but that would be an issue pertaining to the
architecture of that mechanism specifically. It isn't anything to do
with the relationship between the Unicode Standard (and UTS #51) and
ISO/IEC 10646.
--Ken
