It is one of those things that happens when you don’t have a working group beat on a spec for six months. With an IETF process, I bet JSON would disallow duplicate keys and have comments. It might even have a datetime data type or at least recommend ISO8601 in a string.
I was on the Atom working group. That is still a solid spec. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Feb 6, 2020, at 8:56 AM, Doug Turnbull > <dturnb...@opensourceconnections.com> wrote: > > Well that is interesting, I did not know that! Thanks Walter... > > https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object > > I gave it a go in Python (what I'm using) to see what would happen, indeed > it gives some odd behavior > > In [4]: jsonStr = ' {"test": 1, "test": 2} ' > > > In [5]: json.loads(jsonStr) > > Out[5]: {'test': 2} > > On Thu, Feb 6, 2020 at 11:49 AM Walter Underwood <wun...@wunderwood.org> > wrote: > >> Repeated keys are quite legal in JSON, but many libraries don’t support >> that. >> >> It does look like that data layout could be redesigned to be more portable. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >>> On Feb 6, 2020, at 8:38 AM, Doug Turnbull < >> dturnb...@opensourceconnections.com> wrote: >>> >>> Thanks for the tip, >>> >>> The issue is json.nl produces non-standard json with duplicate keys. >> Solr >>> generates the following, which json lint fails given multiple keys >>> >>> { >>> "positions": { >>> "position": 155, >>> "position": 844, >>> "position": 1726 >>> } >>> } >>> >>> On Thu, Feb 6, 2020 at 11:36 AM Munendra S N <sn.munendr...@gmail.com> >>> wrote: >>> >>>>> >>>>> Notice the lists, within lists, within lists. Where the keys are >> adjacent >>>>> items in the list. Is there a reason this isn't a JSON dictionary? >>>>> >>>> I think this is because of NamedList. Have you tried using json.nl=map >> as >>>> a >>>> query parameter for this case? >>>> >>>> Regards, >>>> Munendra S N >>>> >>>> >>>> >>>> On Thu, Feb 6, 2020 at 10:01 PM Doug Turnbull < >>>> dturnb...@opensourceconnections.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I was curious if anyone had any tips on parsing the JSON response of >> the >>>>> term vectors component? Or anyway to force it to be more standard JSON? >>>> It >>>>> appears to be very heavily nested and idiosyncratic JSON, such as >> below. >>>>> >>>>> Notice the lists, within lists, within lists. Where the keys are >> adjacent >>>>> items in the list. Is there a reason this isn't a JSON dictionary? >>>> Instead >>>>> you have to build a stateful list parser that just seems prone to >>>> errors... >>>>> >>>>> Any thoughts or ideas are very welcome, I probably just need to do >>>>> something rather simple here... >>>>> >>>>> "termVectors": [ >>>>> "D100000", [ >>>>> "uniqueKey", "D100000", >>>>> "body", [ >>>>> "1", [ >>>>> "positions", [ >>>>> "position", 92, >>>>> "position", 113 >>>>> ] >>>>> ], >>>>> "10", [ ... >>>>> >>>>> -- >>>>> *Doug Turnbull **| CTO* | OpenSource Connections >>>>> <http://opensourceconnections.com>, LLC | 240.476.9983 >>>>> Author: Relevant Search <http://manning.com/turnbull> >>>>> This e-mail and all contents, including attachments, is considered to >> be >>>>> Company Confidential unless explicitly stated otherwise, regardless >>>>> of whether attachments are marked as such. >>>>> >>>> >>> >>> >>> -- >>> *Doug Turnbull **| CTO* | OpenSource Connections >>> <http://opensourceconnections.com>, LLC | 240.476.9983 >>> Author: Relevant Search <http://manning.com/turnbull> >>> This e-mail and all contents, including attachments, is considered to be >>> Company Confidential unless explicitly stated otherwise, regardless >>> of whether attachments are marked as such. >> >> > > -- > *Doug Turnbull **| CTO* | OpenSource Connections > <http://opensourceconnections.com>, LLC | 240.476.9983 > Author: Relevant Search <http://manning.com/turnbull> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such.
