Include Schemas in raml context

[justjacksonn]

Currently, the schemas defined in the root of a raml file, as well as schemas embedded within the raml file are not accessible in any way via the raml context object.

It would be ideal to have a allSchemas (like allResources) option that would be a flat list of all schema files. This should be some form of object though.. because in some cases the schemas are include files, and in others they are inlined. I'd argue against loading up all the include schemas into memory and work towards not using inlined schemas at all, but it is what it is now, so I'd urge that we keep the flat list that includes the type (inline or file) and the actual value (the path/file, or the string of inlined schema).

Then perhaps for each resource, we have the schema option so that as we iterate a resource, we can access the schema if need be (maybe this is there now? I haven't looked to see if that is possible).

[blakeembrey]

It should be accessible on each resource body? That would be the best way to iterate over all the schemas (it should exist right now). Aside from that, having an allSchemas can work but in some cases (inline or !include'd schemas) we won't have a name for the schema to map it back to.

[justjacksonn]

Ok.. the initial reason behind this is to have the ability to generate language bindings for the schemas, such as java pojos from the schemas, that are then used by the SDK templates. Of course it doesn't matter the order until the code is actually compiled or used, but right now I am running a separate task outside of raml-generator to find and run jsonschema2pojo on all the .json files in a specified directory. It would be far better to have a list of all schemas in one shot. Also, in the case of using each resource schema: attribute, it allows for aliases to the schemas: list at the root of the RAML doc, so I would still need a way to match a resource schema alias to the root schema it refers to if the resource schema is not inlined or included at that point.

[sichvoge]

@blakeembrey, first the allSchemas should be on the context level and second, you can give an id or name into your json schema you can use, for example, and in XSDs it is name. So that should work, right? How do you store the schemas? Is it just the pure string or json object or ...?

[justjacksonn]

So I'll add to this after talking with Blake a bit on gitter yesterday.
Each of the resource methods/bodies have the schemas loaded as a String.
So, correct me if I am wrong Blake, but in the case of an alias used in a
body schema section, I think the string of the schema is loaded up at that
point, such that resource.methods.post.body.mediatype.schema is a string of
the json schema (or xsd) and not just the name (alias) that is used. So I
assume in the code Blake actually looks up the alias name, and loads the
schema at that point.

On Wed, Apr 8, 2015 at 11:53 PM, Christian Vogel [email protected]
wrote:

@blakeembrey https://github.com/blakeembrey, first the allSchemas
should be on the context level and second, you can give an id or name
into your json schema you can use, for example, and in XSDs it is name. So
that should work, right? How do you store the schemas? Is it just the pure
string or json object or ...?

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[blakeembrey]

Yes, that's correct. It's a feature of the current RAML 0.8 parser. A lot of schema stuff (I think) relies on context like the media type of the body. There's also request/response schemas. It should be an all or none feature, so if we make a global schema feature we should rewrite all the schemas to be references to the global instance. What do you think?

var allSchemas = {
  [id: string]: {
    id: string /* Same name as parent, can be completely random/unique like resource/method ids */
    schema: string
  }
}

var resource = {
  body: {
    'application/json': {
      schema: /* Reference to the global schema instance */
    }
  }
}

[justjacksonn]

I do like the idea of global schema but can I urge for the sake of memory
consumption and large apis and schemas that the actual schema text not be
loaded until accessed or have a separate allSchemas[0].load or something.
That way only the schema needed is purposely loaded at the time of need.
The key should be the alias name found in the individual body schema
elements which is what I think you ate saying g Blake
On Apr 10, 2015 12:38 PM, "Blake Embrey" [email protected] wrote:

Yes, that's correct. It's a feature of the current RAML 0.8 parser. A lot
of schema stuff (I think) relies on context like the media type of the
body. There's also request/response schemas. It should be an all or none
feature, so if we make a global schema feature we should rewrite all the
schemas to be references to the global instance. What do you think?

var allSchemas = {
[id: string]: {
id: string /* Same name as parent, can be completely random/unique like resource/method ids /
schema: string
}
}
var resource = {
body: {
'application/json': {
schema: / Reference to the global schema instance */
}
}
}

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[blakeembrey]

If the schemas loading become an issue to you, please let me know. Right now loading the schema strings is a decision by the current RAML 0.8 parser, but we can look at patching it with additional features when needed.

[justjacksonn]

Fair enough.
On Apr 10, 2015 7:26 PM, "Blake Embrey" [email protected] wrote:

If the schemas loading become an issue to you, please let me know. Right
now loading the schema strings is a decision by the current RAML 0.8
parser, but we can look at patching it with additional features when needed.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.