search

mamund / hal-forms

backward-compatible extension for HAL to support dynamic forms at runtime.
MIT License
30 stars 18 forks source link

Typos in type definition #88

Open Ickbinet opened 3 years ago

Ickbinet commented 3 years ago

https://rwcbook.github.io/hal-forms/#_code_type_code

"Possible settings for the type value adn teh expected contents to be returned inthe are:"

Should be?:

"Possible settings for the type value and the expected contents to be returned in here are:"

odrotbohm commented 3 years ago

It might also be a good chance to add a note on whether the list of possible values for type is exhaustive. That list is very close to HTML input types except checkbox, radio and file. Are other types generally supported, too?

mamund commented 3 years ago

update got reverted somehow. will fix

and, yes, we should state that "type" list is not exclusive. with a fallback for when client's don't recognize the value of "type"

odrotbohm commented 3 years ago

Should we remove the sentence about type being an "enumerated attribute"? It's that one, that led me to assume exhaustiveness of the list given. Because, if arbitrary other types are allowed as well, there's no enumeration anymore, is there?

mamund commented 3 years ago

removing would be OK w/ me. AFAIK, the word's definition does not call for exhastiveness. but happy to improve clarity here.

odrotbohm commented 3 years ago

As we're following concepts of HTML pretty closely I had assumed it was a reference to the concept of an enumerated attribute like this: https://stackoverflow.com/questions/4104110/what-are-enumerated-attributes-in-html

mamund commented 3 years ago

that's a very reasonable assumption. i agree that we should drop "enumerated". it's a small change for a big win.