Skip to content

Explicitly allow implementations to support additional option values #924

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Explicitly allow implementations to support additional option values #924

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions spec/registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,8 @@
This section describes the functions for which each implementation MUST provide
a _function handler_ to be conformant with this specification.

Implementations MAY implement additional _functions_ or additional _options_.
In particular, implementations are encouraged to provide feedback on proposed
_options_ and their values.
Implementations MAY implement additional _functions_,
additional _options_, and additional _option_ values.
Comment on lines 3 to +7
Copy link
Member

@aphillips aphillips Nov 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This section describes the functions for which each implementation MUST provide
a _function handler_ to be conformant with this specification.
Implementations MAY implement additional _functions_ or additional _options_.
In particular, implementations are encouraged to provide feedback on proposed
_options_ and their values.
Implementations MAY implement additional _functions_,
additional _options_, and additional _option_ values.
This section defines the _functions_ which are REQUIRED for conformance with this specification,
along with **optional** _functions_ that SHOULD be implemented to support
additional functionality.
Each **standard** _function_ MUST be defined and
MUST accept all standard _options_ and _option_ values listed in this specification.
When provided by an implementation, each **optional** _function_
MUST accept all standard _options_ and _option_ values listed in this specification.
Implementations SHOULD implement _options_ and _option_ values that are marked as **optional**.
Implementations MAY implement _functions_ not defined in this specification.
Such functions MUST use an implementation-defined _namespace_.
In addition, implementations are encouraged to provide mechanisms for users to
register and use user-defined _functions_ and their associated _functional handlers_.
Implementations MAY implement additional _options_ not defined here.
Such _options_ MUST use an implementation-specific _namespace_ .
Implementations MAY implement additional _option_ values for _options_ defined here,
although care needs to be exercised to ensure interoperability
and to avoid collisions with future standardization.
There is no namespace mechanism for _option_ values,
however, the [stability policy](#stability-policy) for this specification
permits only the ranges a-z, A-Z, and 0-9 in _option_ values.
Implementation-defined values SHOULD use a distinguishing character
or character sequence, such as by prefixing an underscore,
to ensure that they don't collide with future standardization.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such functions SHOULD use an implementation-defined namespace.
...
Such options SHOULD use an implementation-specific namespace .

Shouldn't that be a MUST, to avoid collisions with later additional standard functions / options?

although care needs to be exercised to ensure interoperability

Even though we don't have namespaces for option values, I suggest we consider recommending that when an additional option values is added to a standard or optional option, that it start with "_" to avoid collision with future standard or optional options.

That is not as powerful as namespaces, since it doesn't help to prevent collisions with other implementations, but at least is future-proofing against Unicode's future option values.

Copy link
Member

@aphillips aphillips Nov 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should be MUST.

Our stability policy (soon to be effective) says:

Updates to this specification will only reserve, define, or require function names or function option names consisting of characters in the ranges a-z, A-Z, and 0-9. All other names in these categories are reserved for the use of implementations or users.

So we can recommend something like what you mention or just call out the stability guarantee explicitly here. I'll make an edit to that effect. I edited my suggestion above.


> [!NOTE]
> The [Stability Policy](/spec#stability-policy) allows for updates to
Expand Down