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]> 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]> 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
