Diff in top level format of securedBy between 0.8 and 1.0

[xaka]

RAML 0.8:

"securedBy": [
  "oauth_2_0",
  "clientId"
],

RAML 1.0:

"securedBy": [
  {
    "name": "oauth_2_0",
    "securityScheme": {
      "describedBy": {
        "queryParameters": {
          "access_token": {
            "description": "Used to send a valid OAuth 2 access token. Do not use together with\nthe \"Authorization\" header\n",
            "name": "access_token"
          }
        }
      },
      "description": "Instagram's API uses the OAuth 2.0 protocol for simple, but effective\nauthentication and authorization. The one thing to keep in mind is tha\nall requests to the API must be made over SSL (https:// not http://)\n",
      "name": "oauth_2_0",
      "settings": {
        "accessTokenUri": "https://api.instagram.com/oauth/access_token",
        "authorizationGrants": [
          "code",
          "token"
        ],
        "authorizationUri": "https://api.instagram.com/oauth/authorize",
        "scopes": [
          "basic",
          "comments",
          "relationships",
          "likes"
        ]
      },
      "type": "OAuth 2.0"
    },
    "securitySchemeName": "oauth_2_0",
    "structuredValue": null
  },
  {
    "name": "clientId",
    "securityScheme": {
      "describedBy": {
        "queryParameters": {
          "client_id": {
            "description": "Client_id is is identifier of  your server, script, or program with a specific application\nthis parameter is required if you are accessing APIs without authenticating\n",
            "example": "9e0dbc0a3b8d436ca65ae2df9825c893",
            "name": "client_id"
          }
        }
      },
      "description": "in many situations, you may not need to authenticate users at all.\nFor instance, you may request popular photos without authenticating\n(i.e. you do not need to provide an access_token; just use your client ID with your request).\nWe only require authentication in cases where your application is making requests on behalf of a user\n(commenting, liking, browsing a user's feed, etc.).\n",
      "name": "clientId",
      "type": "x-customHeader"
    },
    "securitySchemeName": "clientId",
    "structuredValue": null
  }
],

[sichvoge]

It seems that 0.8 is missing a lot of information. @svacas @KonstantinSviridov is this on purpose?

[KonstantinSviridov]

@sichvoge Actually, what we see here as "RAML 0.8" is output of the old JS parser. It provides exactly what was specified in RAML document, and it's fine.

"RAML 1.0" here is a fragment of TCK JSON. So, what's the additional information?

The RAML 1.0 parser provides a way to obtain AST node of referenced security scheme. The SecuritySchemeRef.securityScheme() method serves this purpose. This functionality must be tested and, thus, reflected in TCK JSON. Right now we serialize AST Node completly, which is excessive, so, we need to invent some appropriate way. Serializing just security scheme name is obviously not enough.

[KonstantinSviridov]

One more difference between how securedBy is serialized by the old 0.8 JS parser and TCK JSON is node format.

Current TCK JSON:

"securedBy": [
  {   security scheme reference object 1  },
  {   security scheme reference object 2  },
],

Old JS parser:

"securedBy": [
  {
    securitySchemeName1: {   security scheme reference object  }
  } , {
    securitySchemeName2: {   security scheme reference object  }
  }
],

I do not see reasons for not switching TCK format to old JS 0.8 here.