Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format Registry documentation is not accurate / well published #3703

Closed
LasneF opened this issue Apr 12, 2024 · 4 comments
Closed

Format Registry documentation is not accurate / well published #3703

LasneF opened this issue Apr 12, 2024 · 4 comments

Comments

@LasneF
Copy link

LasneF commented Apr 12, 2024

Looking on the page here https://spec.openapis.org/registry/format/
as well on the JSON content here https://spec.openapis.org/api/format.json

there are some mistakes in the collumn type

for instance :
decimal A fixed point decimal number of unspecified precision and range stringnumber
should be string, number

for in64 we have an other version
int64 signed 64-bit integer numberstring

only sf integer looks correct

then about the JSON content , to me the given the constrains that a format can apply to multiple base type it should be represented as an array

"base_type": "numberstring" => "base_type": [ "number","string"]

@LasneF LasneF changed the title Format Registry documentation is not accurate Format Registry documentation is not accurate / well published Apr 12, 2024
@LasneF
Copy link
Author

LasneF commented Apr 12, 2024

Looking a bit deeper in gh-page repo , it looks like data is accurate , but it is more a generation issue of the HTML document and of the JSON document that does not leverage the data

for instance int64 is correctly described here
https://raw.githubusercontent.com/OAI/OpenAPI-Specification/gh-pages/registries/_format/int64.md

@handrews
Copy link
Contributor

Yes, something is concatenating two type values instead of rendering them as a comma-separated list.

@Bellangelo
Copy link
Contributor

I found a solution on this one and I will open a PR soon. It is worth noting that the only reason the sf-integer is shown correctly it is because we have wrongly set its base type to string. Which means that the base type is basically set to "integer, string" instead of ["integer", "string"].
You can check it also by the produced JSON: https://spec.openapis.org/api/format.json

@handrews
Copy link
Contributor

Resolved by @Bellangelo 's PR - I just checked the rendered pages and they look good now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

3 participants