Support for 'main stream' format validation for the no-invalid-schema-examples rules

[LasneF]

Is your feature request related to a problem? Please describe.

given an API specification , i would like that example are validated not only about the type but as well about the format

for instance as of today this example is mentionned as valid with the rules no-invalid-schema-examples set

        expiry:
          type: string
          format  : date
          example: TN

Describe the solution you'd like

i would like either a parameter on the no-invalid-schema-examples rule
either a dedicated rules that would validate example toward format

notice that the rules should support combination with oneOf for instance such

        expiry:
          type: string
          oneOf:
            - format: date
            - enum:
                - SPOT
                - TODAY
                - TN
                - 'ON'
                - TOM
          example: TN

      should not be spot as an error (as it is currently raised as such)

Describe alternatives you've considered

no alternative :)

Additional context

it should be done for main stream format like at minimum date and date-time that are the most used
any support of https://spec.openapis.org/registry/format/ would be a bonus

[lornajane]

Thanks @LasneF, this is a good suggestion and we'll bear it in mind. You should also be able to build checks like these with configurable rules or custom plugins (And if you do, please share with the cookbook !)

[tatomyr]

@LasneF how is the issue different from this one?

[LasneF]

Let s summuriaze the tree issues links

#1729 : this issue is a about supporting fomat validation properly
it also highlight the nasty side effect when format is used in synch with anyOf , or oneOf

#766 : looks similar and extend in the discussion the topic around pattern ( that is an kind of extension , and due to pattern introduce the security aspect due to pattern attack (just added one comment)

#1470 : this one is a kind of mistake , it hightlight that given json schema definition this may deserve a dedicated rules as format validation is not a required feature , it is a kind of decorator

No pb you can close all and keep only the #766 as the root of the requirement given the differents aspects here

[tatomyr]

Thanks for the summary @LasneF! Let's keep the discussion in #766.