Good point! I was relying on the fact that our field names are unique for now, but there's no guarantee it will stay that way. So yes, set "field" to the full path, and ban "." from field names.
But the path should go all the way to the root dictionary. Eg, for a bad mode, "field": "meta.cost-type.cost-mode" "value": "foo" or for a bad IP address in an endpoint cost request, "field": "endpoints.srcs" "value": "ipv4:a.b.c" - Wendy From: "Y. Richard Yang" <[email protected]> Date: Wed, October 9, 2013 16:56 To: Wendy Roome <[email protected]> Cc: IETF ALTO <[email protected]> Subject: Re: [alto] New error format in draft 20 > 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?
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
