Clarify spec for subpath

[johnmhoran]

johnmhoran: 2025-01-20 18:39: Just started to flesh out the relevant issues, PRs and comments before converting this to an issue.

the "board": https://github.com/package-url/purl-spec/issues?q=state%3Aopen%20label%3A%22PURL%20subpath%20component%22

Relevant issues and PRs:

• Clarifications, in particular about version encoding #35
• docs(types): oci type repositry_url must be percent encoding #150
• test: unencoded subpath cannot contain . or .. #368

We also need to

• review the relevant language etc. in PURL-SPECIFICATION.rst
• apply RFC 2119/8174 but replace the use of any "not"/"NOT" with affirmative language
• done via docs(subpath): revisited #394

2025-02-06 Note: after discussion at yesterday's biweekly PURL community meeting, we are back to using "not"/"NOT" when that most clearly and succinctly expresses the intent.

[jkowalleck]

will work on this.

i'll give this a bit of time, and wait until #361 got merged,
so i can use the newly added structures from there.

[jkowalleck]

status update: did not start yet, other things came in the way.
plan on starting soon.

[jkowalleck]

the ticket says:

apply RFC 2119/8174 but replace the use of any "not"/"NOT" with affirmative language

@johnmhoran, based on yesterday's community meeting: is this still true?

[johnmhoran]

Hi @jkowalleck . I'm glad you asked. No, after some sensible discussion at yesterday's biweekly PURL community meeting, that briefly-adopted approach is no longer in effect, and we are back to using the not/NOT when that most clearly and succinctly expresses the intent.

[johnmhoran]

and thanks for the reminder -- I'll update the project board items to note that not/NOT is no longer forbidden. ;-)