3 ms·

The EBNF in the page does not match the textual description: - "ALPHANUMERIC" is only letters, not numbers - "BUILD_REF" can contain dashes/hyphens "-"

by zvr 2y ago

The EBNF in the page does not match the textual description: - "ALPHANUMERIC" is only letters, not numbers - "BUILD_REF" can contain dashes/hyphens "-" - "GIT_COMMIT_REF" is the letter "g" and a single hex character - "BUILD_REF" and "SOURCE_REF" may be empty, since they are 0 or more repetitions - "TIMESTAMP" is arbitrary numbers, so month or hour may be "99" for example

saghm 2y ago
While I understand the point you're making, some of these don't seem like they should _technically_ be an issue in terms of whether a parser following the textual descriptions would work on the actual thing. Any parser written to accept an alphanumeric string should presumably accept a purely alphabetic one, and I'm pretty sure a "ref" in git doesn't just mean a hash but also refers to branches and tags, either of which could have a name in the format you describe. Given that the point of EBNF is to define grammar to a degree of precision and conciseness that textual descriptions can't match, I don't think it's a super big deal. From the perspective of building a parser from EBNF, the names of the tokens don't matter.
- viraptor 2y ago
  > don't seem like they should _technically_ be an issue Sure, people can ignore the EBNF. But if you expect that, then why publish it at all? EBNF is specifically used to describe formats and get rid of ambiguities present in text description. Not being careful with it just undermines whole idea.
  - saghm 2y ago
    I'm not saying to ignore the EBNF; I'm saying to ignore the identifiers used in the EBNF. It doesn't matter that ALPHANUMERIC is alphabetic only because the identifier is just used as a shorthand for the tokens it represents. You could literally put anything down instead of ALPHANUMERIC and it would work the same, so the fact that the name isn't a perfectly precise description isn't a big deal.
    - zvr 2y ago
      No, it's the opposite problem. For example the text talks about "ASCII alphanumerics [09-A-Za-z]", the relevant EBNF rule is called "ALPHANUMERIC", but its definition is only letters. It's not the problem that it's called "ALPHANUMERIC" -- it's that it should describe alphanumerics and it doesn't.
- zvr 2y ago
  On the git part: the text only mentions "git commit checksum", not "branches and tags" -- and it couldn't, since these are not immutable nor are they restricted to hex characters. My point above is that the EBNF defines "GIT_COMMIT_REF" to be the letter "g" and a _single_ hex character. So "GIT_COMMIT_REF" may be "g0", "g1", ... "g9", "gA", ... "gF", "ga", ..., "gf". That's it. Which obviously contradicts the text and the intention.

by zvr 2y ago

saghm 2y ago

While I understand the point you're making, some of these don't seem like they should _technically_ be an issue in terms of whether a parser following the textual descriptions would work on the actual thing. Any parser written to accept an alphanumeric string should presumably accept a purely alphabetic one, and I'm pretty sure a "ref" in git doesn't just mean a hash but also refers to branches and tags, either of which could have a name in the format you describe. Given that the point of EBNF is to define grammar to a degree of precision and conciseness that textual descriptions can't match, I don't think it's a super big deal. From the perspective of building a parser from EBNF, the names of the tokens don't matter.

viraptor 2y ago
> don't seem like they should _technically_ be an issue Sure, people can ignore the EBNF. But if you expect that, then why publish it at all? EBNF is specifically used to describe formats and get rid of ambiguities present in text description. Not being careful with it just undermines whole idea.
- saghm 2y ago
  I'm not saying to ignore the EBNF; I'm saying to ignore the identifiers used in the EBNF. It doesn't matter that ALPHANUMERIC is alphabetic only because the identifier is just used as a shorthand for the tokens it represents. You could literally put anything down instead of ALPHANUMERIC and it would work the same, so the fact that the name isn't a perfectly precise description isn't a big deal.
  - zvr 2y ago
    No, it's the opposite problem. For example the text talks about "ASCII alphanumerics [09-A-Za-z]", the relevant EBNF rule is called "ALPHANUMERIC", but its definition is only letters. It's not the problem that it's called "ALPHANUMERIC" -- it's that it should describe alphanumerics and it doesn't.
zvr 2y ago
On the git part: the text only mentions "git commit checksum", not "branches and tags" -- and it couldn't, since these are not immutable nor are they restricted to hex characters. My point above is that the EBNF defines "GIT_COMMIT_REF" to be the letter "g" and a _single_ hex character. So "GIT_COMMIT_REF" may be "g0", "g1", ... "g9", "gA", ... "gF", "ga", ..., "gf". That's it. Which obviously contradicts the text and the intention.