Proposal: add a new format: plain for type: string

My proposal is that we add a new string type format:

type: string
format: plain

Which limits strings to non-binary strings. The reason that I think this would be helpful is that

type: string

With format unset is generally used as a generic string. However, it should allow in both string and binary string types. Here are some schemas that demonstrate that: Binary is a more specific format constraint on string, so one can have this schema:

composedSchema:
  allOf:
    - type: string
    - type: string
      format: binary

Which will validate for python b'hi'

Can one have a binary date and binary date-time? I suspect not because we don’t know the encoding to go from a sample default/sample/enum string value to an encoded binary value. Do people agree with this point about binary date and datetimes not existing?

What is missing is the ability to constrain a string to only non-binary types. If we had that, then we could reject binary string values and only allow in non-binary strings.

type: string

Allows in ‘hi’ and b’hi’

type: string
format: binary

Allows in b’hi’ only

type: string
format: plain

Would allow in ‘hi’ only and exclude b’hi’

All json payloads that are sending plain text and not binary file data are sending:

type: string
not:
  type: string
  format: binary

which is equivalent to:

type: string
format: plain

[handrews]

@spacether format: binary and format: byte no longer exist in OAS 3.1, having been replaced by JSON Schema’s more flexible contentMediaType, contentEncoding, and contentSchema.

The only time you are dealing with an actual octet-stream is when the media type specified in the HTTP Content-Type header or as a part of a multipart form. This is outside of the JSON data model, and not a type: string in the normal sense.

Open API’s Media Type Object and Encoding Object cover whatever aspect of this is not covered by JSON Schema.

When working with a media type compatible with the JSON data model, raw binary is not possible, only encoded binary as indicated by contentEncoding. If there is no contentEncoding, then the string is assumed to be regular JSON string data without any encoding to decode.

I don’t think this proposal applies anymore. format: binary was never a good fit for format (but in fairness to OpenAPI, at the time of OAS 3.0, there weren’t any better options).

[spacether]

Thank you for clarifying this. So it sounds like this is no longer applicable in v >= 3.1.0 and that format binary strings cannot be used in place of string type with no formatting.