Qualified rulenames to avoid clashes when extending ruleset

[DawMatt]

This is to resolve issue #73 .

Changing the rules to use URN style naming (similar to Stoplight's OWASP ruleset) makes it simpler to extend this ruleset without naming clashes from other rules.

Section numbers (but not subsection numbers) have been used as part of the naming scheme, to balance maintainability with understanding what the rules are trying to achieve.

[fluffy-dutchman]

Since this is a YAML file, have you checked to make sure that this key name (rule-name) changes are not breaking conventions for key-names? If you wanted a key with multiple ":" in it like the URN you suggested, I believe you will have to wrap each key in quotes like: "json:api:1:sect4:content-type". Also, if "1" is the version of the JSON:API specification the rule is for I'd suggest using 1.0 or 1.1 depending on which specification version it applies to.

[DawMatt]

@tnederveld , I've checked the spec ( https://yaml.org/spec/1.1/ ) and it includes a number of unquoted URN examples. It also states that colons and other significant characters are acceptable within scalars as long as they aren't followed by a space (or other whitespace).

The ruleset also works fine in testing. Both via npm test, and in the wild (I've already extended this).

I'll make the 1 -> 1.0 change as requested. Is this sufficient, or do you also want quoting of keys event though it is not required by the specification? My preference is to leave them unquoted but that is mainly due to aesthetics.

[DawMatt]

@tnederveld , all rule names have been changed to include a version naming element of 1.0

[DawMatt]

@tnederveld , was this OK, or did you need additional changes to be made?