Subject: Re: [Json] What’s up with 4627bis?

From: Cyril J <[email-masked]>
Date: Fri, 10 Jan 2014 22:54:49 -0800 (PST)

Hi all,

As a newcomer to this list's threads that I'm still trying to grok from their beginning, I hope I didn't miss the following topic possibly already mentioned.

If I didn't, I might have something of interest for Tim, wrt. I-JSON.

As both a user and implementor of a JSON parser (and "deserializer") I couldn't miss to notice the rather ad-hoc, implementation-dependent, solution to a seemingly frequent, recurring problem, in a statically typed deserialization use case.

Indeed, it isn't difficult to find many examples of applications written in statically typed languages which, also, find themselves in an interesting situation with the following facets:

1) they need to consume some incoming JSON
2) they are (for whatever, various legacy reasons) firmly relying on the "natural" static type system of their platform
3) yet, (for whatever, other various legacy reasons) they cannot quite afford to step back and settle once and for all, as they should, for any of the schema languages for JSON - assuming they'd have one meeting their needs (or for other non-schema-based, cleaner refactoring)
4) but still, they need to "deserialize" that JSON into fresh instances of object oriented (or not OO) *strongly typed* data structures - by that I mean of course: going beyond just a plain vanilla hash map "string to object"

Of course, it didn't take long for JSON librairies implementors to come up with the classic in-band-signalling workaround:

... { "$type": "Acme.Business.Model.CompanyDomain.Affiliate", "CompanyId": 123, ... }

"You wanna know the type of that thing? Well, there you go, here it is, buddy..."

(to which some apparently were like... "Hey! Where is the type of that thing?!" - see links at the bottom)

Talking about the .NET realm alone I can already count at least two competing conventions already, with the question regularly coming on the table for JSON users, and found in three of the most popular implementations [1] - i.e., choosing "$type" vs. "__type" for the key holding the type information hint.

For obvious reasons of ease of implementation, however, regardless of the type info hint key convention in use, they all happen, at least, to agree on requiring the same relative position for that ad-hoc key in the JSON object being deserialized - if it needs to be present, they expect to encounter it immediately after parsing the start of JSON object, marked "{".

(it's also for efficiency, as implementations usually simply create a fresh instance of the deserialization target type right after encountering and parsing that key name)

So, I was just wondering if per chance I-JSON could find the above use case legitimate enough to recommend to implementations some BCP about it.

Thoughts?

Allow? Disallow? Name if allowed? Position? Etc.

'Hoping it's not just completely off-topic,

Cheers,

Cyril Jandia

[1] http://stackoverflow.com/questions/9490345/json-net-change-type-field-to-another-name

(JSON.NET uses "$type" for that, following a habit I believe was introduced by Microsoft, as early as [2])

[2] http://msdn.microsoft.com/en-us/library/system.web.script.serialization.javascriptserializer(v=vs.90).aspx

While ServiceStack (and probably others) uses "__type":

[3] http://stackoverflow.com/questions/12731214/remove-concrete-type-information-in-json-response-using-jsonserializer