I'll talk about some superficial characteristics that make RAML easy to swallow, particularly when compared to the OpenAPI specification. The RAML specification uses a consistent notation, based on YAML, wheras the OpenAPI specification switches back and forth between a JSON representation and a YAML representation, distracting the reader.

Relative to OpenAPI (aka "Swagger"), RAML values making life easier for the writer. Thus it looks concise, looks almost like a Markdown, Word or Whiteboard outline you use already.

One RAML use case would be to generate HTML or PDF documentation of an API. Another would be to generate a set of client stubs to access the API from some language like Python, Java, Node, FORTRAN, etc. Of course you can generate server stubs too if your are the developer of the service.

RAML is all about defining the semantics of specific URLs and families of URLs, but it rejects the "namespace" mechanism from the XML and RDF world. For instance you cannot use a well-known predicate such as dc:Author . Statements certainly look cleaner than they do in RDF.

Despite this heresy, the type system is modeled after XSD but uses a more hip syntax which may appeal to the young people in the audience. A RAML document could be expressed as an RDF graph by a mechanical translation and then SPARQL queried for fun and profit.