Flatten to JSON - Allow any data type on the "anything" input

[matt.baker]

Suggestion: Allow any data type to be connected to the "anything" terminal of the flatten to JSON function.

Basically the same as the flatten to XML function.

Also the reverse, unflatten from JSON, may need to be done as well.

[AristosQueue (NI)]

Personally, I agree with this idea. But, professionally, let me explain why it doesn't work and then users can debate it.

From the point of view of the JSON standard, it is meaningless to flatten anything other than a cluster or class to JSON. JSON inherently starts off with a "{" for defining a structure of data. XML allowed us to define our own schema for data and we could define what a lone item would look like. 

With our Flatten To XML, a cluster of a Boolean and a lone Boolean would look like two different strings. How would we handle JSON? Suppose we assume that a lone Boolean should produce a valid JSON string. If we did that, then a lone Boolean would flatten like this

     { "BooleanName"=true }

And that string is exactly the same as the string for a cluster of a single Boolean. Two types producing the same string was an ambiguity that bothered many developers.

We could say that we allow a lone Boolean and the string it produces is a single field entry for JSON. In other words, flattening a Boolean would result in

      "BooleanName"=true

But this string is not a valid JSON string. No JSON parser in the world, including our own Unflatten From JSON, would unflatten it because it is not well-formed. You could use this string if you were building up your own JSON string from parts, and to me, that has value, but I can easily see the confusion of Flatten To JSON and Unflatten From JSON not being parallel. So perhaps we would teach our Unflatten From JSON to accept not-well-formed strings when the type given to Unflatten is a lone Boolean (or other scalar). But that has minimal value since although you could use the Flatten To JSON to build up your own JSON strings, you would need to write or use a full JSON parser to extract the partial field strings to give them to the Unflatten From JSON.

At the end of the day, since JSON is meant for records, the dev team made it support records. They got clusters working. I hope someday they get classes working also. I'm not sure about the other datatypes. What do you think?

[GregSands]

I agree that Flatten to JSON and Unflatten from JSON should only produce/consume valid JSON strings.  So, say that both a Cluster of a single Boolean and a lone Boolean do both flatten to

    { "BooleanName"=true }

Then Unflatten from JSON should accept either a Cluster of a single Boolean or a lone Boolean at its type input and unflatten either without a problem.  I don't see a problem with the ambiguity, as it's just an internal LabVIEW representation in memory, not a property of the data itself.  Any other program that reads the data can make its own choice about how to store it.  It's still just a Boolean value with a name.

Or am I missing something?

Disclaimer: I'd better note that I've never actually used JSON 🙂

[drjdpowell]

In the JSON package I helped create we support lone JSON Values.   The JSON value of a boolean is actually just 'true'; the name of a value is part of a JSON Object.   Lone values are perfectly natural, and I couldn't find any requirement in the JSON spect that all JSON must be objects or arrays.  

If you added to this idea the possiblity of "Build JSON Object" and "Build JSON Array" primatives (which take JSON strings for contained values), then one could dynamically build JSON structures, rather than require a static cluster to define it.  With dynamic creation, JSON of lone values makes sense.  We could, for example, make a true JSON array, containing a mix of datatypes, which I don't think one can do with a cluster.

-- James

[AristosQueue (NI)]

Powell: http://json.org/ is explicit ... valid JSON starts with either a { or a [. You're either working with a record or an array of data.

[Intaris]

Having just read the ECMA document for JSON, if you're processing single values outside of some data structure (in the case of a lone Boolean), it's not JSON. End of.

You can call it JSON, you can label it JSON, but it isn't JSON.

[drjdpowell]

"JSON Value" is the term used in the spec; 'true' is a valid JSON Value (subtype: JSON Text literal).   I couldn't find a place where "JSON" is specifically defined as only being a "JSON Object" or "JSON Array", but I'm not interested in objecting if that's how the term is understood.  

How about JSON Values?  If you want to add support for building/interpreting JSON Objects/Arrays dynamically, then you will have to work with JSON Vales at some level.  If I wanted to build the JSON Object {"a":"hello", "b": 123, "c":null} dynamically (i.e. I can't have a statically-defined cluster), I would need to get those JSON Value substrings somehow.  Having to put every value in a cluster and then strip out the { and } brackets would be clunky.

-- James

[drjdpowell]

Now, I said I wasn't interested in objecting,, but rereading the ECMA spec, it explicitly says that

"Conforming JSON text is a sequence of Unicode code points that strictly conforms to the JSON grammar."

"A JSON text is a sequence of tokens...that conforms to the JSON value grammer."  

"A JSON value can be an object, array, number, string, true, false, or null."  

So true is conforming JSON text.

-- James

PS> This appears to be a quite recent change and/or clarification in the spec, dating only from March 2013 with RFC7158.  Previous versions seemed to say both things at different parts of the document.  (And after spending time Googling that, I find I could have just read Wikipedia )

[Intaris]

Yup, that RFC document clearly states that single values are supported.  I stand corrected.

[AristosQueue (NI)]

That is a change then. Wasn't that way when the JSON prims were created for LV 2013 (development was done in 2012). By March 2013, we were late in beta.

I'll flag the folks who worked on these prims.

[Intaris]

If NI didn't know about this, how many other implementations of JSON don't support lone values?

I don't know which is more valuable, better inter-system compatibility or better adherance to the current norm.....