Hi Wendy, On Thu, Oct 10, 2013 at 10:35 AM, Wendy Roome <[email protected]>wrote:
> 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" > > Good point. We will revise the sentence slightly to clarify this. Thanks! Richard > 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
