It's nice, but because of the HAML-like format, there are a lot of empty space characters included.
That's great for readability, but it doesn't seem like a perfect choice for a webservice description language, since that content might get hosted and transferred often over the network for clients that might be interested in it.
You should probably have a format that is easily digestible, like WSDL was for SOAP services. Requiring the person serving the RAML to setup their webserver to gzip it and requiring the client to gunzip everything is not very friendly. Having a JSON version of the spec would condense it while still allowing it to be readable, and it would be easily digestible in Javascript and many other languages without an additional parser.
If you're dead set on using JSON, note that RAML seems to be a subset of YAML, which can be easily converted to JSON. You could do that on the server side, or just use one of the many YAML parsers written in javascript on the client side.
That's great for readability, but it doesn't seem like a perfect choice for a webservice description language, since that content might get hosted and transferred often over the network for clients that might be interested in it.
You could convert to binary to compress it, but that makes it harder for the client, so the friendliest thing would be to convert it to JSON, e.g.: http://my.host/to/a/path/of/my_service.haml.json in addition to the more human-readable haml format at: http://my.host/to/a/path/of/my_service.haml