SURF and TURF shall remove the # as the delimiter for the integer type and consider a number an integer if it includes no decimal point or $ decimal type delimiter.

SURF and TURF currently use # as a delimiter to indicate that a number is of type urf-Integer. A large motivation for this is that SURF/TURF is supposed to be JSON backwards-compatible (i.e. we can read JSON as SURF/TURF), and JSON (following JavaScript) only has a "number" type, so all numbers in JSON are only "numbers", which are usually stored as floating point. So in JSON 5 and 5.0 would both be of type "number", and in JavaScript would be stored in floating point format.

Java and other language, on the other hand, indicate the distinction e.g. between int and double, so that 5 would be an integer and 5.0 would represent a floating point number. This certainly makes the serialization more concise.

It turns out that the JSON spec is pretty vague about implementation of these "numbers", and in real life it seems that JSON parsers/serializers may actually make a disctinction. There has been discussion (e.g. https://github.com/json-schema-org/json-schema-spec/issues/79 ) about whether things like 5 and 5.0 would both satisfy a JSON Schema requirement of integer. Currently the JSON Schema 6.0 specification says:

The precise treatment of the “integer” type may depend on the implementation of your JSON Schema validator. JavaScript (and thus also JSON) does not have distinct types for integers and floating-point values. Therefore, JSON Schema can not use type alone to distinguish between integers and non-integers. The JSON Schema specification recommends, but does not require, that validators use the mathematical value to determine whether a number is an integer, and not the type alone. Therefore, there is some disagreement between validators on this point. For example, a JavaScript-based validator may accept 1.0 as an integer, whereas the Python-based jsonschema does not.

Additionally it seems that Json.NET (I presume come C# library) is making some sort of distinction between floating point and integer in its JSON serialization, judging from https://stackoverflow.com/q/21153381/421049 .

So even if the pure JSON world it would seem that it's not prohibited to use/abuse the JSON format to make a distinction between integers and floating point numbers. In our case, we don't even want to go round-trip—we just want to be able to read a JSON document. Rather than requiring a # delimiter, SURF/TURF can just consider integers anything without a decimal point (and without the decimal $ delimiter), similar to what Java does. This still seems JSON compliant as far as reading a JSON document, and even seems consistent with some JSON implementations.