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
