Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unknown type for array with anyOf items #94

Closed
wayneashleyberry opened this issue Nov 19, 2018 · 8 comments
Closed

Unknown type for array with anyOf items #94

wayneashleyberry opened this issue Nov 19, 2018 · 8 comments

Comments

@wayneashleyberry
Copy link

wayneashleyberry commented Nov 19, 2018

What did you do

jsonschema -d .

What did you expect to happen

An array type with multiple item types should be documented correctly, with links to each allowed type.

What happened

Unknown type.

What's your environment

  • Operating System: macOS 10.14.1
  • node.js version: 11.2.0

Do you have example files:

For this schema:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "properties": {
        "items": {
            "type": "array",
            "items": {
                "anyOf": [
                    {
                        "$ref": "#/definitions/Thing"
                    },
                    {
                        "$ref": "#/definitions/OtherThing"
                    }
                ]
            }
        }
    },
    "definitions": {
        "Thing": {
            "properties": {}
        },
        "OtherThing": {
            "properties": {}
        }
    }
}

I'm getting following Markdown:

Array type: array
All items must be of the type:
Unknown type ``.


Test files and output can be found here: https://github.com/wayneashleyberry/jsonschema2md-issues/tree/master/array-of

@trieloff trieloff added the bug label Nov 19, 2018
@trieloff
Copy link
Collaborator

I suggest to turn "Thing or Other Thing" into a new schema and reference that. Documenting type structures of arbitrary depth is quite hard (especially in Markdown, where you have only limited ways of expressing nesting and structure), so this would make your Schema a bit more comprehensible.

@wayneashleyberry
Copy link
Author

@trieloff what would a schema that could have many "sub-schema's" look like?

To try and make this clearer, the case I'm working with is an array of layers where a layer can be a text layer, image layer or shape layer. I started out with conditional validation on an enum but that soon got out of hand because the single "layer" schema was massive.

I now have a layer schema which each typed layer "inherits" and it's working really well. The only change I'd expect in the documentation is for "All items must be of the type: Unknown type ``." to read "All items must be of the type ImageLayer, `TextLayer` or `ShapeLayer`" if that makes sense?

@wayneashleyberry
Copy link
Author

Here's a simplified example of the actual project I'm working on:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "title": "Project",
    "properties": {
        "layers": {
            "type": "array",
            "minItems": 1,
            "items": {
                "oneOf": [
                    {
                        "$ref": "#/definitions/TextLayer"
                    },
                    {
                        "$ref": "#/definitions/ImageLayer"
                    },
                    {
                        "$ref": "#/definitions/ShapeLayer"
                    }
                ]
            }
        }
    },
    "definitions": {
        "ImageLayer": {
            "allOf": [
                {
                    "$ref": "#/definitions/Layer"
                }
            ],
            "properties": {
                "layerType": {
                    "const": "image"
                }
            }
        },
        "TextLayer": {
            "allOf": [
                {
                    "$ref": "#/definitions/Layer"
                }
            ],
            "properties": {
                "layerType": {
                    "const": "text"
                },
                "text": {
                    "type": "string",
                    "examples": [
                        "Hello, World!"
                    ]
                }
            },
            "required": [
                "text"
            ]
        },
        "ShapeLayer": {
            "allOf": [
                {
                    "$ref": "#/definitions/Layer"
                }
            ],
            "properties": {
                "layerType": {
                    "const": "shape"
                }
            }
        },
        "Layer": {
            "type": "object",
            "title": "Layer",
            "properties": {
                "layerType": {
                    "type": "string",
                    "enum": [
                        "text",
                        "image",
                        "shape"
                    ]
                },
                "opacity": {
                    "description": "This field represents the opacity of a layer, zero being completely transparent.",
                    "type": "number",
                    "minimum": 0,
                    "maximum": 1,
                    "examples": [
                        0.754
                    ]
                }
            },
            "required": [
                "layerType"
            ]
        }
    }
}

@trieloff
Copy link
Collaborator

"All items must be of the type: Unknown type ``." to read "All items must be of the type ImageLayer, TextLayer or `ShapeLayer`" if that makes sense?

Yes, that makes sense. For jsonschema2md only schemas that are in their own file (and built-in types) are treated as named types. This means if you move the definitions of Layer, ImageLayer, TextLayer, etc. into separate files, jsonschema2md can pick up the name, and create a nice documentation page for each schema. If you keep it as definitions inside a big schema, jsonschema2md will try to inline the documentation if it is not too deep, or just give up.

In XDM we have something quite similar with Image and Video, which both extend Asset:

@trieloff trieloff mentioned this issue Dec 11, 2019
7 tasks
trieloff pushed a commit that referenced this issue Dec 16, 2019
# [4.0.0](v3.3.1...v4.0.0) (2019-12-16)

