Generator: Other properties on the same level as oneOf
I have an object property in a payload which is defined as follows:
"crs": {
"description": "Coordinate reference system specified as [EPSG](http://www.epsg.org) code or [PROJ](https://proj4.org) definition. Defaults to `4326` (EPSG code 4326) unless the client explicitly requests a different coordinate reference system.",
"oneOf": [
{
"title": "EPSG Code",
"type": "integer",
"format": "epsg-code",
"example": 7099
},
{
"title": "PROJ definition",
"type": "string",
"format": "proj-definition",
"example": "+proj=moll +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs"
}
],
"default": 4326
},
Running the generator on it returns:
Invalid JSON obtained from the content of the AsyncAPI specification file
[ { code: 'OBJECT_ADDITIONAL_PROPERTIES',
params: [ 'oneOf' ],
message: 'Additional properties not allowed: oneOf',
path: '#/topics/data/publish/payload/properties/payload/properties/spatial_extent/properties/crs',
schemaId: 'http://asyncapi.hitchhq.com/v1/schema.json#',
description: 'A deterministic version of a JSON Schema object.',
[Symbol(z-schema/schema)]:
{ additionalProperties: false,
properties: [Object],
patternProperties: [Object],
description: 'A deterministic version of a JSON Schema object.',
type: 'object',
'__$validated': true },
[Symbol(z-schema/json)]:
{ asyncapi: '1.0.0',
info: [Object],
externalDocs: [Object],
baseTopic: 'openeo',
topics: [Object],
components: [Object] } } ]
I don't see this backed by the spec. It seems as if it is allowed to have things such as a default value and a description on the same level as oneOf etc. So it would be great to get a fix for this.
m-mohr
All 7 comments
Removing them doesn't solve the problem so there must be something else wrong, but I don't know what it is.
m-mohr
on 14 Feb 2019
Can you put a complete example of a definition you are trying to use
rmelian
on 14 Feb 2019
@rmelian Sure, here is a reduced example:
{
"asyncapi": "1.0.0",
"info": {
"title": "openEO API for Subscriptions",
"version": "0.4.0",
"description": "...",
"contact": {
"name": "openEO Consortium",
"url": "http://openeo.org/",
"email": "[email protected]"
},
"license": {
"name": "Apache 2.0",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html"
}
},
"baseTopic": "openeo",
"topics": {
"data": {
"publish": {
"summary": "Inform about changes regarding an EO dataset.",
"description": "At least one of the `temporal_extent` and `spatial_extent` fields MUST be specified.\n\nSubscriptions to this message can be restricted to a certain collection by specifying `name` and providing a valid collection name.",
"payload": {
"type": "object",
"required": [
"message",
"payload"
],
"properties": {
"message": {
"$ref": "#/components/schemas/message"
},
"payload": {
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"$ref": "#/components/schemas/collection_name"
},
"temporal_extent": {
"type": "array",
"description": "MUST be specified if the temporal extent of the dataset has changed. The temporal extent is always specified as an array, that consists of either a single timestamp or a start and an end time, each element formatted as a RFC 3339 date-time. Specifies the temporal extent of the data that has changed, not of the whole dataset. Example: The dataset covers images from beginning of 2015 until the end of 2018. A single image has been added, captured at the first day in 2019 at 01:00:00 UTC (1am). The spatial extent specified here must be an array containing a single string: `2019-01-01T01:00:00Z`.",
"example": [
"2016-01-01T02:30:00Z",
"2016-01-01T04:45:00Z"
],
"minItems": 1,
"maxItems": 2,
"items": {
"type": "string",
"format": "date-time"
}
},
"spatial_extent": {
"type": "object",
"description": "MUST always be specified. It is the spatial extent of the data that was changed. Specifies the spatial extent of the data that has changed, not of the whole dataset. Example: The dataset covers the whole world and an image of Austria has been added. The spatial extent specified here must be the bounding box of Austria.",
"required": [
"west",
"south",
"east",
"north"
],
"properties": {
"crs": {
"description": "Coordinate reference system specified as [EPSG](http://www.epsg.org) code or [PROJ](https://proj4.org) definition. Defaults to `4326` (EPSG code 4326) unless the client explicitly requests a different coordinate reference system.",
"oneOf": [
{
"title": "EPSG Code",
"type": "integer",
"format": "epsg-code",
"example": 7099
},
{
"title": "PROJ definition",
"type": "string",
"format": "proj-definition",
"example": "+proj=moll +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs"
}
],
"default": 4326
},
"west": {
"description": "West (lower left corner, coordinate axis 1).",
"type": "number"
},
"south": {
"description": "South (lower left corner, coordinate axis 2).",
"type": "number"
},
"east": {
"description": "East (upper right corner, coordinate axis 1).",
"type": "number"
},
"north": {
"description": "North (upper right corner, coordinate axis 2).",
"type": "number"
},
"base": {
"description": "Base (optional, lower left corner, coordinate axis 3).",
"type": "number"
},
"height": {
"description": "Height (optional, upper right corner, coordinate axis 3).",
"type": "number"
}
}
}
}
}
}
},
"example": {
"message": {
"issued": "2018-08-07T14:06:36Z",
"topic": "openeo.data"
},
"payload": {
"name": "MOD18Q1",
"temporal_extent": [
"2018-08-07T15:30:00Z",
"2018-08-08T16:43:00Z"
],
"spatial_extent": {
"west": 34.6,
"south": 39.6,
"east": 35.1,
"north": 40.1
}
}
}
}
}
},
"components": {
"schemas": {
"message": {
"type": "object",
"required": [
"topic",
"issued"
],
"properties": {
"issued": {
"type": "string",
"format": "date-time",
"description": "Date and time when the message was sent, formatted as a RFC 3339 date-time."
},
"topic": {
"type": "string",
"description": "Message type",
"example": "openeo.sample"
}
}
},
"collection_name": {
"type": "string",
"description": "Unique identifier for EO datasets.",
"example": "MOD18Q1"
}
}
}
}
I copied your definition to the online editor http://editor.asyncapi.org/ and it worked changing the asyncapi version to 1.2.0.
"asyncapi": "1.2.0"
can you try that?
rmelian
on 14 Feb 2019
👍1
actually, the reason is not working is because oneOf was introduced starting from version 1.1.0
you can find more information here https://fmvilas.com/announcing-asyncapi-1-1-0/
thanks, @fmvilas for pointing this out
rmelian
on 14 Feb 2019
👍2
@rmelian @fmvilas Thanks a lot for spotting that. I never noticed there's a new version. Maybe due to the fact that if you go to https://www.asyncapi.com/ and click "Learn" and "The specification" it still leads you to v1.0.0!
m-mohr
on 15 Feb 2019
Yep, we're now updating the website. It's creating many confusions. Thanks for reporting it!
fmvilas
on 15 Feb 2019
👍1
Was this page helpful?
0 / 5 - 0 ratings
Related issues
Ellocsys
路
9Comments
karlwbrown
路
8Comments
uraala
路
10Comments
alexanderTilg
路
10Comments
aravindajju
路
9Comments
Most helpful comment
actually, the reason is not working is because
oneOfwas introduced starting from version 1.1.0you can find more information here https://fmvilas.com/announcing-asyncapi-1-1-0/
thanks, @fmvilas for pointing this out