Contradictive Field Typing in error_response Definition

[AtticusRains]

In the error response definition the description of the message field seems to contradict the field type. I suggest we change the type of message to be a string to allow for more descriptive error messages.

From openapi-hsda.yaml :

  error_response:
    properties:
      code:
        description: 'Repeat the HTTP status code'
        type: integer
      message:
        description: 'A plain language message explaining the error'
        type: integer

[kinlane]

I'd like to propose RFC 7807 - https://tools.ietf.org/html/rfc7807 - as we move to v2.0 - further standardize HSDA by leveraging existing standards. Agreed the current isn't sufficient.

[kinlane]

I have added the base problem schema to HSDA - -using RFC 7807:

    problem:
      description: The meta_table_description table contains metadata about individual
        tables.
      properties:
        type:
          type: string
          description: A URI reference [RFC3986] that identifies the problem type.  This specification encourages that, when dereferenced, it provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html5-20141028]).  When this member is not present, its value is assumed to be "about:blank".
        title:
          type: string
          description: A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4)'
        detail:
          type: string
          description: A human-readable explanation specific to this occurrence of the problem.
        status:
          type: string
          description: The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
      required:
        - type
        - title
        - detail
        - status 

I will add a handful of types based upon the most common errors -- which should be able to be added to without iterating upon the version (unless fields are added).