Add BNF grammar to explain things with less risk of ambiguity and to support implementing parsers

[christianhujer]

It would be great to have a BNF grammar to explain things with less risk of ambiguity and to support implementing parsers for checkers and alike.

Here's a start, using the ABNF from RFC5234.

I might come up with a PR if the idea of adding an ABNF grammar is accepted.

ABNF Definition of Conventional Commits

commitMessage = conventionalCommitHeader [body] [blankLine footer*]
conventionalCommitHeader = typePrefix headline LF
typePrefix = typeNoun [scope] [breakingChangeIndicator] ":" SP
typeNoun = "feat" / "fix" / "refactor" / noun
scope = "(" scopeNoun ")"
scopeNoune = noun
breakingChangeIndicator = "!"
headline = text LF
body = blankLine bodyLine bodyLine*
bodyLine = text LF
blankLine = LF
footer = footerToken footerTokenSeparator footerBody
footerTokenSeparator = footerTokenColonSeparator / footerTokenHashSeparator
footerTokenColonSeparator = ":" SP
footerTokenHashSeparator = SP "#"
footerToken = "BREAKING CHANGE" / dashSeparatedToken
dashSeparatedToken = token dashPlusToken*
dashPlusToken = "-" token
footerBody = *(text LF)
noun = token
text = *(WSP / VCHAR)
token = ALNUM *ALNUM
ALNUM = ALPHA / DIGIT

Projects may decide to put further restrictions on typeNoun, scopeNoun, and footerToken as they deem useful.

Declaration of Intended Compatibility

The intention of the ABNF grammar is to reflect what is written in the prose ruleset in the specification section. Any difference of the ABNF grammar from the specification ruleset is unintentional, by accident, and a mistake in the ABNF grammar. The ruleset takes precedence over the ABNF grammar.

References:

• RFC5234