> Things like the maximum size of strings or integers are implementation limits. These should be kept separate from the language definition per se. At least wi

> Things like the maximum size of strings or integers are implementation limits. These should be kept separate from the language definition per se. At least with integers, I think protobuf's ability to specify 32-bit and 64-bit integers has been quite helpful. > There are de facto different levels of portability of JSON data. A highly portable piece of JSON data confines itself not to exceeding certain limits, like ranges of integers. We could call that "strictly conforming". Yeah... and that's how you get yourself in to problems. Life is simpler with one standard that either works or doesn't. Easily the most annoying thing with protocol buffers is using unsigned integers because of Java's signed integer foolishness. Yes, you can argue that's a reason to have the "strictly conforming" concept, but I'd argue quite the opposite. > Limits are different from other discrepancies among implementations because it is very clear what the behavior should be if the extended limit is supported. If an implementation handles integers beyond the JSON specified range, there is an overwhelming expectation that those representations keep denoting integers. Hmm... I don't think that is clear at all. In fact, it isn't clear to me when I have to worry about floating point rounding potentially kicking in. > This is different from situations where you hit some unspecified or undefined behavior, where an implementation could conceivably do anything, including numerous choices that meet the definition of a useful extension. In practice, there seems to be little difference. While there might be some idealized behaviour that is expected, there appears to be plenty of wiggle room for a variety of behaviours for these "not strictly conforming" cases.