Clearly document what an implementer should do in the following scenarios:
They want to publish data not currently covered by the specifications
They want to support a mechanism or feature that does not appear in the Open Booking flow
E.g.
a) Use extension mechanisms
Useful for cases where it's unlikely others will have the same use case - such as booking system or provider specific data.
Document how to use custom namespaces, with examples of these, both for open data publishing and custom Open Booking API endpoints
b) Promote the new use case within the OpenActive standards processes
Raise on implementers forum Slack channel, in the first instance
You may be prompted to create a GitHub issue with your use case and proposal
This then gets raised for discussion in a W3C call
With agreement in that forum, actions are taken to produce light initial guidance that we can use to encourage convergence, including usage guidance for defined beta properties where appropriate
The documentation, tooling and validator are updated accordingly if needed, for example with support for a new beta property in simple cases, or a sample feed in complex cases
Clearly document what an implementer should do in the following scenarios:
E.g.
a) Use extension mechanisms
Useful for cases where it's unlikely others will have the same use case - such as booking system or provider specific data.
Document how to use custom namespaces, with examples of these, both for open data publishing and custom Open Booking API endpoints
b) Promote the new use case within the OpenActive standards processes