docs: update usage documentation

docs/inputs/JSON_Schema.md

@@ -22,7 +22,7 @@ The order of interpretation:
 - `dependencies` only apply to schema dependencies, since property dependencies adds nothing to the underlying model. Any schema dependencies are interpreted and then [merged](#Merging-models) together with the current interpreted model.
 - `enum` is interpreted as is, where each `enum`. Usage of `enum` infers the enumerator value type to the model, but only if the schema does not have `type` specified.
 - `const` interpretation overwrite already interpreted `enum`. Usage of `const` infers the constant value type to the model, but only if the schema does not have `type` specified.
-- [oneOf/anyOf/then/else](#Processing-sub-schemas)
+- [allOf/oneOf/anyOf/then/else](#Processing-sub-schemas)
 - [not](#interpreting-not-schemas)
 
 ## Interpreting not schemas
@@ -36,13 +36,9 @@ Currently, the following `not` model properties are interpreted:
 - You cannot use nested `not` schemas to infer new model properties, it can only be used to re-allow them.
 - boolean `not` schemas are not applied.
 
-## allOf sub schemas
-`allOf` is a bit different than the other [combination keywords](#Processing-sub-schemas) since it can imply inheritance. 
-
-So dependant on whether the interpreter option `allowInheritance` is true or false we interpret it as inheritance or [merge](#Merging-models) the models.
-
 ## Processing sub schemas
 The following JSON Schema keywords are [merged](#Merging-models) with the already interpreted model:
+- `allOf`
 - `oneOf`
 - `anyOf`
 - `then`

docs/usage.md

@@ -12,12 +12,18 @@ For more specific integration options, please check out the [integration documen
 
 - [Understanding the output format](#understanding-the-output-format)
 - [Generate models from AsyncAPI documents](#generate-models-from-asyncapi-documents)
+  * [Limitations and Compatibility](#limitations-and-compatibility)
+    + [Message Schema formats](#message-schema-formats)
+    + [Polymorphism](#polymorphism)
 - [Generate models from JSON Schema documents](#generate-models-from-json-schema-documents)
 - [Generate models from Swagger 2.0 documents](#generate-models-from-swagger-20-documents)
+  * [Limitations and Compatibility](#limitations-and-compatibility-1)
+    + [Polymorphism](#polymorphism-1)
 - [Generate models from OpenAPI documents](#generate-models-from-openapi-documents)
+    + [Limitations and Compatibility](#limitations-and-compatibility-2)
+      - [Polymorphism](#polymorphism-2)
 - [Generate models from TypeScript type files](#generate-models-from-typescript-type-files)
 - [Generate models from Meta models](#generate-models-from-meta-models)
-- [Generate models from OpenAPI documents](#generate-models-from-openapi-documents-1)
 - [Generate Go models](#generate-go-models)
 - [Generate C# models](#generate-c%23-models)
 - [Generate Java models](#generate-java-models)
@@ -30,73 +36,105 @@ For more specific integration options, please check out the [integration documen
 
 ## Understanding the output format
 
-TODO
+The output format is designed for you to use the generated models in further contexts. It might be part of a larger code generation such as AsyncAPI templates. This means that you can glue multiple models together into one large file, or split it out as you see fit.
+
+All [generate functions](./generators.md) return an array of `OutputModel`s, which contains the following properties.
+
+| Property | Type | Description |
+|---|---|---|
+| `result` | String | The rendered content, that depends on whether you render it as a full model or partial model. |
+| `model` | [ConstrainedMetaModel](./processing.md#the-constrained-meta-model) | The constrained meta model that contains many other information about the rendered model. |
+| `modelName` | String | The rendered name of the model. |
+| `inputModel` | `InputMetaModel` | Contains all the raw models along side the input they where generated for. Check the code for further information. |
+| `dependencies` | String[] | List of rendered dependency imports that the model uses. |
 
 ## Generate models from AsyncAPI documents
 
-When providing an AsyncAPI document, the library iterates the entire document and generate models for all defined messages. If any other kind of iteration is wanted, feel free to create a [feature request](https://github.com/asyncapi/modelina/issues/new?assignees=&labels=enhancement&template=enhancement.md).
+When providing an AsyncAPI document, the library iterates the entire document and generate models for all defined message payloads. The message payloads are interpreted based on the schema format. 
+
+For JSON Schema it follows the [JSON Schema input processing](#generate-models-from-json-schema-documents).
 
 There are two ways to generate models for an AsyncAPI document.
 
-- [Generate from a parsed AsyncAPI document](../examples/asyncapi-from-parser)
-- [Generate from a pure JS object](../examples/asyncapi-from-object)
+- [Generate from a parsed AsyncAPI 2.x document](../examples/asyncapi-from-parser)
+- [Generate from an AsyncAPI 2.x JS object](../examples/asyncapi-from-object)
 
 The library expects the `asyncapi` property for the document to be set in order to understand the input format.
 
 The message payloads, since it is a JSON Schema variant, is [interpreted as a such](./inputs/JSON_Schema.md).
 
+### Limitations and Compatibility
+These are the current known limitation of the AsyncAPI input.
+
+#### Message Schema formats
+Currently, only a limited number of schema formats are supported and we currently rely on the [AsyncAPI parser](github.com/asyncapi/parser-js/) to handle those schema formats and convert them into [AsyncAPI Schema format](https://github.com/asyncapi/parser-js/#custom-message-parsers). At some point in the future, Modelina will support all native schema formats, so it does not matter which standard you use to define the message payloads, you will be able to generate models from it.
+
+#### Polymorphism
+
+Through the AsyncAPI Schema you are able to use `discriminator` for achieving polymorphism. Current version of Modelina does not generate the expected inheritance of models, instead it's current behavior is to [merge the schemas together](./inputs/interpretation_of_JSON_Schema.md#Processing-sub-schemas). This means you will still get access to the properties that missing inherited model has, but without the inheritance.
+
+Long term if this is something you wish was supported, voice your [opionion here](https://github.com/asyncapi/modelina/issues/108).
+
 ## Generate models from JSON Schema documents
 
 There is one way to generate models for a JSON Schema document.
 
-- [Generate from a pure JS object](../examples/json-schema-draft7-from-object)
-
-We support both draft-4, draft-6, and draft-7 documents.
+- [Generate from a JSON Schema draft 7 JS object](../examples/json-schema-draft7-from-object)
 
 The library expects the `$schema` property for the document to be set in order to understand the input format. By default, if no other inputs are detected, it defaults to `JSON Schema draft 7`. The process of interpreting a JSON Schema to a model can be read [here](./inputs/JSON_Schema.md).
 
 ## Generate models from Swagger 2.0 documents
 
-There are one way to generate models from a Swagger 2.0 document
+There are one way to generate models from a Swagger 2.0 document.
 
-- [Generate from a pure JS object](../examples/swagger2.0-from-object)
+- [Generate from a Swagger 2.0 JS object](../examples/swagger2.0-from-object)
 
 The Swagger input processor expects that the property `swagger` is defined in order to know it should be processed.
 
 The response payload and `body` parameters, since it is a JSON Schema variant, is [interpreted as a such](./inputs/JSON_Schema.md).
 
+### Limitations and Compatibility
+These are the current known limitation of the Swagger 2.0 input.
+
+#### Polymorphism
+
+Through the Swagger 2.0 Schema you are able to use `discriminator` for achieving polymorphism. Current version of Modelina does not generate the expected inheritance of models, instead it's current behavior is to [merge the schemas together](./inputs/interpretation_of_JSON_Schema.md#Processing-sub-schemas). This means you will still get access to the properties that missing inherited model has, but without the inheritance.
+
+Long term if this is something you wish was supported, voice your [opionion here](https://github.com/asyncapi/modelina/issues/108).
+
 ## Generate models from OpenAPI documents
 
 There are one way to generate models from an OpenAPI document
 
-- [Generate from a pure JS object](../examples/openapi-from-object)
+- [Generate from OpenAPI 3.0 JS object](../examples/openapi-from-object)
 
 The OpenAPI input processor expects that the property `openapi` is defined in order to know it should be processed.
 
 The response and request payloads, since it is a JSON Schema variant, is [interpreted as a such](./inputs/JSON_Schema.md).
 
+#### Limitations and Compatibility
+These are the current known limitation of the OpenAPI inputs.
+
+##### Polymorphism
+
+Through the OpenAPI 3.0 Schema you are able to use `discriminator` for achieving polymorphism. Current version of Modelina does not generate the expected inheritance of models, instead it's current behavior is to [merge the schemas together](./inputs/interpretation_of_JSON_Schema.md#Processing-sub-schemas). This means you will still get access to the properties that missing inherited model has, but without the inheritance.
+
+Long term if this is something you wish was supported, voice your [opionion here](https://github.com/asyncapi/modelina/issues/108).
+
 ## Generate models from TypeScript type files
 
 Currently, we support generating models from a TypeScript type file.
 
 - [Generate Java model from a TypeScript file](../examples/java-from-typescript-type/)
 
-The TypeScript input processor expects that the typescript file and base directory where it's present, is passed as input, in order to process the types accurately.
+The TypeScript input processor expects that the typescript file and base directory where it's present, is passed as input, in order to process the types accurately. The input processor converts the TypeScript types into JSON Schema, which are then passed on to the [JSON Schema processor](#generate-models-from-json-schema-documents). 
 
 ## Generate models from Meta models
 Sometimes, the supported inputs such as AsyncAPI and JSON Schema wont be enough for your use-case and you want to create your own data models while still utilizing the full sweep of features from the generators.
 
 You can do that by providing the [internal meta model](./internal-model.md#the-meta-model) as input. Check out this [example out for a live demonstration](../examples/meta-model).
 
-## Generate models from OpenAPI documents
-
-There are one way to generate models from an OpenAPI document
-
-- [Generate from a pure JS object](../examples/openapi-from-object)
-
-The OpenAPI input processor expects that the property `openapi` is defined in order to know it should be processed.
-
-The response and request payloads, since it is a JSON Schema variant, is [interpreted as a such](./inputs/JSON_Schema.md).
+Check out this [example out for a live demonstration](../examples/meta-model).
 
 ## Generate Go models