Looking at very core of the issue with byte type representation (at least in XML suits) I believe it was affected by mapping to/from Java. Jackson has its own ways handling such payloads. We really should map suites according to mspec and keep values in tests according to their "canonical" representation. Without pinning it to any particular language. As far I remember we currently map byte[] payloads to hex strings, but sometimes such representation is helpful also for digits. Earlier we had base64 for byte arrays which did make it pretty hard to debug tests. If we could map single bytes to hex that also would be great cause turning it into digit by Jackson is not very helpful.
Best, Łukasz On 20.04.2021 18:00, Christofer Dutz wrote: > 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 >
