Does the paradigm behind the schema specification for actions allow extending set of action parameters for specific resource instances?
Consider an example:
A JobDocument resource schema defines action "SubmitJob" which takes "JobCreator", "StartTime", and "PreferredExecutors" parameters common to all JobDocument instances. Theses parameters are defined in the schema.
A specific system is populated with a JobDocument resource "Bake Candy" which additionally requires parameters "Amount", "Shape", and "Color" to instantiate a Job which would bake certain amount of candies of specific color and shape.
Would compliance with the Specification/Schema maintained it these extended parameters are shown inside the "SubmitJob" @redfish.ActionInfo annotation while not defined in the schema or it would be considered a violation?
Unfortunately you'd need to have all of the parameters defined in the schema definition of the action; it's not legal to provide parameters that are not defined in schema.
In your case, you could do one of two things:
Define a single "SubmitJob" action with all possible parameters for the various underlying resources, and in each resource expose an ActionInfo term to convey the specific parameters supported for each instance.
Break your action into multiple definitions where the parameters are more fine-tuned for a particular usage. This would be similar to how ComponentIntegrity has both "SPDMGetSignedMeasurements" and "TPMGetSignedMeasurements"; both are conceptually the same to collect signed measurements, but each has a unique list of parameters specific for their usage.
Both approaches are valid, and the decision between one and the other might come down to how much overlap there is in the action usage between the different resource instances.