Shall a non canonical purl be a valid input ?

[TG1999]

https://github.com/package-url/purl-spec/blob/main/schemas/purl-test.schema-0.1.json

We also need to define what kind of inputs a "base" and "advanced" tests can take ?

[johnmhoran]

And for the base and advanced tests, for build, parse, and roundtrip,

• when is a non-canonical PURL allowed as an input?
• how are the various non-canonical characteristics to be handled (unencoded slash in a qualifiers value being just one of many way an incoming PURL can be non-canonical and must be handled somehow)?
• when must a test fail, i.e., expected_failure is true, and when must the expected_output be null (presumably in coordination with expected_failure is true)?

[johnmhoran]

@TG1999 Thank you for opening this issue. I added a few closely-related questions ^ and also added the issue to https://github.com/orgs/package-url/projects/10/views/1.

[TG1999]

@johnmhoran thanks 🙇, also thanks for bringing this issue up, I hope resolving this issue brings more clarity on valid inputs and the expected behaviours.

[johnmhoran]

Thanks @TG1999 . While I'm at it ;-)

• why does the test schema seem to require a roundtrip input be canonical and prohibit a null value in expected_output?

[petergardfjall]

Referencing a discussion relevant to this ticket: https://github.com/package-url/purl-spec/issues/644#issuecomment-3485989383

An excerpt from that comment:

I had a discussion on qualifiers with @matt-phylum here. In this comment he clarified a thing to me -- the procedure for parsing a PURL accepts a wider range of PURLs than the procedure for producing a canonical (output) purl.

In other words, the way the spec is currently formulated it does NOT require input purls to be canonical.

[johnmhoran]

@petergardfjall Please note that the how-to-build and how-to-parse sections (not currently part of the 1.0 standard submitted to Ecma) have not yet been updated to accurately reflect the 1.0 submission.