Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Literal keys contents / values #1036

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

Merged
merged 3 commits into from
Feb 21, 2025
Merged

Literal keys contents / values #1036

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
72be269
Literal keys contents / values
macchiati Feb 21, 2025
777dd31
Apply suggestions from code review
aphillips Feb 21, 2025
df10557
fix merge fiasco
aphillips Feb 21, 2025
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
14 changes: 10 additions & 4 deletions spec/syntax.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -369,7 +369,7 @@ otherwise, a corresponding _Data Model Error_ will be produced during processing
- _Duplicate Variant_:
Each _variant_ MUST use a list of _keys_ that is unique from that
of all other _variants_ in the _message_.
_Literal_ _keys_ are compared by their contents, not their syntactical appearance.
_Literal_ _keys_ are compared by their _string values_, not their syntactical appearance.

```abnf
matcher = match-statement s variant *(o variant)
Expand Down Expand Up @@ -470,7 +470,7 @@ that matches all values for a given _selector_.

The value of each _literal_ _key_ MUST be treated as if it were in
[Unicode Normalization Form C](https://unicode.org/reports/tr15/) ("NFC").
Two _literal_ _keys_ are considered equal if they are canonically equivalent strings,
Two _literal_ _keys_ are considered equal if their _string values_ are canonically equivalent strings,
that is, if they consist of the same sequence of Unicode code points after
Unicode Normalization Form C has been applied to both.

Expand Down Expand Up @@ -742,8 +742,9 @@ escaped as `\\` and `\|`.

An **_<dfn>unquoted literal</dfn>_** is a _literal_ that does not require the `|`
quotes around it to be distinct from the rest of the _message_ syntax.
An _unquoted literal_ MAY be used when the content of the _literal_
contains no whitespace and otherwise matches the `unquoted-literal` production.
An _unquoted literal_ MAY be used when the _string value_ of the _literal_
matches the `unquoted-literal` production.
It will thus contain no whitespace (nor certain other characters).
Implementations MUST NOT distinguish between _quoted literals_ and _unquoted literals_
that have the same sequence of code points.

Expand All @@ -755,6 +756,11 @@ literal = quoted-literal / unquoted-literal
quoted-literal = "|" *(quoted-char / escaped-char) "|"
unquoted-literal = 1*name-char
```
The **_<dfn>string value</dfn>_** of a _literal_
for _unquoted literals_ is the text content of that _literal_;
or for _quoted literals_, the text content of that _literal_
after removing the enclosing `|` characters
then unescaping any escaped characters.
Comment on lines +759 to +763
Copy link
Collaborator

Choose a reason for hiding this comment

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

This feels a bit clumsy, but not objectionably so.


#### Names and Identifiers

Expand Down