Fix bazel tests

[TG1999]

Reference:

• Fix Bazel tests #729

Related:

• Expected output in testcases do not follow spec encoding #644

[johnmhoran]

@TG1999 One preliminary question I have: if the input PURL has an unencoded slash in the qualifiers value, doesn't that raise an exception, halt the evaluation process, and thus require a null expected_output and a true expected_failure?

@mjherzog @pombredanne @matt-phylum @jkowalleck What do you think?

[matt-phylum]

If the input PURL has an unencoded slash, an exception should not be thrown. It is not part of the spec, and it breaks existing PURLs where slash is not encoded, including examples from previous versions of the spec and output from code that implements an older version of the spec.

When I last updated the purl-survey output, 10 of 15 implementations passed tests that required slash to be unencoded in qualifier values. PURLs canonicalized by those implementations would be broken by turning unencoded slashes in qualifiers into errors.

[johnmhoran]

Thanks @matt-phylum . Putting aside slashes for a moment (which the submitted standard makes clear MUST be percent-encoded in a qualifiers value however we're meant to distinguish between MUST and SHOULD and MAY), if a roundtrip input has no pkg:, expected_output will be null and expected_failure will be true -- right? Surely a tool will not "fix" that deficiency by supplying the missing pkg:.

[jkowalleck]

while fixing this for bazel explicitely,
we should have this case become a general spec case in specification-test.json

• encode reserved delimiters /?&#

PS:see #738

[johnmhoran]

If a base test input is not canonical, like this one ^, doesn't that fail, period?

[jkowalleck]

nope.
non-canonical inputs must be allowed.

this case is not about non-canonical input, but about invalid input.
as a purl must not contain non-alphanumeric chars -> see https://github.com/package-url/purl-spec/blob/main/purl-specification.md#permitted-characters

anyway, we COULD "fix" this invalid input by properly encoding the forbidden chars.
ala "be conservative in what you do, be liberal in what you accept from others" https://en.wikipedia.org/wiki/Robustness_principle

[mjherzog]

@jkowalleck This is the intended distinction between base and advanced test groups. We need a suite of base conformance tests that are pass/fail. You allow a non-canonical input but it may fail.
The advanced tests include those where you might fix an error.
In both cases we are in active discussion about what messages to return along with the pass/fail status.

• In the base case it would be useful for the tool to return a specific message about what caused the error as possible.
• In the advanced case it would be be useful for the tool to return a specific message about what it fixed.
  So in this specific test case the test_group should be advanced instead of base imho.