"JSON Type.vi" incorrectly evaluates string within braces

[Former user]

Evaluation of JSON type is incorrect when a string within curly brackets is used. For example, a UUID4 generated string that contains braces will report as "JSON Object" instead of "Not a JSON Value".

{fab8b6c7-04b6-4ef3-b31a-d204d22ce6ad} is not a valid JSON object

[James Powell]

“JSON Type” only infers the type from the lead character, rather than doing ( a time-consuming) validation that you have entered actual JSON. If you want the validation (and thus get “Not a JSON Value”) use “Next JSON Value”.

Perhaps I should mention “Next JSON Value” as an alternative in the documentation for “JSON Type”.

[Francois Normandin]

It would work if it starts with braces indeed, but “Next JSON Value” does not systematically work either.

For example, the following string asserts as a Number:

160E3E123-0000-048E

While this one asserts as Not a JSON String:

160E3F123-0000-048E

The bug is actually in the “Advance past Number.vi” (called by both “JSON Type” and “Next JSON Value” where multiple negative, positive or exponential signs are resulting as “Number”. In the second string example, the presence of any hexadecimal char “ABCDF” will correctly assert to Not a JSON string, but for all strings with a mix of digits, dot, +/- and “eE”, it will incorrectly assert as a number.

Ideally, the algorithm should verify if “+/-” chars are either leading characters, following an exponential character or preceding the imaginary part of a number. The algorithm should also ensure that the exponential part can only be in the count of “0 or 1” for real numbers and “0, 1 or 2” for imaginary numbers.

I’ll find a workaround, but to comply with JSON-RPC 2.0, the “id” field is required to support both a string or a numeric. Therefore, it is important that the assertion can be made to allow building the JSON packet correctly. Whether I use “JSON Type.vi” or “Next JSON Value.vi”, the result is the same, with slightly different failure surface area.

‌

(EDIT: Since there are no standard ways in JSON spec to represent imaginary numbers, a validator that works for real numbers would be sufficient).

‌

[James Powell]

Technically, I don’t make a specification in JSONtext as to handling non-valid JSON entered into the “JSON” inputs. This is partly because I have a design goal of high speed, and extensive validation can require a loss of speed. However, I looks like I can rewrite “Advance past Number.vi” such that it rejects obvious non-numbers without compromising speed.

We can also consider more explicit API validation functions (which can do extra validation steps)

[James Powell]

Added (currently failing) cases to “Test Case Error or No Error” unit test.

[James Powell]

BTW, you will never entirely get your design to work, since a User entry like ‘160E3’ can be intended either as a number or as a string. To be 100% reliable, you need to explicitly know the type, rather than inferring it from the LabVIEW string.

[James Powell]

Note: Permissive read of numbers not to JSON spec that I am keeping, as they are valid human-writable numbers:
.1
1.
01
+1

[James Powell]

Resolving. Now doesn't accept obvious non-numbers. Note that this is still not an input-validation function.