Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

["Manger, James" <[e-mail]>]

>> JDDF offers "type":"uint8" but very common languages, such as Java, don't have an unsigned 8-bit type. So code generation might use a short (16-bit signed integer) to handle the [0, 255] range. That seems to put the code in a very similar situation to using a long when the JDDF says "int54". In both cases the native type can hold values that the schema doesn't allow, requiring extra parse/stringify functions if you really want to enforce the schema's rules.

>This isn't quite right. Yes -- Java only has "byte", but by convention you can store both signed and unsigned 8-bit numbers in these bytes.
>Protobufs does this:

That is certainly 1 reasonable choice for a code generator.

>Furthermore, the Java standard library has methods that explicitly let you do the conversion of a Java byte-as-uint8 into a Java int or long:
>
>https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedInt-byte-
>https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedLong-byte-
>
>If bytes-as-uint8 weren't conventional, then why does java.lang.Byte have methods that enable such a style?

Did you notice the "Since 1.8" annotation on those methods? This support for byte-as-uint8 was only added in Java 8.
And even these additions don't make Java's standard sorting or printing work for uint8. Generated code cannot merely using byte for uint8; it also needs to add code so a byte-as-uint8 is serialized differently to a normal byte-as-int8.

Short-as-uint8 has different properties: sorting & serializing works as "normal", but it takes twice as much memory.

If I saw uint8 in JDDF, I'd almost certainly want control over whether it became a byte or short in my Java code, depending on the situation.


>> * "type": "intString" ...
>> * "type": "uintB64u" ...
>> * "type": "bytesB64" ...
>> * "type": "bytesB64u" ...

> I think I'm opposed to this suggestion. Adding support for arbitrary binary data is going to be challenging. I think I prefer that we just stick to {"type":"string"}, and then folks can write their own extensions to JDDF to achieve their specific needs. After awhile, the community may perhaps converge on common extensions, or patterns may arise and we can update the JDDF spec.
>
>Anything we add to the spec now would have to be supported by all implementations. So I'd prefer we give out a minimal spec to the world, and see where the real world takes it. If we try to solve all problems right away, we may make it too hard for implementations to crop up, ultimately solving no problems for anyone.

But if the spec is too minimal it isn't worthwhile.

--
James Manger