S-008 camara-parameter-casing-convention: rule name suggests parameter-name validation, but only path-key casing is checked

[hdamker]

Problem description

The Spectral rule camara-parameter-casing-convention (S-008 in the validation framework rule inventory) has a name and documentation that suggest it validates parameter naming, but its implementation only validates path-key kebab-case.

• Rule definition (linting/config/.spectral-r4.yaml):

  • description: Paths should be kebab-case.
  • given: $.paths[*]~ — selects path keys, not parameters
  • Pattern: ^\/([a-z0-9]+(-[a-z0-9]+)*)?(\/[a-z0-9]+(-[a-z0-9]+)*|\/{.+})*$

• Documentation in Commonalities Linting-rules.md:

  • Heading at line 351: #### Path parameters / Query parameters
  • Description at line 357: "Path parameter should follow a specific case convention, with the default being kebab case."

• Design Guide §5.7.4 Parameters and §5.8.3:

  Parameter names are defined in lowerCamelCase: For example: sessionId.

The Design Guide mandates lowerCamelCase for parameter names. The current rule does not check this. The rule name and the Linting-rules.md heading are misleading because they imply parameter-name coverage that is not implemented.

Expected behavior

Parameter names should be validated against the Design Guide:

• Path and query parameter names: lowerCamelCase
• Header parameter names: excluded (HTTP headers are case-insensitive per RFC; CAMARA documents x-correlator as a guideline at §5.8.5)

The path-key kebab-case check should remain in place — it correctly implements Design Guide §5.7.1.

Alternative solution

Two implementation options:

1. Rename + add sibling (preferred): Rename the current rule to camara-path-casing-convention (accurate name for the implementation) and add a sibling rule camara-parameter-name-casing-convention with:

   camara-parameter-name-casing-convention:
     description: Parameter names (path and query) must be lowerCamelCase.
     message: "{{property}} is not lowerCamelCase: {{error}}"
     severity: warn
     given: $.paths[*][*].parameters[?(@.in != 'header')].name
     then:
       function: pattern
       functionOptions:
         match: "^[a-z][a-zA-Z0-9]*$"
     recommended: true

   Existing rule signature stays stable; gap is filled by addition. Update Linting-rules.md to split the section accordingly.

2. Extend current rule: Keep the rule name and add the parameter-name given as an array entry. Less surgical because the single rule then mixes two distinct concerns (path keys and parameter names) under one ID.

Additional context

Discussed in: Zulip thread (+ follow-ups)

The current path-key behavior is correctly pinned by regression/r4.1-broken-spec-routing on camaraproject/ReleaseTest (validation framework regression suite). Once a new parameter-name rule is added, it can be pinned via a follow-up edit to that branch.