Interesting thought. It appears a json parser, from what I used, will more likely give only the line number. For example, try http://jsonlint.com/
It typically gives a line number, and then some message on what is expected. Hence, line # might be more likely available? Richard On Monday, October 14, 2013, Richard Alimi wrote: > Actually, how about just the character position in the input stream? That > would avoid any complexities of different line-ending styles. It could > simply be named "position". > > > On Sun, Oct 13, 2013 at 9:14 PM, Y. Richard Yang > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> 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]<javascript:_e({}, 'cvml', '[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]<javascript:_e({}, 'cvml', '[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] <javascript:_e({}, 'cvml', >>>> '[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] <javascript:_e({}, 'cvml', '[email protected]');> >>>>> https://www.ietf.org/mailman/listinfo/alto >>>>> >>>> >>>> >>>> _______________________________________________ >>>> alto mailing list >>>> [email protected] <javascript:_e({}, 'cvml', '[email protected]');> >>>> https://www.ietf.org/mailman/listinfo/alto >>>> >>>> >>> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
