Proposing new Types

[wertzui]

I'm missing some types and would like to get some feedback if they might be implemented in the spec.

• bool: Simple boolean values. Either true or false. Together with required, the client would either render a normal checkbox, or a tri-state-checkbox.
• datetime-offset: An ISO 8601 encoded string. This would be good to support users who use an API from different time zones. The default JavaScript Date-constructor automatically takes care of converting it into the browsers local timezone.
• duration: An ISO 8601 encoded string. Must start with a 'P'. This is also supported in the upcoming ECMAScript Temporal spec, see https://tc39.es/proposal-temporal/docs/index.html
• image: A valid image URL. Can also be a data URL, like data:image/png;base64,.... A client interface would render the image and a text input and / or a file upload.
• file: A valid URL. Can also be a data URL. A client interface would render a download-button and a text input and / or a file upload. I've read support HTML5 types for inputs #36 and think, this is a valid solution.

For further aid, I would also like to propose a new field on properties:
mimeTypes which would be OPTIONAL and may contain an array of MIME-types. This would help clients to know which types for image and file are accepted.

[mamund]

some interesting items on this list. would like to hear from others on which seems compelling additions.

as mentioned elsewhere here, the recommended approach is to create a working valid extension that is backward-compatible. then we can all see what it takes to implement it and test it against existing client applications to make sure the fallbacks are acceptable on all sides.

a side note: since HAL-FORMS might be used in UI settings as well as API settings, you should be sure that each extension has a viable solution for both use cases. we've tried to steer clear to writing specs that tell implementors what the UI should look-like and focus on how response consumers can recognize the feature and deal with it in both API and UI cases.

looking forward to seeing some of this in action.

[wertzui]

Do you mean an implementation of the spec with the mentioned additions when you write: "a working valid extension that is backward-compatible"?

If yes, I'm currently working on one and will report back once it is finished.

[wertzui]

I found the need for two more types:

• percent: A number which should be displayed as percent by multiplying it with 100 and appending a percentage sign (%).
• currency: A number that represents a currency value. Depending on the region for this currency, the client should format it appropriate and prepend or append (depending on the rules of the region) the currency symbol for the region.