I'm working on a tool that will generate printable PDF documents from a RAML spec and would love to have one 'definitive' file I can use that implements all elements available in RAML. Being able to successfully render this test file would indicate that the tool works properly.

In the helloworld.raml example, the response's data type declaration has an invalid title field; this field does not exist for data type declarations according to the spec.

The appropriate field here is likely to be displayName.

I'm putting an example of a RFC3339 compliant Time Code with a Timezone Offset in my RAML example and as far as I can tell it is RFC3339 complient, except that RAML says it's a bad date-time.

  orderDate?: 
    type: datetime
    example: 2016-02-28T16:41:41-4:00
    format: rfc3339 

According to RFC documentation examples, this is valid:

1996-12-19T16:39:57-08:00
   This represents 39 minutes and 57 seconds after the 16th hour of
   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
   in UTC.```

In example typesystem/complex.raml, there are two problematic properties in the body :
kind: admin
kind: manager

The issue was noticed using version 1.0.0 of the raml-java-parser, as parsing the example fails with the following errors:

- message: "Invalid type name: admin"
- message: "Invalid type name: manager"

After reading the spec, it seems to me that the example should either use the discriminatorValue facet in the Admin and Manager type declaration, or use uppercase for admin and manager when discriminating between the types.

The /entry type is collection (https://github.com/raml-org/raml-examples/blob/master/others/world-music-api/api.raml#L170)

That type refers to a schema <<resourcePathName|!singularize|!uppercamelcase>> but there is no such schema in this repo (https://github.com/raml-org/raml-examples/blob/master/others/world-music-api/api.raml#L60-L68).

First of all thank you for adding the amazing banking-api example. My question is if I'm following that structure what is best practice for per-endpoint examples for the type system. For example, we have this.

post:
  description: Creates <<resourcePathName | !singularize>> data
  responses:
    201:
      body:
        application/json:
          type: <<get-response-type>>

with

/users:
  type:
    member:
      post-request-type: types.thing
  post:

For solutions I have tried:

/users:
  type:
    member:
      post-request-type: types.thing
        example:
          user: Patrick
          password: securepass       
  post:

and

/users:
  type:
    member:
      post-request-type: types.thing
  post:
    example:
      user: Patrick
      password: securepass