On 9/11/2016 5:40 AM, Christoph Päper wrote:
>> "Took no action" generally means "rejected".
> Can anyone explain then, why [L2/16-128] seems to have been “rejected” and still made it into selection.html?
Not all documents in the UTC document register are born equal.
If a document in the register is explicitly a *proposal* to encode X at
code point Y in version Z of the Unicode Standard, then that requires a
recorded decision by the UTC. If the UTC takes up such a document, and
the minutes for the agenda item in question note only "UTC took no
action at this time", that clearly indicates that as of that date the
UTC had not *accepted* the proposal. It *might* mean that the proposal
was rejected, but a rejection is often then also indicated with some
action item to follow up with the proposal author. If the proposal
author is in the room for the discussion, they might simply take notes
about some possible future revision of the proposal, and no action need
be formally minuted. In only a few instances would a rejection be
minuted as a formal decision -- that case is generally limited to some
encoding proposals that are objectionable in ways that the UTC
determines are unlikely to be fixable, and which thus should not be
re-discussed in future meetings.
Other kinds of documents in the register (and associated agenda items to
discuss them) may not require minuting of formal decisions by the UTC at
all.
>
>
> Same minutes as above:
>
>> >E.1.11 Additional Emoji selection factor [Emoji SC/Edberg, L2/16-128]
>> >
>> >Discussion. UTC took no action at this time.
> [L2/16-128]:http://www.unicode.org/L2/L2016/16128-additional-emoji-selection-factor.pdf
>
> This was the proposed text to be added:
>
In a case like that, the UTC doesn't necessarily control the exact text
of a web page. The emoji selection factors are not a formal
specification or a published standard. They are guidelines that the
Emoji Subcommittee uses to help organize and rationalize its
consideration of all the various proposals that get submitted for
encoding more emoji characters. That helps the Emoji Subcommittee
assemble better summarized proposals to bring to the UTC when it is time
to standardize some selected set of new emoji and assign code points for
them for a new version of the Unicode Standard.
L2/16-128 was brought to the attention of the UTC by the Emoji
Subcommittee to let the UTC know they were considering another selection
factor, and to allow discussion and let people raise objections or make
other suggestions. Once the Emoji Subcommittee gets that feedback, they
could then go back and update the relevant web page regarding selection
factors. No UTC decision is required for something like that. People who
have a problem with one or another of the selection criteria that the
Emoji Subcommittee has been using can always submit feedback, if they
wish, and I'm sure the Emoji Subcommittee would take such feedback under
advisement.
In general, I would advise people who are interested in the UTC and UTC
process to not treat the UTC minutes as legal documents that require
their wording to be litigated line by line. Minutes of standards
organizations function primarily as their institutional memory about
decisions taken and associated actions to follow up on decisions. The
wording of such minutes tends to be brief and telegraphic, because a lot
of topics are taken up, and a lot of decisions and actions have to be
recorded quickly -- and their wording is usually aimed at being clear to
the people doing the actual maintenance of the standard(s) or other
specifications. They are not meeting transcripts, and they do not
attempt to recapitulate discussions nor do they provide detailed
rationales for every decision taken by the committee.
If something is unclear about some decision taken by the UTC, or the
outcome of the discussion of some particular topic is unclear and you
desire elucidation, the best course is often simply to ask somebody who
attended the meeting about it. Many participants in the UTC meetings
*do* monitor this discussion list, for example.
--Ken
Received on Thu Sep 15 2016 - 19:28:43 CDT
This archive was generated by hypermail 2.2.0 : Thu Sep 15 2016 - 19:28:44 CDT