Types Don't Stay True to Definition

[blakeembrey]

This one needs to be ruled for/against, but I'd like to see the JSON output be more true to the users input. Example:

  methodName:
    type: string

          "methodName": {
            "displayName": "methodName",
            "name": "methodName",
            "type": [
              "string"
            ],

Notice that type has become an array.

[KonstantinSviridov]

Right, TypeDeclaration.type property is an array in RAML 1.0. Do you propose here to replace one element arrays by their element in this case?

[sichvoge]

Talking with Uri; the type property is indeed either a single type or a sequence. The following is an example for a sequence:

type: [ foo, bar ]

So I would potentially stick with an array to have a consistent representation. @blakeembrey ?

[blakeembrey]

I proposed using the raw user input. Anywhere where we lose data means a slightly incorrect representation in documentation.

[KonstantinSviridov]

We already have several cases of losing input style data. For example, we do not make a difference between sequences and maps in traits and resourceTypes. I do not think, we should handle input style in particular cases if we can not handle it everywhere.

[blakeembrey]

@KonstantinSviridov There isn't any information lost there though, it's just making the data more accessible. The names remain the same, and there's no reason someone would render something based on array or object of resource types, though it's a valid concern. Here it's a different representation of something people will actually display to users.

[sichvoge]

@KonstantinSviridov, as per raml-org/raml-spec#306 - RC2 will handle all global definition (except documentation) as maps.