The goal of this issue is to create a 2.0 version of the Data Dictionary specification.
This is a major change due to the fact that enforcement of lookups is being added, as well as stricter validation of what's in the payload against the server metadata.
The following sections are needed:
[x] Summary of Changes
[x] Specification
[x] Certification
We will also be moving the generated testing rules and artifacts over to this repository as part of the change.
Update (7/2022) - Link to Commander PR with DD 1.7 enumeration checking (GitHub)
Ignored Enumeration Values
There is a process and JSON format for adding known exceptions (i.e. true local) to the testing tools. These should go through a PR process, either by providers suggesting changes directly, or creating a ticket with the proposed changes to make for those who might not want to edit JSON directly.
Running the Commander with the revision above may flag things that are truly local, but look similar to what's defined in the standard.
Canonical example: Country Road vs. County Road DD 2.0. Ignored value: "ignored": ["CountryRoad"]
If a provider doesn't pass testing, they should open a ticket or PR describing the case that failed.
The changes will be reviewed by RESO staff and workgroups, as needed.
In some cases, the DD might want to consider cases such as this for promotion into the the standard, at which point they'd be removed from the ignored list.
The goal of this issue is to create a 2.0 version of the Data Dictionary specification.
This is a major change due to the fact that enforcement of lookups is being added, as well as stricter validation of what's in the payload against the server metadata.
The following sections are needed:
We will also be moving the generated testing rules and artifacts over to this repository as part of the change.
Update (7/2022) - Link to Commander PR with DD 1.7 enumeration checking (GitHub)
Examples
Ignored Enumeration Values There is a process and JSON format for adding known exceptions (i.e. true local) to the testing tools. These should go through a PR process, either by providers suggesting changes directly, or creating a ticket with the proposed changes to make for those who might not want to edit JSON directly.
See: https://github.com/RESOStandards/web-api-commander/blob/main/src/main/resources/ignored.json
How does it work?
"ignored": ["CountryRoad"]In some cases, the DD might want to consider cases such as this for promotion into the the standard, at which point they'd be removed from the ignored list.