Examples not reads when `format: byte`

Hello there,

From the openapi-style-validator project, we have an issue with properties of type string and format byte where the example is not read: https://github.com/OpenAPITools/openapi-style-validator/issues/132

Schema:

  schemas:
    Response:
      required:
        - content
      properties:
        content:
          type: string
          format: byte
          example: "VGhpc1Nob3VsZFBhc3MK"

Expected: An OpenAPI with example set for the content property.

Actual: example is null.

We do not know if this is expected behaviour or an issue on the parser, can someone tell us more on that “issue” ?

Thanks

[frantuma]

@gervaisb

we have added indeed such conversion in https://github.com/swagger-api/swagger-core/pull/4147, therefore you can use it if it fits your needs (by using parser “as is” , with no swaggerParserBinaryAsString property/env set).

The first possible issue with this approach is that the conversion / data binding is opinionated, as it uses getBytes() to encode the string into bytes, while e.g. the serialized string could be meant to be a Base64 encoded representation of the bytes (Jackson e.g. uses Base64 for default binding of string to byte[])

Another issue is serialization of the parsed string, in this case the serialized value will be encoded in Base64, resulting in a different string from the one parsed.

We might choose to try using Base64 in the cast method above, but again this would be an opinionated choice, given also that e.g. example is of any type in OAS 3.0, possibly including any encoding/representation of binary values

An additional issue is serialization to YAML; YAML is capable to represent binary using tags, and indeed default serialization uses that, therefore a YAML version of the same spec, with the same string value in example as the one in JSON version, would not be parsed correctly (would actually break).

example: !!binary |-
  Y2FjY2E=

We could further address the points above by e.g. providing more options and addressing the different cases, but on top of adding quite some complexity and being not trivial, the expected behaviour would be dependent on the specific spec.

[frantuma]

no fixed ETA but probably within first week of April