definities common.yaml voldoen niet aan DD5.3

[melsk-r]

Originally created by fsamwel (https://github.com/VNG-Realisatie/Haal-Centraal-common/issues/77):

DD5.3 Technische definities van properties alleen opnemen voor zover dat noodzakelijk is voor gebruik

Meestal volstaat het om in de definitie van properties in de response de propertynaam, type, format, description en example op te nemen. We gebruiken daar niet de technische definities pattern, minimum, maximum, minLength, maxLength, minItems en required, tenzij....

• gebruik minimum en maximum in Datum_onvolledig dag, maand en jaar.
• minItems en maxItems in de geoJson definities

N.B. waarom zitten geoJson componenten in common.yaml? In BAG en BRK verwijzen we naar definities van opengis , niet naar common.yaml. Volgens mij kunnen die verwijderd worden uit common.yaml

N.B. we kunnen regel toevoegen aan spectral lint om DD5.3 te testen:

  too-much-information:
    description: properties of GET responses should not use pattern, minimum, maximum, minLength, maxLength, minItems or required
    resolved: false
    type: style
    message: 'Gebruik geen {{property}} in response definitie: {{path}}'
    given: '$.components.schemas..properties[*]'
    then:
      - field: "minItems"
        function: falsy

      - field: "maxItems"
        function: falsy

      - field: "maxLength"
        function: falsy

      - field: "maxLength"
        function: falsy

      - field: "minimum"
        function: falsy

      - field: "maximum"
        function: falsy

      - field: "required"
        function: falsy

      - field: "pattern"
        function: falsy

[melsk-r]

This comment originally might have been created by someone else.

DD5.3 Technische definities van properties alleen opnemen voor zover dat noodzakelijk is voor gebruik

Meestal volstaat het om in de definitie van properties in de response de propertynaam, type, format, description en example op te nemen. We gebruiken daar niet de technische definities pattern, minimum, maximum, minLength, maxLength, minItems en required, tenzij....

• gebruik minimum en maximum in Datum_onvolledig dag, maand en jaar.

Dit gaat natuurlijk vooral op voor bevragingen-API's. Mochten we op termijn ook een API maken die wel datavalidatie nodig heeft dan is het wel handig om deze in de Common.yaml te hebben.

[melsk-r]

This comment originally might have been created by someone else.

@fsamwel Begrijp ik je goed als ik betreffende DD wijzig in:

DD5.3 Technische definities van properties alleen opnemen voor zover dat noodzakelijk is voor gebruik

Meestal volstaat het om in de definitie van properties in de response de propertynaam, type, format, description en example op te nemen. We gebruiken daar niet de technische definities pattern, minimum, maximum, minLength, maxLength, minItems en required, tenzij....

• het een van de properties van 'Datum_onvolledig' (dag, maand en jaar) betreft. Daar mag 'minimum' en 'maximum' wel gebruikt worden.
• het geoJson definities betreft, daar mag 'minItems' en 'maxItems' gebruikt worden.

De technische definitie title gebruiken we alleen wanneer de propertynaam afwijkt van de naam in het informatiemodel (en het informatiemodel bekend is bij veel gebruikers). De technische definitie enum gebruiken we wanneer (sommige/mogelijke) gebruikers de mogelijke waarden gebruiken in code/algoritmes en daarom moeten weten welke mogelijke waarden er zijn.

Wat betreft je wijzigingsvoorstel voor de spectral lint, loop ik, als ik dit doorvoer, er niet tegenaan dat de foutmelding ook wordt gegeven in bovenstaande gevallen en als het niet om een response gaat?

[melsk-r]

This comment originally might have been created by someone else.

het geoJson definities betreft, daar mag 'minItems' en 'maxItems' gebruikt worden.

moet zijn "we een (inter)nationale standaard gebruiken waarin dit wel is opgenomen"

Wat betreft je wijzigingsvoorstel voor de spectral lint, loop ik, als ik dit doorvoer, er niet tegenaan dat de foutmelding ook wordt gegeven in bovenstaande gevallen en als het niet om een response gaat?

Misschien. Kan je dat dan oplossen door het script te verfijnen?