Skip to content

Conversation

@bhaible
Copy link
Contributor

@bhaible bhaible commented Mar 25, 2024

This assumes that PR #731 is applied.

In detail:

  • Since the reserved keywords start with a ., we need to talk about the keyword .match, not match.

  • Saying that "A reserved annotation starts with a reserved character" and "A reserved annotation MAY be empty" is a contradiction. Therefore, we need to distinguish a reserved annotation from a reserved body. This distinction is also useful because the reserved body occurs in two other places as well.

  • The statement that a reserved body contains "arbitrary text" is not true, since we have now decided that (unless empty) it must start and end with a non-whitespace character.

  • A nonterminal reserved-start does not exist. What is meant is reserved-annotation-start.

  • The statement "Implementations MUST NOT remove or alter the contents of a reserved annotation." needs to be constrained, because now implementations are SUPPOSED to trim whitespace around the reserved body.

This assumes that PR unicode-org#731 is applied.

In detail:

* Since the reserved keywords start with a `.`, we need to talk about the keyword `.match`, not `match`.

* Saying that "A _reserved annotation_ starts with a reserved character" and "A _reserved annotation_ MAY be empty" is a contradiction. Therefore, we need to distinguish a _reserved annotation_ from a _reserved body_. This distinction is also useful because the _reserved body_ occurs in two other places as well.

* The statement that a _reserved body_ contains "arbitrary text" is not true, since we have now decided that (unless empty) it must start and end with a non-whitespace character.

* A nonterminal `reserved-start` does not exist. What is meant is `reserved-annotation-start`.

* The statement "Implementations MUST NOT remove or alter the contents of a _reserved annotation_." needs to be constrained, because now implementations are SUPPOSED to trim whitespace around the _reserved body_.
@aphillips aphillips added syntax Issues related with syntax or ABNF fast-track Editorial change permitted to use fast-track merge rules Agenda+ Requested for upcoming teleconference labels Mar 25, 2024
@bhaible bhaible force-pushed the tweaks-for-syntax-md branch from adf8a54 to 0e3ffdb Compare March 25, 2024 16:29
@aphillips
Copy link
Member

@eemeli asked to review this before we merge it during the 2024-03-25 call.

@aphillips aphillips requested a review from eemeli March 25, 2024 18:18
@aphillips aphillips merged commit 21aec3c into unicode-org:main Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Agenda+ Requested for upcoming teleconference fast-track Editorial change permitted to use fast-track merge rules syntax Issues related with syntax or ABNF

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants