Showing results for 
Search instead for 
Did you mean: 

Bug in LabVIEW NXG: Unflatten from JSON?

Go to solution

Hello, ran into a weird paradox trying to parse a JSON string from a web request.  I'm trying to specify the LV structure to parse the JSON data into and part of that structure is a cluster, but when I connect that to the Unflatten from JSON, I get a broken wire for datatype mismatch saying the terminal is a cluster of 0 elements.  Of course when I try to pass in a cluster of zero elements I get an error on the cluster constant saying Empty clusters are not supported which makes sense to me as I'm not sure what use that would be.





I'll confess this is my first NXG project so maybe I'm missing something obvious here, but I'm a long time user of LabVIEW and think there is something fundamentally wrong here.  Thanks in advance for any feedback you can offer.

0 Kudos
Message 1 of 10
Accepted by topic author trs1651

My guess (I cannot check) is that timestamps are not allowed in the target data type. If this is correct, I'm excited to see that the error message made it over to NXG.

Message 2 of 10

Excellent suggestion!  You are on the money, in hindsight I can see how a timestamp is harder to parse and needs more information then strings and numerics. Ironically, when I was testing the cluster by itself the first thing I dropped in was a timestamp and that broke it.


Thank you for your help; pity the error description wasn't more explicit, but life goes on.




0 Kudos
Message 3 of 10

JSON itself does not specify a format for timestamps. The only types it officially knows are stringsnumbersbooleannullobjects and arrays.


Different usages of JSON define additional conventions, such as Java(Script) which defines a timestamp as a string based on the ISO8601 standard. But these are in the context of JSON only conventions not real standard specifications and in the case of Java simply caused by the fact that the string form of the Date() object is defined to use that format. Other applications of JSON can use other conventions although the Java(Script) convention has been getting a sort of defacto-standard, except that ISO8601 is a pretty complex standard that allows a lot of different optional formats in an attempt to be compatible with many different implementations.


As such it is not really correct to say that the LabVIEW Flatten To and Unflatten From functions are buggy when not supporting Timestamps.


I would however agree that the LabVIEW help could be a bit more specific about the actually supported data types, and the mappings it performs. There are obvious ones like the JSON numeric type being compatible with any of the LabVIEW integer and floating point types but also not so obvious ones. And while not JSON standard required, a ISO8601 compatible JSON string would not be a luxury either, since LabVIEW has a specific datatype for timestamps.




Rolf Kalbermatter
My Blog
Message 4 of 10

The LabVIEW inbuilt JSON nodes follow a design philosophy of "if in doubt, do nothing" and make the User write custom code to do all datatype mapping between LabVIEW and JSON.  Third-party LabVIEW JSON libraries tend to follow the alternate idea of "do something reasonable (which the User can reject and do differently if they want)".  The later is a much more useful way to go, IMO.  

Message 5 of 10

It depends, both are valid approaches. In terms of support one makes little promises and lets the user deal with anything that falls out of the standard. The other tries to be all and fails in half of the situations too, but leaves many in the wrong believe that there is a standard to be followed.


For someone like NI I think it makes sense to be prudent about adopting non-standard extensions. It will cause support request either way, takes a lot of time to support pseudo standards and increases the documentation requirements.


As a Toolkit developer we are more likely to implement whatever we need for our specific use case and just say for others: "If you like it then use it, if you don't, extend it as you like!" I definitely wouldn't feel very inclined to invest lots of effort into something that I'm not going to need myself.

Rolf Kalbermatter
My Blog
Message 6 of 10

All excellent insights and feedback.  Thank you all for the time you took to read my problem and educate me and others.

0 Kudos
Message 7 of 10

@rolfk wrote:

The other tries to be all and fails in half of the situations too, but leaves many in the wrong believe that there is a standard to be followed.


I think you have your estimates way off there; just using things like the RFC3339 internet standard for Time Stamps and using text for Enumerated Constants and Paths satisfy way more than half of use cases.  I'd say reasonable choices satisfy more than 95+% of situations, not half.

Message 8 of 10

Yes and no! RFC3339 or in extension ISO8601 are nice standards, and thanks to Java(Script) who uses it as their default string form for Date() (and in extensions many more) also quite broad adopted. The DateToString is also not a problem at all, you just pick one of the several recommended forms and are done. The opposite StringToDate is a lot trickier. These two standards allow for a lot of optional features, variants and simplifications in an attempt to embrace a lot of different formats already used. And even then they do not cover all that is present in the world.


I do know your Timestamp library to parse RFC3339 strings and it is a great piece of work. RFC3339 is one of the many possible formats that ISO8601 describes. It is very strictly defined and has only one optional part (the fractional seconds) so parsing that is fairly straightforward. It is however not what Java(Script) uses. Java allows for the much broader ISO8601 standard. And parsing that in a reliable way that can deal with all the many ISO8601 formats is a very significant piece of programming code.


In addition you have all kind of database connectors that all have their own ideas about how timestamps in string form should be represented. If you mainly work with IoT applications, you may indeed cover 90% of the cases with a mildly tolerant RFC3339 style parser, but if you interface to many other systems, things definitely get a lot more complicated as there are at least as many date, time and timestamps formats as there are programming languages and database backends combined together.


There also almost certainly a reason, why JSON does not have an actual Timestamp datatype. An important part of that decision is likely that choosing any form of explicit Timestamp format will for sure alienate a significant part of potential users who may have very strong feelings about one or the other format. After all if you use a specific language which wants to use a specific format and then want to use a standard like JSON that requires a different format, the standard you try to use must be wrong of course! 😀

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 10

The alternative to not making everyone happy should not be to make no-one happy. 


Also, JSON is more widely useful than just interfacing with some other language; a lot of use cases is storage of structured data, such as JSON stored in a database or file, where we are the only ones that need to read back the data.  In these cases, we are free to use any reasonable format for data types.  

0 Kudos
Message 10 of 10