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

Should the data type for limit parameter be a String or Number? #167

Closed
thadguidry opened this issue Apr 11, 2024 · 3 comments · Fixed by #169
Closed

Should the data type for limit parameter be a String or Number? #167

thadguidry opened this issue Apr 11, 2024 · 3 comments · Fixed by #169
Labels
API design Where we discuss any changes we want to introduce in the API documentation Improvements or additions to documentation

Comments

@thadguidry
Copy link
Contributor

thadguidry commented Apr 11, 2024

The current wording for limit under Data Extension Property Proposals says

Optionally, the requested limit

and ideally would instead give the data type

An optional string value to control the number of proposed properties fetched.

We do have a paragraph further above that limit parameter that mentions it's a String data type? as

The service SHOULD support an optional limit query string parameter to control the number of proposed properties.

But I noticed that we have other numerical values for things like this, such as Query's limit, and Preview's width, height and also Candidates score, and wondered if we should ensure that we use numerical data types for parameter values always expected to be a number like limit ?

@thadguidry thadguidry added documentation Improvements or additions to documentation API design Where we discuss any changes we want to introduce in the API labels Apr 11, 2024
@wetneb
Copy link
Member

wetneb commented Apr 11, 2024

The example makes it clear that this limit should be an integer, not a string. Would you like to make a PR to clarify this in the description of the field if you think that would be helpful?

@thadguidry
Copy link
Contributor Author

We absolutely don't want to wrap a standard around examples. W3C fully says "do not do that".

Yeap, PR coming.

@thadguidry
Copy link
Contributor Author

Generally, we need better display of data types for parameters in Respec which can sorta help #95 and also #157

So, I'll work on all that in separate PR's

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API design Where we discuss any changes we want to introduce in the API documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants