RAML 1.0 > OAS 3.0 not conforming to the spec when merging traits and resourceTypes

[p-bakker]

My RAML has something along these lines:

#%RAML 1.0
title: My API
version: v1
baseUri: https://{tenant}.test.com/api/{version}/organization/{organizationId}
baseUriParameters:
  tenant:
    type: string
    displayName: Tenant Identifier
    default: yourSubDomain
  organizationId:
    type: UUID
    displayName: ID of the Organization to interact with
    default: 00000000-0000-4000-0000-000000000000

traits:
  # Using Default trait to specify support for application/json, as using global mediaType for this would be overridden by Printable trait
  Default:
    headers:
      Accept:
        type: string
        enum: [application/json]
        default: application/json
  Printable:
    headers:
      Accept:
        type: string
        enum: [application/pdf] #does this add to the enum, or does it overwrite
    responses:
      200:
        body:
          application/pdf:

resourceTypes: #Add error types, more response codes
  Collection:
    get:
      is: [ Default ]
      responses:
        200:
          body:
            application/json:
              type: <<item>>[]
  Member:
    get:
      is: [ Default ]
      responses:
        200:
          body:
            application/json:
              type: <<item>>

types:
  Company:
    properties:
      id: string

/companies:
  type: { Collection: {item: Company} }

  /{id}:
    type: { Member: {item: Company} }

    get:
      is: [ Printable ]

What this basically does is say: a GET on companies/{id} can either Accept application/json or application/pdf.

When you run this through the converter to generate OAS 3.0, only the application/pdf is properly included:

openapi: 3.0.0
info:
  title: My API
  version: v1
servers:
  - url: 'https://{tenant}.test.com/api/{version}/organization/{organizationId}'
    variables:
      tenant:
        default: tenant
      version:
        default: version
      organizationId:
        default: organizationId
paths:
  /companies:
    get:
      responses:
        '200':
          description: ''
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Company'
      operationId: GET_companies
      parameters:
        - $ref: '#/components/parameters/trait_Default_Accept'
  '/companies/{id}':
    get:
      responses:
        '200':
          $ref: '#/components/responses/trait_Printable_200'
      operationId: GET_companies-id
      parameters:
        - $ref: '#/components/parameters/trait_Printable_Accept'
    parameters:
      - name: id
        in: path
        required: true
        schema:
          type: string
components:
  schemas:
    Company:
      properties:
        id:
          type: string
      required:
        - id
      type: object
  responses:
    trait_Printable_200:
      description: ''
  parameters:
    trait_Default_Accept:
      name: Accept
      in: header
      required: true
      schema:
        default: application/json
        enum:
          - application/json
        type: string
    trait_Printable_Accept:
      name: Accept
      in: header
      required: true
      schema:
        enum:
          - application/pdf
        type: string
  examples: {}
  requestBodies: {}
  headers: {}
  securitySchemes: {}
  links: {}
  callbacks: {}

I've also tested with the same RAML file and generating HTML data from it using https://www.npmjs.com/package/raml2html and that library does parse stuff as expected, so I think my RAML is ok.

I've also Looked at the RAML specs to see how stuff in the RAML file should merge, see https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/#resource-types-and-traits-effect-on-collections. I've also put the sample RAML code from the spec through the converter and the outcome is not correct:

#%RAML 1.0
title: Example API
version: v1
traits:
  withQueryParameters:
    queryParameters:
      platform:
        enum:
          - win
          - mac
/installer:
  get:
    is: [ withQueryParameters ]
    queryParameters:
      platform: #the actual enum is [ mac, unix, win ]
        enum:
          - mac
          - unix

becomes

{
  "openapi": "3.0.0",
  "info": {
    "title": "Example API",
    "version": "v1"
  },
  "servers": [],
  "paths": {
    "/installer": {
      "get": {
        "responses": {
          "default": {
            "description": ""
          }
        },
        "operationId": "GET_installer",
        "parameters": [
          {
            "$ref": "#/components/parameters/trait_withQueryParameters_platform"
          }
        ]
      }
    }
  },
  "components": {
    "schemas": {},
    "responses": {},
    "parameters": {
      "trait_withQueryParameters_platform": {
        "name": "platform",
        "in": "query",
        "required": true,
        "schema": {
          "enum": [
            "win",
            "mac"
          ],
          "type": "string"
        }
      }
    },
    "examples": {},
    "requestBodies": {},
    "headers": {},
    "securitySchemes": {},
    "links": {},
    "callbacks": {}
  }
}

As you can see in the above example, the merging of the enum is not done according to the RAML spec