Hi Sebastian, Thanks for taking our discussion to the list :)
I would like to lay emphasis on the fact that "byte" would not have any size ... it is defined as fixed 8-bit element so it should have been: "By (logical) definition a byte is a container of exactly 8 bits without an immediate semantical meaning." I know that in the past I objected the concept of a "byte" in mspec. But let me clarify ... I still do if we would continue to provide a length. But I do (now) see big benefits in a "byte" without size (So more like a "bit" which's length is inherently defined by its name) In java the natural datatype for data is byte, however it's a signed 8-bit value. By using an array of "uint 8" we internally create an array of short values. If we used an mspec type of "byte" each language could decide which is their natural type for these values. In java this would be "byte" as "int 8" ... in Go it would be a "uint 8" same as in C. And to be complete, you should probably also add a: write(byte) read(byte) too. If we say "byte" is always 8 but, I would be in strong favor of this change. If not I would be in strong opposition ;-) Chris -----Ursprüngliche Nachricht----- Von: Sebastian Rühl <[email protected]> Gesendet: Dienstag, 20. April 2021 17:28 An: [email protected] Betreff: Byte representation Hi together, Working on xml serialization (and boxed [more about that in my next summary mail]) I noticed that we are missing support for byte in mspec: By (logical) definition a byte is a container of a bits without a immediate semantical meaning. This could be for example a image, binary data of a compiled program etc. Opposed to a strongly typed definition of uint8 where the meaning would be „a unsigned integer with 8-bit storage“ which could be a sensory data. When using these in an array I would render the first one (byte) as a hex string (or base64/cdata) “<data>AFFE</data>" in xml whereas the latter one (uint 8) I would render as „<data><value>175</value><value>254</value></data>. Same would apply to my boxes where I would render the first one as a pretty hex-dump (with line numbers and string representation) and the latter as pretty value boxes with contained integers. For that we would add a write(byte[]) read(byte[]) to the Writer/Reader and call them from the template whenever we are sure that the data we write is of the definition „byte“. Same could be done to single values and their rendering of course. For the api-user and the data itself on the wire nothing would change, it would just make testing and debugging a whole lot easier. What do you think? Sebastian