### Bug Fixes

* **i18n:** use correct file name format ([43a74f4](43a74f4))
* **markdown:** constraint values can be zero now ([2e057fd](2e057fd))
* **markdown:** handle null as a constant value ([e652e11](e652e11))
* **proxy:** remove logging statements ([616a1d9](616a1d9))
* **schemas:** remove references going nowhere ([2186142](2186142))

### Build System

* **dependencies:** remove unused dependencies ([dbc9192](dbc9192))

### Code Refactoring

* **cli:** remove bluebird, lodash, simplify arg parsing ([b6b1822](b6b1822))

### Continuous Integration

* **test:** require node 10 ([ba4a947](ba4a947))

### Documentation

* **changelog:** mention changes for v4 ([4dfe90c](4dfe90c)), closes [#126](#126) [#174](#174) [#72](#72) [#73](#73) [#94](#94) [#52](#52) [#20](#20) [#125](#125) [#177](#177) [#34](#34) [#123](#123)

### Features

* **cli:** generate JSON schema output ([dd18f3b](dd18f3b)), closes [#176](#176)
* **formats:** add support for formats: json-pointer, relative-json-pointer, regex, and uri-template ([689c158](689c158))
* **i18n:** new internationalization system ([1a664de](1a664de))
* **i18n:** provide complete en_US translation ([5eb0c89](5eb0c89))
* **markdown:** add header surpression ([6225b9f](6225b9f))
* **markdown:** add support for `default` keyword ([72a0fde](72a0fde))
* **markdown:** add support for comments ([07bb52f](07bb52f))
* **markdown:** add YAML frontmatter support ([4df92e6](4df92e6))
* **markdown:** create and write markdown ([e521541](e521541))
* **markdown:** generate additional detail ([cc07df2](cc07df2))
* **markdown:** generate header again ([011427c](011427c))
* **markdown:** generate some property details ([fa34cf1](fa34cf1))
* **markdown:** generate type details ([c9f19e1](c9f19e1))
* **markdown:** highlight keyword usage for documentation ([d35e4ed](d35e4ed)), closes [#100](#100)
* **markdown:** list nested schemas in README ([608674b](608674b))
* **markdown:** list nested schemas in README ([87e8489](87e8489))
* **markdown:** show examples ([c8e8dfa](c8e8dfa))
* **markdown:** show extensibility and abstraction in header ([90a9a8e](90a9a8e))
* **markdown:** show id and status in header ([08e1923](08e1923))
* **markdown:** show id and status in header ([b6fcf53](b6fcf53))
* **markdown:** show join types ([12af018](12af018))
* **markdown:** show some info about properties, switch i18n library ([f8a32df](f8a32df))
* **markdown:** show type, link, additional and custom properties in header ([eff129a](eff129a))
* **markdown:** show value constraints ([515969c](515969c))
* **markdown:** support item arrays and additionalItems ([c9fbcdf](c9fbcdf)), closes [#31](#31)
* **markdown:** support patternProperties and additionalProperties ([1386ee3](1386ee3)), closes [#95](#95) [#180](#180)
* **proxy:** generate meta information ([ac65ac6](ac65ac6))
* **proxy:** generate slugs ([eacbf38](eacbf38))
* **proxy:** resolve references ([4cea068](4cea068))
* **readme:** generate readme again ([d6b9e5e](d6b9e5e))
* **readme:** mention the most common schema version ([fc583d7](fc583d7))
* **schema:** add full support for "A Vocabulary for the Contents of String-Encoded Data" ([96ca3a6](96ca3a6))
* **schema:** add support for keyword `$defs` ([70b63c8](70b63c8))
* **schema:** add support for keyword `deprecated` ([934b856](934b856))
* **schema:** add support for readOnly and writeOnly schemas and properties ([7452882](7452882))

### BREAKING CHANGES

* **changelog:**
* **i18n:** The file format for the i18n files has changed

You can now specify the language to use using `-l` and `jsonschema2md` will pick up the correct language configuration.
* **test:** Node 8 is no longer supported
* **dependencies:** Removes the JSON schema validation feature entirely
* **cli:** Repaces lodash with ferrum, removed bluebird, changes the meaning of `--schema-out` or `-x` to be no longer relative to output dir

The `--schema-out` or `-x` command line option is no longer relative to the output path (specified with `-o` or `--out`)
@trieloff
Copy link
Collaborator

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@wayneashleyberry
Copy link
Author

@trieloff I'm not seeing v4.0.0 on npm yet?

@trieloff
Copy link
Collaborator

@wayneashleyberry
Copy link
Author

Yeah, I see it now - thanks @trieloff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants