Useful terminology

[macchiati]

It would be useful to have some additional terminology for talking about messages, and there is a bit of a mismatch between the BNF and how we need to talk about messages.

For example:

On https://github.com/unicode-org/message-format-wg/blob/main/spec/syntax.md#selection, we refer to a single 'selector'. And we need a term for that. But in the syntax discussion, that doesn't make any sense, because a selector is the entire match line:
Selector ::= 'match' ( '{' Expression '}' )+

We would have to say "expression", but that is such a vague term that it doesn't work in flowing text.

We are also referring to Selector as a the line in a message, or a 'piece of code that implements a selection mechanism', or 'an entity in the registry' like a plural selector, making it easy to misunderstand what is being discussed.

Similarly, we don't have defined term for the list of VariantKeys that occur in a Variant; the boldfaced part below:

when one female {...}

So I suggest we review the terminology so that we have consistency between the BNF and textual descriptions, and that terminology distinguishes between entities need to be distinguished for clarity.

[aphillips]

I'm encountering the same desire in my reviews of various PRs. Note that I also have in our agenda the review of normative language (2119) and will pack this item with that.

(the following commentary is aimed at the group, not a comment on Mark's text):

Careful definition and use of terms makes it easier to understand what is being specified.

One of the luxuries that we have in W3C spec tools (like Respec or bikeshed) is that it's straightforward to declare a term's definition and the mark occurrences elsewhere in the doc (auto-linking to the definition). Or even across specs (which is why I18N Glossary exists).

I think that we need to think in terms of defined terms and then use them consistently, adding more as needed.

[echeran]

Agreed. It has been a challenge for a long while (ex: #30 superseded by #80). It also makes discussions more difficult: different people may use different terms to mean the same thing, or imply different meanings from the same term. There have been instances of people talking past each other as a result.

[aphillips]

In our call of 2023-02-06 we resolved to highlight terms when defined and highlight their subsequent use in the spec(s). It's not quite as sophisticated as what e.g. Respec or Bikeshed do.

Probably we should use id linking instead of highlighting (hint: see here for examples)

We'll have to backfill existing terminology, of course, and ensure consistency after. I have a task to start some of this.