Skip to content

Document why we need unquoted literals #478

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

Jump to bottom
Closed
stasm opened this issue Sep 18, 2023 · 2 comments
Closed

Document why we need unquoted literals #478

stasm opened this issue Sep 18, 2023 · 2 comments
Labels
design Design document or issues related to design resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. syntax Issues related with syntax or ABNF

Comments

@stasm
Copy link
Collaborator

stasm commented Sep 18, 2023

In #477, we're documenting the design of quoted literals. We should have a similar document about unquoted literals. In particular, we have good reasons for unquoted literals to be used as variant keys and option values. There are also use-cases for using them in operand positions, especially number literals.

I think a design doc about the unquotes literals would be useful in the context of the following ongoing discussions:

  • How close to nmtoken do we want the unquoted literals to be?
  • What syntax and sigils do we want to use for open/close elements?
  • If and how to allow negative numbers as unquoted literals?
  • If and how to make literals in operands and literals in keys/optvals follow the same syntax rules?
  • What syntax to adopt or recommend for namespacing?
@stasm stasm mentioned this issue Sep 18, 2023
Closed
@aphillips aphillips added syntax Issues related with syntax or ABNF design Design document or issues related to design labels Sep 19, 2023
This was referenced Sep 20, 2023
Merged
Closed
@aphillips aphillips added the resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. label Dec 14, 2023
@aphillips
Copy link
Member

Looking at the question list...

How close to nmtoken do we want the unquoted literals to be?

We have aligned on NCName instead of nmtoken

What syntax and sigils do we want to use for open/close elements?

This is a separate conversation that we are close to resolving. Alignment on NCName actually avoids this being in conflict.

If and how to allow negative numbers as unquoted literals?

We added number-literal to the syntax to permit this. Moving from +/- to hash-and-slash will remove the remaining issue. Of course, we need to agree to hash-and-slash...

If and how to make literals in operands and literals in keys/optvals follow the same syntax rules?

This is done?

What syntax to adopt or recommend for namespacing?

This is done.

Assuming we can reach consensus on spannables, I believe this will be complete. Do you still think we need a design doc to capture the requirement?

@stasm
Copy link
Collaborator Author

stasm commented Dec 16, 2023

You're right, the alignment on NCName helped a lot here.

My original request for a doc was made back when there were more open questions, e.g. about namespacing and syntax conflicts. Since then we've made good progress on many of these questions; others are being actively discussed in their own respective docs. Let's close this issue.

@stasm stasm closed this as not planned Won't fix, can't repro, duplicate, stale Dec 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
design Design document or issues related to design resolve-candidate This issue appears to have been answered or resolved, and may be closed soon. syntax Issues related with syntax or ABNF
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@aphillips @stasm