I am fine with adding two optional fields. Regarding an optional "character" field, the suggested semantics is the character position at the line. To avoid ambiguity, how about name them "line-number" and "character-number" so that their JSONNumber type is not surprising?
Richard On Sat, Oct 12, 2013 at 1:43 PM, Richard Alimi <[email protected]> wrote: > We used to have a 'reason' field, but it was suggested in the the > apps-area review that it be removed because of the concern over > internationalization. Given that it's WGLC I would prefer not to revisit > that. > > I don't have a problem with adding optional line and character fields, > given that they can be conveyed as integers. I don't think it should be > required, since not all parsers may provide that information. > > Rich > > > On Fri, Oct 11, 2013 at 5:54 PM, Y. Richard Yang <[email protected]> wrote: > >> Hi Wendy, >> >> Interesting suggestion. I assume that the fields will be optional, right? >> A consideration is that the syntax errors typically are caught by a JSON >> parser. I know that you know quite a few parsers. Will the existing parsers >> give such information (e.g., line, character)? >> >> To others: if you have used multiple parsers, your experience can be >> quite helpful here. >> >> Thanks! >> >> Richard >> >> >> On Thu, Oct 10, 2013 at 12:50 PM, Wendy Roome <[email protected] >> > wrote: >> >>> As current;y defined, E_SYNTAX gives no indication as to where the error >>> is or what was wrong. So how about adding the following additional fields >>> for E_SYNTAX: >>> >>> "line" Optional line number (first line is 1) >>> "character" Optional character in line (first character is 1) >>> "reason" Optional error message, which may or may not include line and >>> character. >>> >>> This raises the question of what language to use for "reason". At the >>> risk >>> of coming across as an English chauvinist, I suggest that it be in >>> English. After all, the RFC is in English, and the field names are >>> English. So it's pretty unlikely that server and client programmers won't >>> understand enough English to deal with a simple error message. And I >>> don't >>> see a client library displaying that message to the end user; instead the >>> lib would log it for analysis by the developers. >>> >>> And if a server isn't able to give an English error message, use "line" >>> and "character". >>> >>> - Wendy Roome >>> >>> >>> _______________________________________________ >>> alto mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/alto >>> >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
