Hi Wendy, On Wed, Oct 9, 2013 at 3:13 PM, Wendy Roome <[email protected]>wrote:
> 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. > > Yes. > 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". > > An example used in the discussions will say: "field" : "cost-type.cost-mode" "value" : "foo" The reason for the "." subfield structure is to avoid future cases of ambiguous subfield name, for example, two fields with different names, but both have a subfield with the same name. We do not have any two subfields with the same name in the current design, but future extensions might and hence cause problem for the general structure. For the "." notation to be valid, we need to avoid "." in field names. What do you think? > 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. > Yes. > 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. > > This will lead to your next email: invalid value or invalid type. I will reply in the next email. > I think that covers all bases. > > Indeed. Richard > - 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
