Bug: usage of `oneOf` causing problems

[jbrown-xentity]

Name: James Brown

Affiliation: GSA/data.gov

Type of issue: Schema systemic issue with oneOf

Issue: Currently the default when describing possible options for a field utilizes oneOf. This is limiting, in that it can only match a single implementation of the options (not matching multiple). This becomes an issue when there is overlap. For example, accrualPeriodicity can be multiple different standards (ISO, DCAT, etc), and there is overlap for terms like quarterly. Also for date validation (which is in dozens of places), a valid year implementation like 2025 will fail because it matches multiple possible formats. See example here.

Recommended change(s):

Given there isn't currently any planned implementation where something matching multiple passing valid items should fail, we should turn all oneOf into anyOf implementations. Also should take the opportunity to "flatten" where possible.

[jbrown-xentity]

It should be noted this also makes validation more efficient, as once it finds a matching valid form it moves on.

"For disjoint types like null and string, anyOf and oneOf are equivalent, but oneOf actually requires checking all of the items because it needs to verify that precisely one of them matches. anyOf is a best-practice optimization in those cases where there’s no overlap in the types."