In our ocrd-tool schema, for the parameters we only have
|
properties: |
|
type: |
|
type: string |
|
description: Data type of this parameter |
|
enum: |
|
- string |
|
- number |
|
- boolean |
|
- object |
|
- array |
|
format: |
|
description: Subtype, such as `float` for type `number` or `uri` for type `string`. |
|
description: |
|
description: Concise description of syntax and semantics of this parameter |
|
required: |
|
type: boolean |
|
description: Whether this parameter is required |
|
default: |
|
description: Default value when not provided by the user |
|
enum: |
|
type: array |
|
description: List the allowed values if a fixed list. |
|
content-type: |
|
type: string |
|
description: "If parameter is reference to file: Media type of the file" |
|
cacheable: |
|
type: boolean |
|
description: "If parameter is reference to file: Whether the file should be cached, e.g. because it is large and won't change." |
|
default: false |
This excludes perfectly sound data JSON qualifiers like
items (for restrictions on the list items if type==array)minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf (for numerical restrictions if type==number)- fileGrp names not conforming to
^OCR-D-[A-Z0-9-]+$ (which should be allowed by spec now)
The first two yield an error saying Additional properties are not allowed, the latter directly mocks the regex.