You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should the use of AsyncAPI be mandated to describe the PubSub facilities?
E.g: An OGC API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels and message payload descriptions.
As far as I know, AsyncAPI can describe the various likely candidate protocols such as MQTT, AMQP, etc., so I am in favour if keeping it simple, as above.
OGC API Common Part 1: Core, clause 6.6.2 states a looser requirement for OpenAPI:- This OGC API Standard uses OpenAPI 3.0 fragments in examples and to formally state requirements. Using OpenAPI 3.0 is not required for implementing an OGC API. Other API definition languages may be used along with, or instead of, OpenAPI. However, any API definition language used should have an associated conformance class advertised through the / conformance path. This Standard includes a conformance class for OGC API definitions that follow the OpenAPI specification 3.0. Alternative API definition languages are also allowed. Conformance classes for additional API definition languages will be added as the OGC API landscape continues to evolve.
The text was updated successfully, but these errors were encountered:
Should the use of AsyncAPI be mandated to describe the PubSub facilities?
E.g:
An OGC API SHALL provide the description of its Publish-Subscribe capabilities using AsyncAPI to describe supported protocols, channels and message payload descriptions.
As far as I know, AsyncAPI can describe the various likely candidate protocols such as MQTT, AMQP, etc., so I am in favour if keeping it simple, as above.
OGC API Common Part 1: Core, clause 6.6.2 states a looser requirement for OpenAPI:-
This OGC API Standard uses OpenAPI 3.0 fragments in examples and to formally state requirements. Using OpenAPI 3.0 is not required for implementing an OGC API. Other API definition languages may be used along with, or instead of, OpenAPI. However, any API definition language used should have an associated conformance class advertised through the / conformance path. This Standard includes a conformance class for OGC API definitions that follow the OpenAPI specification 3.0. Alternative API definition languages are also allowed. Conformance classes for additional API definition languages will be added as the OGC API landscape continues to evolve.
The text was updated successfully, but these errors were encountered: