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.

[drjdpowell]

Quite a lot, I'll bet.  Though it is unlikely to matter, given that JSON between apps is going to usually involve multiple peices of date, thus requiring a data structure, object or array.  Lone values are useful in building up or chopping up those strucures internally.  But you're right, there could be some apps out there that wont accept '123.456', or '"Hello"', but instead need it to be '[123.456]' or '["Hello"]'.  

[AristosQueue (NI)]

I talked to the developers. Our implementation conforms to RFC-4627. They did not know about this change, but they confirmed that our implementation was obsoleted by RFCs 7158 and 7159. A CAR has been filed. Normally I would close an idea that has been moved to CAR, but I'm going to leave this idea open since the CAR may get closed as a feature request to support the new JSON standard. Regardless, I've already been told this is a very low priority change because, as drjdpowell notes, the vast majority of real use cases for JSON involves serialization of structures, and since we have no other facilities for building up the structures, adding the lone values has minimal benefit.

[JLS]

Flattening both a cluster containing a boolean and a boolean to something like { "BooleanName"=true } is reasonable.  I don't think this is ambiguous; it is simply a surjective function, of which there are many in LabVIEW.  Said differently, there is nothing wrong with a function mapping two elements to the same thing.  Consider the function f(x) = x^2 where x is an integer.

In our case here, flattening this way would be convenient and enable functionality with less syntax (not having to build the cluster of the single element).  I don't see a downside.  Having an option to produce the json object { "BooleanName"=true } vs just the json value "BooleanName"=true for some custom json contructing would be better / more flexible yet.

[Hooovahh]

Okay I'd like to add to this idea.  Is there a reason that the JSON Unflatten/Flatten doesn't support the path data type, or the timestamp data type?

I'm working with Web Services and it can send data as a timestamp as JSON, but I can't use the unflatten to get my data back because timestamps aren't supported.  I can get the data as a string but then need to do the conversion, and make sure I do it right.

I don't use the path data type with the Web Service but I also thought it was odd it wasn't possible to use that on JSON but figured there might be an actual reason like trying to adhear to a standard.

[AristosQueue (NI)]

The answer (from the JSON team) is that Timestamp and Path are not well defined JSON types. Did you intend for that to be a platform specific path or a platform independent path? Did you intend for the timestamp to be the cluster of two doubles or changed to some human readable string format or preserved as the giant cluster of fields? They decided to only support types that are actually transmittable as JSON and leave it to you to convert your data into such supported types before calling the JSON primitives. Essentially, you need to build up an application-specific wrapper around the JSON primitives for the types you're trying to communicate.

[Hooovahh]

That's a fair enough answer and figured it was the case.  I guess my particular issue is probably more with the Web Services team, since they accept taking a timestamp as a write, but they convert it to a string to be sent over JSON.  But as far as I can tell the format conversion isn't documented, so going from string to timestamp is never defined. I used scan from string and it seems to work, but if the JSON supported timestamp data types, then the Web Services would have and there wouldn't be this string conversion.  To be safe I could wrap my own timestamp to string, and string to timestamp wrappers.

[Tomi_Maila]

JKI JSON doesn't have this limitation and allows anything to be wired to the JSON serialization input.

jki.net/tools#json

[drjdpowell]

Why does this idea still have only 14 kudos?

[PBD_ctrl]

How has this not been fixed yet?  We have had to write a tool set to deal with LabVIEW's poor JSON handling.  This being one of the sore spots.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Flatten-to-JSON-Allow-any-data-type-on-the-quot-anythi...