Drop references to a "function registry" #983
Conversation
| This section defines the **_<dfn>default functions</dfn>_** | ||
| which are REQUIRED for conformance with this specification, | ||
| along with _default functions_ that SHOULD be implemented to support |
There was a problem hiding this comment.
This dilutes the nice parallel between the name REQUIRED/RECOMMENDED and the 2119 associated keywords REQUIRED/RECOMMENDED for the various "default functions", although I diluted it for clarity by using SHOULD instead of RECOMMENDED when I created this section.
Note that we previously discussed name this the "Default Function Set" with "function set" being a term. I'm not sure that "function set" is useful as a term?
I am also not sure if "default" is the right term, if we include the recommended items in it.
Finally, I note that "This section..." might not be right, since we broke it up into a list of documents.
Perhaps:
| This section defines the **_<dfn>default functions</dfn>_** | |
| which are REQUIRED for conformance with this specification, | |
| along with _default functions_ that SHOULD be implemented to support | |
| This section defines the **_<dfn>default functions</dfn>_**. | |
| This includes the **REQUIRED** _functions_, | |
| which are required for conformance with this specification, | |
| along with the **RECOMMENDED** _functions_ | |
| that SHOULD be implemented to support |
There was a problem hiding this comment.
Now I'm confused: Are the bold REQUIRED and RECOMMENDED intended to be understood as RFC 2119 key words, or not? I'm also confused by your suggestion including "required for conformance" about the former and "SHOULD be implemented" about the latter.
I would find it easier to understand if we had only one set of default functions, which includes both those that are REQUIRED and those that are RECOMMENDED for implementation, without creating separate category labels for those subsets.
There was a problem hiding this comment.
The idea is to clearly identify which functions and which options are required vs. recommended. The words are both 2119 keywords and "categories" (There is also the "proposed" state, for items not yet finalized that composes with REQUIRED/RECOMMENDED). We can discuss if the additional level of formality is needed in the call later today.
|
|
||
| Implementations MUST _accept_ each **REQUIRED** _function_ and | ||
| MUST _accept_ all _options_ defined as **REQUIRED** for those _functions_. | ||
| Implementations MUST _accept_ each REQUIRED _default function_ and |
There was a problem hiding this comment.
I wouldn't make this change: I don't think it is necessary.
|
|
||
| Implementations SHOULD _accept_ each **RECOMMENDED** _function_. | ||
| Implementations SHOULD _accept_ each RECOMMENDED _default function_. |
| @@ -34,34 +35,33 @@ Implementations MAY emit an _Unsupported Operation_ error for _options_ | |||
| or _option_ values that they cannot support. | |||
|
|
|||
| _Functions_ can define _options_. | |||
| An _option_ can be **REQUIRED** or **RECOMMENDED**. | |||
| An _option_ can be REQUIRED or RECOMMENDED. | |||
There was a problem hiding this comment.
The formatting here is intentional. Many such below. Won't repeat.
|
About the label: I was waiting to rename it based on discussion of what the name should be 😉 |
As discussed previously (most recently in #974 (comment)), we should update our terminology to no longer refer to a "function registry", a term that we don't actually define.
This PR applies that change, along with some incidental cleanup. The term default function is introduced, and used where appropriate.
The GitHub label
registryshould probably also be renamed asdefault-functions.