You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.
When working with AMF parser, I've discovered that the following RAML passes the validation (aml-org/amf#1085):
#%RAML 1.0title: Test API/person:
post:
body:
application/json:
type:
type:
type: # And possibly many more nested 'type:' facets below until the actual Type Expressiontype: objectproperties:
prop1: string
Here's what the current version of specification says:
The type which the current type extends or just wraps. The value of a type node MUST be either a) the name of a user-defined type or b) the name of a built-in RAML data type (object, array, or one of the scalar types) or c) an inline type declaration.
While points a) and b) are clear, the point c) here puzzles me since it creates a loophole that allows a user to create an infinite type declaration, or confusing constructions involving deprecated schema node:
types:
MyType:
schema:
type: objectproperties:
Is it done on purpose? What is the point of allowing an inline type declaration inside a type?
The text was updated successfully, but these errors were encountered:
Hi 👋
When working with AMF parser, I've discovered that the following RAML passes the validation (aml-org/amf#1085):
Here's what the current version of specification says:
While points a) and b) are clear, the point c) here puzzles me since it creates a loophole that allows a user to create an infinite type declaration, or confusing constructions involving deprecated
schema
node:Is it done on purpose? What is the point of allowing an inline type declaration inside a type?
The text was updated successfully, but these errors were encountered: