spec: grammar

[jkowalleck]

• fixes publish the grammar #535

[jkowalleck]

The ABNF is done according to latest spec, ready for review.

possible followup: have a pipeline that checks the test-suite against that ABNF.

[ppkarwasz]

@jkowalleck, thanks for submitting this!

I'll check it in detail later, right now these two problems show up:

[ppkarwasz]

Thanks again for the PR! 🎉

I only spotted a couple of issues, the rest looks solid.

Random thought while reading: what if we defined a common set of productions for the basic character sequences, and then split things into two separate ABNF grammars: one for canonical PURLs and one for non-canonical PURLs?

The spec is very lenient about repeated slashes /: they’re allowed not just at the start, but also smack in the middle of a namespace or subpath. Basically, you could take a nap with your finger on the / key and still be fully PURL-compliant. 😴///😴///😴

If you fall asleep, you'll need a bigger screen to display the PURL, though. 😉

[jkowalleck]

The spec is very lenient about repeated slashes /: they’re allowed not just at the start, but also smack in the middle of a namespace or subpath. Basically, you could take a nap with your finger on the / key and still be fully PURL-compliant. 😴///😴///😴

tha's not what the current spec says.
unlimited slashes are allowed on the start/end:

purl-spec/PURL-SPECIFICATION.rst

Line 149 in c53ba0e

- All leading and trailing slashes '/' are not significant and SHOULD be

but not on the middle:

purl-spec/PURL-SPECIFICATION.rst

Lines 147 to 148 in c53ba0e

	- If present, the ``namespace`` MAY contain one or more segments, separated
	by a single unencoded slash '/' character.

[ppkarwasz]

Hi @jkowalleck,

that's not what the current spec says. unlimited slashes are allowed on the start/end:

purl-spec/PURL-SPECIFICATION.rst

Line 149 in c53ba0e

- All leading and trailing slashes '/' are not significant and SHOULD be

but not on the middle:

purl-spec/PURL-SPECIFICATION.rst

Lines 147 to 148 in c53ba0e

	- If present, the ``namespace`` MAY contain one or more segments, separated
	by a single unencoded slash '/' character.

The spec doesn’t mention slashes in the middle explicitly, but the spec instructs parsers to ignore empty path segments, which are precisely what repeated slashes (///) represent.

purl-spec/PURL-SPECIFICATION.rst

Lines 390 to 398 in c53ba0e

	- The left side is the ``remainder``
	- Strip the right side from leading and trailing '/'
	- Split this on '/'
	- Discard any empty string segment from that split
	- Percent-decode each segment
	- Discard any '.' or '..' segment from that split
	- UTF-8-decode each segment if needed in your programming language
	- Join segments back with a '/'
	- This is the ``subpath``

So in practice, multiple slashes are allowed anywhere (start, middle, or end), since they collapse during parsing.

[jkowalleck]

So in practice, multiple slashes are allowed anywhere (start, middle, or end), since they collapse during parsing.

I understand, but this is not the right scope for your concerns. I've built the grammar based on the spec, and not on the parser-rules.
If you feel there is something off in the spec, then better open a dedicated ticket for this.

The requested change was completed.

[jkowalleck]

if you dont like this original ABNF case-sensitive notation, we could use RFC7405's case-sensitive notation:

Suggested change

	scheme = %x70.6B.67 ; lowercase string "pkg"
	scheme = %s"pkg"

[jkowalleck]

need to check whether anything in the grammar changed since the last commit here (Oct 1, 2025) (-> see this diff )
As PURL v1.0 is tagged and released, we should be able to finalize the grammar here.

PS: since the PURL core-spec is a standard now, I'd rather have the core-grammar be part of that standard, too.

[jkowalleck]

re: #578 (comment)

reviewed/revisited the grammar according to Ecma standard.
current state of the PR reflects PURL spec v1.0

[Copilot]

Pull request overview

This PR adds a formal ABNF grammar specification for Package-URL (PURL), addressing issue #535. The grammar defines the structure and character encoding rules for both regular and canonical PURL formats.

• Introduces comprehensive ABNF grammar rules for PURL components (scheme, type, namespace, name, version, qualifiers, and subpath)
• Defines character encoding rules and permitted character classes following RFC5234
• Specifies both canonical and non-canonical forms of PURL strings

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jkowalleck]

@mjherzog @pombredanne please review