would an antlr pURL grammar be useful?

[Scanteianu]

As the title says - the grammar can be accompanied by code in different languages to parse pURL, and can serve as a machine readable formal spec for what is allowed to be a pURL. I'd be happy to work on this.

https://github.com/antlr/antlr4 antlr "supports 10 target languages (Cpp, CSharp, Dart, Java, JavaScript, PHP, Python3, Swift, TypeScript, Go)", so writing a grammar in antlr would benefit anyone trying to write a parser in any of the above

[jkowalleck]

already working on it - feel free to collaborate:

• ▶️ spec: add grammar (ABNF) purl-spec#578 -- please give this a carefull review
• issues: https://github.com/package-url/purl-spec/issues?q=is%3Aissue%20state%3Aopen%20grammar
• PRs: https://github.com/package-url/purl-spec/pulls?q=is%3Apr+is%3Aopen+grammar

[jkowalleck]

https://github.com/antlr/antlr4 antlr "supports 10 target languages

eventually, all the existing libraries will be spec compliant, once the grammar is final and part of the standard.

Are you writing own PURL parsers/makers, or are you using the ones in here: https://github.com/orgs/package-url/repositories
I mean, there are existing libraries for Python, JavaScript, PHP, Go, etc ... you should consider contributing to existing libs

[Scanteianu]

already working on it - feel free to collaborate:

• ▶️ spec: grammar purl-spec#578 -- please give this a carefull review
• issues: https://github.com/package-url/purl-spec/issues?q=is%3Aissue%20state%3Aopen%20grammar
• PRs: https://github.com/package-url/purl-spec/pulls?q=is%3Apr+is%3Aopen+grammar

I don't recognize this format (admittedly, I only know antlr and yacc). Do you know of any good parser generator libraries for it? I think antlr is great specifically because I can either write a new parser or eventually modify the existing ones to use the same grammar

[jkowalleck]

I don't recognize this format (admittedly, I only know antlr and yacc). Do you know of any good parser generator libraries for it? I think antlr is great specifically because I can either write a new parser or eventually modify the existing ones to use the same grammar

This PR uses ABNF: package-url/purl-spec#578
ABNF itself is defined in RFC 5234: https://datatracker.ietf.org/doc/html/rfc5234

ABNF is a standardized grammar notation widely used in internet protocol specifications (HTTP, SIP, email, URI syntax, and many others). Unlike BNF, which exists in many competing variants and never had a single authoritative standard, ABNF has a formal, stable definition.

Since this PR is for PackageURL, it makes sense to use ABNF — it’s the same standardized grammar notation used in the IETF URL/URI specification (RFC 3986). ABNF is the formal way URLs, URIs, email addresses, and many other internet identifiers are defined. Using it here keeps the grammar aligned with established internet standards and makes the syntax easier for other tools and implementers to understand.

It’s worth noting that ABNF isn’t a parser‑generator language like ANTLR or yacc. It’s a notation for describing grammars independently of any specific toolchain. Various libraries can parse ABNF and generate validators or parsers from it, but ABNF itself doesn’t prescribe a particular generator. That’s why you won’t find a single “official” ABNF parser generator — instead, tools adopt it because it’s a well‑recognized, interoperable format for expressing grammars.

[Scanteianu]

Ah, this makes sense. in that case, maybe what I can try to do is to come up with an antlr grammar derived from your work and try to implement that. You're definitely the expert on how the purl works, but my goal would be to eventually integrate it into all the various parsers to be able to provide some level of standardization and hopefully simplification.

[mjherzog]

To reinforce Jan's point we are starting with an ABNF grammar because PURL is defined as a URL: https://package-url.github.io/www.packageurl.org/docs/purl/specification#a-purl-is-a-url.
Jan has led the effort to create the ABNF grammar and we expect to add it to ECMA-427 (PURL) at some point soon.
Like any spec we need implementations to validate the spec so an ANTLR implementation would be very welcome. You could create this as a project/repo under the package-url org on GitHub or on your own.
Note also that https://package-url.github.io/www.packageurl.org/docs/getting-started/toolgrid shows the tools that currently implement PURL and/or VERS with a focus on FOSS - there are also many commercial tools that implement PURL.

[Scanteianu]

Excellent, thanks both. It makes sense to use the format standard to URLs for a formal spec, and I'll forge ahead with an antlr poc for practical use, trying to keep the structure similar to the formal one Jan is proposing. I'll start with a POC in my GitHub, and I'll put a link to it here when I have something to show, and then we can find it a home in the package-url org

…

On Wed, Apr 22, 2026, 20:42 Michael Herzog ***@***.***> wrote: *mjherzog* left a comment (package-url/community#24) <#24 (comment)> To reinforce Jan's point we are starting with an ABNF grammar because PURL is defined as a URL: https://package-url.github.io/www.packageurl.org/docs/purl/specification#a-purl-is-a-url . Jan has led the effort to create the ABNF grammar and we expect to add it to ECMA-427 (PURL) at some point soon. Like any spec we need implementations to validate the spec so an ANTLR implementation would be very welcome. You could create this as a project/repo under the package-url org on GitHub or on your own. Note also that https://package-url.github.io/www.packageurl.org/docs/getting-started/toolgrid shows the tools that currently implement PURL and/or VERS with a focus on FOSS - there are also many commercial tools that implement PURL. — Reply to this email directly, view it on GitHub <#24?email_source=notifications&email_token=ACQFGI6SE6MRODNAIRZP27D4XEHCLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZHEYDKNBYHA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4299054884>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQFGI4ZBGKNQP2Y2GWM4W34XEHCLAVCNFSM6AAAAACYCRU6QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOJZGA2TIOBYGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Scanteianu]

for now i've done a minimal implementation in abnf, details here: package-url/purl-spec#578 (comment) i think we should drive that to completion (ie: fix the grammar and then ensure the validator passes all the tests), and then focus on the antlr version (i think antlr is a lot more powerful in terms of being able to generate parsers in multiple languages, and it's a lot more supported than this library, but a grammar in any format is much better than none at all, and @jkowalleck has very valid reasons for chosing that format).