commonmark
Inconsistent "may not" vs. "must not"
"May not" has opposite colloquial and formal interpretations, which is why a lot of documents follow https://www.ietf.org/rfc/rfc2119.txt and use "must not" to avoid any ambiguity.
The CommonMark spec uses "must not" in some places but also "may not" in others. I think it would be clearest to stick with "must not" where possible.
What's the ambiguity supposed to be? "You may not take out the trash" seems unambiguously a prohibition. It cannot mean "you are permitted not to take out the trash."
What's the ambiguity supposed to be? "You may not take out the trash" seems unambiguously a prohibition. It cannot mean "you are permitted not to take out the trash."
Informally, yeah. That's a pretty strong convention. But there's nothing in the grammar making it invalid to parse and interpret it as the latter in English. The need for precision over convention is why the CommonMark spec exists in the first place, if I understand correctly.
This definitely has some implications.
- Although the intention may be obvious to a native speaker, it may not be clear to someone who understands basic English and only knows "may" as a signifier of an option. They can probably manage it or realize to look it up, but "must not" is just as concise and completely avoids the issue.
- I think there would also be less chance for confusion if "may not" and "must not" didn't both appear in the spec. The fact that there are different phrases could suggest the possibility that they may mean different things (again, from the perspective of someone not as familiar with colloquial English).
- A lot of specs adhere to RFC 2119. Just casting a basic net: https://github.com/search?q=RFC+2119&type=code (Observe how many documents include "The key words "MUST"", etc.)
- Also note that RFC 2119 specifically states: "This word, or the adjective "OPTIONAL", mean that an item is truly optional." It's not the end of the world if the CommonMark spec does no adhere to this, but this means that in fact "you are permitted not to take out the trash" would actually be the only valid interpretation in a lot of other spec documents.
- There are also certainly some related colloquial phrases where "may not" indicates an option:
- "I may not take out the trash today after all."
- "I'm scheduling an optional meeting. You may or may not choose to attend, as you see fit."
As someone who's been involved for over a decade with documents (with an international audience) that adhere to RFC 2119, I can say I certainly appreciated the value of sticking with it when it comes to "must not".
There are also certainly a few small additional benefits, like being able to search for "may" vs. "must" to quickly identify optional vs. mandatory things. But I think the most useful thing is the easy win to dispel any ambiguity.