Add component-specific spec test files

[johnmhoran]

This issue is intended to raise and track the question of whether a set of component-focused .json test files would be a useful addition to the current group of test files:

• purl-spec/tests/spec/, which contains a single file atm, specification-test.json (19 test objects)
• purl-spec/tests/types/, which contains 34 type-specific .json test files atm (varying numbers of test objects)

The "specification" test file has a cross-section of tests without any strong pattern. I think this is meant to be tests that are common to all types, while the tests/types are for each PURL type.

@jkowalleck recently opened PR 738 (#738) comprising a set of tests focused on the qualifiers component, which seems like a useful way to group tests. This PR raises some important questions:

• Does it make sense to create a separate file in tests/spec for each component?
• What tests belong in tests/spec/specification-test.json if we have component-level spec tests?

A broader open question is: What is the relationship between specification and type tests? Based on the current set of type tests, most are a combination of:

• Tests where the input is type-specific
• Tests for PURL type rules such as: no namespace allowed or type-specific qualifiers

[jkowalleck]

A broader open question is: What is the relationship between specification and type tests?

my initial idea when i originally proposed splitting the test suite was:

• Everything based on core spec definition is done in the spec tests. all the canonicalization, parsing, building, validation, ...
• Type tests only test things that are based on the type definition. Type tests don't test core spec again.

The benefit: every PURL implementation could be tested for core spec compliance, while some fast-moving type-spec might not be completely implemented.
This would enable PURL library development to be accurate to the one thing that is actually standardized, PURL core spec - no excuses.
This requires that all the core spec features are actually in the respective part of the test suite, and not hidden under some purl type prefix.

in my original solution, I actually reviewed every single test and moved it to the correct place. then i identified duplicates and removed them. The work i spent multiple days with was never merged, but the pull requests tell stories.

• examples for test that should be moved to core-spec
  • some perl/raku type test check whether the : in the namespace is not encoded -> this is core spec: "colon must not be percent-encoded"
  • some npm type check whether the "@" in a namespace is properly percent-encoded -> this is core spec: "non-alphanumerics, especially delimiters(/@?&=#) when not used as such, must be percent-encoded"
  • some type tests that empty namespaces must not exist or are normalized or something - core spec for obvious reason
• examples for actial type tests:
  • some type defines that a namespace must (or must not) be given, or in a certain range
  • some type defines that certain qualifiers are mandatory

[jkowalleck]

Does it make sense to create a separate file in tests/spec for each component?

I would love to see this. With the new test suite structure, we can finally group things in separate files.

PS: since the purl spec is finalized now, we have rules for parsing, building and normalizing each different component. we also have general rules for allowed characters, and how to percent-encode them.
all these rules should be in the test suite eventually. this test suite for core spec might hold hundreds of tests at some point, and grouping them by component in separate files would make things easier for test/spec maintainers, tool writers, and alike.