Actually that needs more explanation than just what I wrote before. How about this:
If the server includes the "value" field, it must also specify "field" with the name of the field. The "value" field is always a JSON string. If the invalid value is a string, "value" is that string. If the invalid value is a number, "value" must be the invalid number as a string. If the invalid value is a subfield, the server must set "field" to the subfield name and "value" to the invalid subfield value, converting it to a string if needed. For example, if the "cost-mode" subfield of the "cost-type" field is invalid mode "foo", the server should set "value" to "foo", and "field" to "cost-mode", not "cost-type". If an element of a JSON array has an invalid value, the server sets "value" to the value of the invalid element, as a string, and "field" to the name of the array. An array element of the wrong type (e.g., a number in what is supposed to be an array of strings) is an invalid value error, not an invalid type error. The server sets "value" to the string version of the incorrect element, and "field" to the name of the array. I think that covers all bases. - Wendy Roome From: "Y. Richard Yang" <[email protected]> Date: Wed, October 9, 2013 14:13 To: Wendy Roome <[email protected]> Cc: IETF ALTO <[email protected]> Subject: Re: [alto] New error format in draft 20 On Wed, Oct 9, 2013 at 1:42 PM, Wendy Roome <[email protected]> wrote: > A few comments and questions on the new error reporting. > > * For code = E_INVALID_FIELD_VALUE, what is the JSON type of the "value" > field"? Seems like it should be the type of the field with the bad value. > But that means "value" has a polymorphic type. That's not impossible to > handle, but so far we're avoided that. That also implies that if the > server returns "value", the server MUST set "field" the name of the > offending field, so the client knows what type to expect for "value". > Good comment! The thought was that "value" is a JSONString of the relevant wrong value specified in the request, as your good example below suggested. You are definitely right that if "value" is specified, "field" should be specified as well.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
