|
|
Post by tophercantrell on Apr 25, 2018 15:25:19 GMT
Are empty strings common in Redfish payloads? I don't see anything in the specification that prohibits empty strings for things like "Manufacturer" and "Name", though maybe "null" is a better value in those cases. Very specifically, should our UI give the user the ability to "blank" a text field and send an empty string? I am trying to think of good examples where that would be needed. Thanks for the assist!
|
|
|
|
Post by gericson on Apr 25, 2018 18:35:12 GMT
Some applications distinguish between null and an empty string. However, both simply indicate an absence of value. It should be equivalent to PATCH Manufacturer=null or Manufacturer="" If a property is specified as Nullable="false", then a non-null (non empty) string must be supplied. For example from ComputerSystem_v1.xml: <Property Name="SystemType" Type="ComputerSystem.v1_0_0.SystemType" Nullable="false"> |
|
|
|
Post by jautor on Apr 26, 2018 3:49:45 GMT
Are empty strings common in Redfish payloads? I don't see anything in the specification that prohibits empty strings for things like "Manufacturer" and "Name", though maybe "null" is a better value in those cases. Very specifically, should our UI give the user the ability to "blank" a text field and send an empty string? I am trying to think of good examples where that would be needed. Thanks for the assist! We're trying to get consistent behavior for "undefined" or "unavailable" strings, and I've suggested to the group that we add a schema annotation indicating that an empty string is acceptable or not. We should only expect to see empty "" strings in cases where the data is user-defined or otherwise settable with no default value. If the data is not available for other reasons (errors, uninitialized data, etc.) then null is the correct response. What we certainly don't want, though, is for implementations to invent data or fill in placeholder (DON'T use "N/A", "[not set]", etc.). "Name" and "Manufacturer" are both properties that should have text available unless an error has occurred (and they are read-only). An example of one that could be an empty (blank) string is "AssetTag". But your point about a user setting a blank string is a good example for us to add to the spec - that is valid data and should be accepted and returned as such - it should not be translated into null. Jeff |
|
