ORD Configuration
How to read this documentation
- The root schema of the document is ORD Configuration
Technical information
- Example files can be found here.
- Visual diagrams can be found here: ORD Configuration Class Diagram.
- The interface is described as JSON Schema here: /spec-v1/interfaces/Configuration.schema.json.
- A high-level overview can also be exported as Excel and CSV file.
- This documentation is automatically generated from ./spec/v1/Configuration.schema.yaml.
Schema Definitions
ORD Configuration
The ORD configuration response will indicate that ORD is available for the given host and how to proceed with the discovery.
Most notably, the ORD configuration will tell an ORD consumer which ORD documents are available and where/how they can be accessed.
The configuration endpoint is a Well-Known URI discovery mechanism.
Property | Type | Description |
---|---|---|
string | Optional URL to the ORD document schema (defined as JSON Schema). If given, this enables code intelligence and validation in supported editors (like VSCode) and tools. JSON Schema Format: uri-reference Recommended Values:
| |
string | Optional base URL that can be used to resolve the relative URLs to the ORD Documents. The baseUrl MUST not contain a leading slash.If you do not provide this property, the base URL is assumed to be the URL of the config endpoint without /.well-known/open-resource-discovery suffix.This implies that either a baseUrl or only absolute URLs MUST be provided when no standardized well-known URI is used.If both a baseUrl and a well-known URI is provided, the explicit baseUrl takes precedence.JSON Schema Format: uri Regex Pattern: ^http[s]?:\/\/[^:\/\s]+\.[^:\/\s\.]+(:\d+)?(\/[a-zA-Z0-9-\._~]+)*$ Example Values:
| |
ORD V1 Support
The existence of this version indicates that Open Resource Discovery is supported in Version 1.x
Property | Type | Description |
---|---|---|
Array<ORD V1 Document Description> | List of all ORD documents that can be retrieved. While it is possible to describe everything in one big ORD document, for bigger services/use cases it might be preferable to split the information into multiple documents. For more details how to implement this correctly, please refer to the ORD configuration endpoint section and the considerations on the granularity of ORD documents. |
ORD V1 Document Description
Describes an ORD Document that is available for pull transport consumption.
Property | Type | Description |
---|---|---|
string | URL or relative URL to the ORD document (provided by an ORD document endpoint). It is RECOMMENDED to provide a relative URL (to baseUrl ).If a baseUrl is given, the relative URLs will be resolved with it.If the URL is not relative to the system providing this information or no well-known URI is used, either the baseUrl or a full URL to the document MUST be provided. JSON Schema Format: uri-reference Example Values:
| |
boolean | Whether the information in the ORD document is system instance aware. This is the case when the provided ORD document potentially differs between system instances. Please note that if a system does not support multitenancy, most likely each system instance has its own URL and different system instances could even be deployed in a different state (version). If those conditions apply, systemInstanceAware MUST be set to true.An ORD aggregator that represents a system instance aware perspective MUST fetch a system instance aware ORD document, not just once per system type but once per system instance. Please note that you can define system instance awareness also on the level of an ORD resource. It is even possible and valid to have an ORD document that is NOT system instance aware to contain resources that are. This can be the case because the resource is described in separate resource definition formats which would change, while the ORD document itself would not change (the links to the resource definition files stay the same). If some ORD information is system instance aware and some is not, we RECOMMEND to split the information into separate documents and mark their system instance awareness accordingly. Example Values:
| |
Array<Access Strategy> | List of supported access strategies for retrieving the metadata from the ORD provider. An ORD Consumer/ORD Aggregator MAY freely choose any of the listed strategies. Array Constraint: MUST have at least 1 items |
Access Strategy
Defines the access strategy for accessing the ORD documents from the ORD provider.
Property | Type | Description |
---|---|---|
string | Defines the authentication/authorization strategy through which the referenced ORD Documents can be accessed. Allowed Values:
Example Values:
| |
string | If the fixed type enum values need to be extended, an arbitrary customType can be provided.MUST be a valid Specification ID. MUST only be provided if type is set to custom .Regex Pattern: ^([a-z0-9]+(?:[.][a-z0-9]+)*):([a-zA-Z0-9._\-]+):v([0-9]+)$ Maximum Length: 255 Example Values:
| |
string | Human-readable description about how the access is set up, notated in CommonMark (Markdown). MUST only be provided if type is set to custom .Minimum Length: 1 Example Values:
|