It is not the same. The <numeric identifier> needs to be 0, a positive digit, or two or more digits starting with a positive digit making the entire identifier positive. Essentially a uint vs an int. A <digit> can be any integer positive or negative so your variant would allow for negative number identifiers which is not allowed.

If <digit> could be a negative integer, I would agree with you, but it is defined in the same document as:
<digit> ::= "0" | <positive digit>

The only real difference between <digit> and <positive digit> is that the <digit> class allows for 0 while <positive digit> does not. So for any multidigit number, as it must not start with a '0', <digit> cannot be used as the first character. Instead a multidigit number must start with a <positive digit>, after which any single digit number can be use, and so <digits> (which is a collection of one or more of the <digit> class) is appropriate.

If I am not understanding this correctly, then I would ask for an example of a number that would be allowed under one form but not the other.

Doh! My bad. You are correct on all counts. Knew I should have reviewed the BNF again before answering. 👼

@jameskregar, is the longer form difficult to understand? The current form follows the descriptive text of the standard. It might be true that it can be simplified, but then the reader has to think harder about the implications. That fact probably saved us at least one round of explanations when we were working up the Regex last year, and the year before that.

With BNF, I generally expect that a literal will only be used when it is impossible (or very awkward) to define an element with other elements alone. When I looked at it and looked at the definitions of <digit> and <postiive digit>, I immediately wondered why it could not be just <digit>. As such, I did spend some extra time trying to figure out what I was missing when reading this BNF.

So, is it difficult to understand: no, but it did cause me to re-read the digit definition 2 or 3 times to make sure I wasn't missing something. If I was referencing the BNF while reading the descriptive text, then yes, maybe the current way would make more sense.

My vote is usually with the simplest form for BNF, and having only 2 options instead of 3 would be slightly simpler. But in the end, either method is technically correct, and this could be more of a style judgement.

If the decision is to keep it as is, then I will close the issue, with no hard feelings.

Ya, I think my inclination would be to fix it as well. Given the definition of <digit> as "0" | <positive digit>, I think my rationale above may have been spurious. It really doesn't seem like too much abstraction to simplify it. But given how difficult it is to push these kinds of changes through, I think that it should be tagged "Needs a PR" and then closed if you aren't willing to champion the PR. I don't think I'll have the time for it.

Well, I am completely new to Github and have never actually used Git, so I don't know how to PR (I assume PR = Pull Request). If someone wants to point me towards a basic tutorial, I'll give it a shot, otherwise I will close it as "Needs a PR".

It's easy, first you fork the repo, then when you're ready with the changes, you start a PR. Here's some links that might be useful:

https://gist.github.com/MarcDiethelm/7303312
https://github.com/semver/semver/blob/master/CONTRIBUTING.md
https://github.com/firstcontributions/first-contributions

This is basically a duplicate of parts of #258, that were pulled out separately too as #575 where already suggestions for simplifications are included that only wait for decision by maintainers to become a PR.