> Yet if QID emoji are implemented by Unicode Inc. without also being > implemented by ISO/IEC 10646 then that could lead to future problems,
Neither Unicode Inc. or ISO/IEC 10646 would _implement_ QID emoji. Unicode would provide a specification for QID emoji that software vendors could implement, while ISO/IEC 10646 would not define that specification. As Ken mentions, there are already many emoji in use inter-operably based on specifications provided by Unicode but not by ISO/IEC 10646. Ken's other point is also worth stressing: there are inter-op issues inherent to the architecture of the QID mechanism. If adopted as a Unicode spec, any software vendor could choose to implement anything they might want as a QID emoji sequence, and there would be no guarantee that any other software would interoperate with that beyond a very minimum: if other software supported the QID mechanism, it would recognize the sequence as a QID sequence, and might handle it as a unit for segmentation purposes (selection, line breaking), but only render the base emoji character in a legible way and nothing more. Moreover, it's possible that two vendors might implement the same QID sequence with significantly different appearances, enough to connote different meanings. (Think of issues from recent years in which the major vendors had significantly different appearances for the same emoji character. Then extend that possibility to every QID sequence that any vendor implements.) Also, it's entirely possible that two different vendors might implement _different_ QID sequences with similar appearances and semantic intent. The PRI doc mentions the possibility of a registry for QID sequences; a key benefit of a registry is that it may mitigate against these non-interop risks. But the current proposal does not in fact provide any mitigations for these issues other than the possibility that a QID sequence might be at some point become an RGI sequence. Peter -----Original Message----- From: Unicode <unicode-boun...@unicode.org> On Behalf Of Ken Whistler via Unicode Sent: Wednesday, October 30, 2019 12:19 PM To: wjgo_10...@btinternet.com Cc: unicode@unicode.org Subject: Re: New Public Review on QID emoji 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
