raml-org / raml-spec

RAML Specification
http://raml.org
3.87k stars 857 forks source link

Json Schema draft compatibility limit #751

Closed tomsfernandez closed 3 years ago

tomsfernandez commented 3 years ago

Hi! is there an upper and lower bound of json schema draft versions that can be included in a RAML?

The only reference there is to a JSON Schema Draft number is in the "references" section but it never explicitly states if RAML 1.0 supports a limited set of drafts.

Thanks!

jstoiko commented 3 years ago

RAML 1.0 does not restrict which version of JSON Schema may be used.

A RAML processor MUST be able to interpret and apply JSON Schema (...)

That being said, I would not read this as "processors MUST support any versions, past and future, of JSON Schema" as it would put unrealistic expectations on tooling developers. So I think it is fair to say that as long as a given processor supports one version of JSON Schema, it meets that criteria.

The link you're referring to in the "references" section is "informative" and should be regarded as such. It was the current draft at the time RAML 1.0 was released.

tomsfernandez commented 3 years ago

Great thanks! I'm closing this issue.

jstoiko commented 3 years ago

Despite my previous comment, there still seems to be some ambiguity surrounding that part of the spec.

Given a RAML data type definition with an !include statement referring to a .json file[1] containing a JSON data structure[2] but for which the actual schema/type definition language is ambiguous, how should a RAML processor treat such definition?

There are two ways to interpret this:

  1. as a RAML data type expressed as JSON, JSON is valid YAML 1.2 after all so any RAML node can be expressed in JSON; or
  2. as a JSON Schema with no $schema defined, JSON Schema draft3+ allows this in which case that’s up to the JSON Schema validator to default to a given draft.

The "Using XML and JSON Schema" section of the spec prescribes RAML processors to support JSON Schema as an alternative to the RAML type system but with additional restrictions, however it doesn't acknowledge the edge-case scenario described above.

The “Resolving Includes” section says:

When RAML or YAML files are included, RAML parsers MUST NOT only read the content, but must also parse it and add the content to the declaring structure as if the content were declared inline. RAML parsers MUST parse the content of the file as RAML content and append the parsed structures to the RAML document node if the included file has a .raml, .yml, or .yaml extension or one of the following media types:

  • application/raml+yaml
  • text/yaml
  • text/x-yaml
  • application/yaml
  • application/x-yaml

but that doesn't help either.

Reopening this issue as this needs to

[1]

type: !include myType.json

[2]

{
  "type": "object",
  "properties": {
    "Foo": {
      "type": "string"
    }
  }
}