4 ms·

> The requirement for the mandatory BOM is unacceptable for most non-Windows users I think the requirement for Unicode is bad in general, whether it uses BOM o

> The requirement for the mandatory BOM is unacceptable for most non-Windows users I think the requirement for Unicode is bad in general, whether it uses BOM or not. > What on earth is "IEEE 64 bit double precision floating point numbers" in the context of textual format? I assume it means that numbers are expected to be IEEE 64-bit floating point numbers represented in the decimal format. > If you have to escape the base64 padding, maybe you should just drop the padding? I agree. > While technically a matter of choice, it uses a lot of unmatching angle brackets and that's just... ugly. I agree with that too. > No canonical representation. I think that a binary format would be better as a canonical representation anyways. However, the lack of indicating the data type would seem to make it difficult to know how to convert it unless you already know the schema. > Maybe you should review tons of other alternatives in this space Just a few days ago, and still working on it today, I had been making something called TER. It might also be worth to look, and I wrote another comment relating to this. Xenon does have a reference type to other nodes, which is something that other similar formats don't have, though.

lifthrasiir 2y ago
> I think the requirement for Unicode is bad in general, whether it uses BOM or not. While there exist legitimate complaints about Unicode, I believe there is no other feasible encoding than UTF-8 for textual formats now. > I assume it means that numbers are expected to be IEEE 64-bit floating point numbers represented in the decimal format. I too believe so (hence the next item), but that just doesn't make sense if you ponder. IEEE 754 doesn't define any textual format while it does have binary decimal formats. The correct wording should have been that numeric scalars follow a specific grammar to be interpreted as an IEEE 754 binary64 number in the data model. > I think that a binary format would be better as a canonical representation anyways. However, the lack of indicating the data type would seem to make it difficult to know how to convert it unless you already know the schema. That's fair. But we have already observed textual formats being... "abused" for the cryptographic purpose (e.g. JWT), so it's not too bad either to have a canonical representation or to explain why there is no canonical representation defined. > Xenon does have a reference type to other nodes, which is something that other similar formats don't have, though. There are several formats that do try to support native graph types, including YAML and Concise [1]. So that is hardly new. I think Concise actually tried very hard to make it fine! But it became quite more complex as a result. [1] https://concise-encoding.org/ https://concise-encoding.org/
- zzo38computer 2y ago
  > I believe there is no other feasible encoding than UTF-8 for textual formats now. I disagree, although I do not believe that this disagreement should have to affect some file formats, since some file formats should not need to care about the character encoding, except perhaps specific details, e.g. that ASCII bytes have ASCII meaning and non-ASCII bytes have non-ASCII meaning (which is true of UTF-8 and of some others). > IEEE 754 doesn't define any textual format while it does have binary decimal formats. The correct wording should have been that numeric scalars follow a specific grammar to be interpreted as an IEEE 754 binary64 number in the data model. OK. Although it seems clearly enough, probably the document should specify explicitly its working anyways, like you mention. > There are several formats that do try to support native graph types, including YAML and Concise [1]. So that is hardly new. I had seen Concise as well, and I have criticisms of that too. I did forget it though as I was writing my message. I did have a idea to add a reference type too (you can see my other comment about TER and ASN.1X), although I would have it to not have the same meaning as the data it references (therefore meaning that it cannot result in cyclic graphs, even if it references itself). I think I should not have remote references, though. Concise encoding seems to have it have the same meaning as the data it references, and I think it is useful to not do this (you could use compression if you want to deal with many of duplicated data).
  - lifthrasiir 2y ago
    > I disagree, although I do not believe that this disagreement should have to affect some file formats, [...] Ah, if you just want to make the UTF-8 requirement less strict for simpler decoders, that can be actually okay. My belief is more about legacy encodings like Shift_JIS. I never seriously tried to fit any graph struture into a serialization format, so I don't yet have a very concrete opinion besides from what was already said. (I'm not even sure Concise had a good approach for that...)
    - GeneThomas 2y ago
      That is hard to believe, the data being serialized may always have a graph structure.

lifthrasiir 2y ago

> I think the requirement for Unicode is bad in general, whether it uses BOM or not. While there exist legitimate complaints about Unicode, I believe there is no other feasible encoding than UTF-8 for textual formats now. > I assume it means that numbers are expected to be IEEE 64-bit floating point numbers represented in the decimal format. I too believe so (hence the next item), but that just doesn't make sense if you ponder. IEEE 754 doesn't define any textual format while it does have binary decimal formats. The correct wording should have been that numeric scalars follow a specific grammar to be interpreted as an IEEE 754 binary64 number in the data model. > I think that a binary format would be better as a canonical representation anyways. However, the lack of indicating the data type would seem to make it difficult to know how to convert it unless you already know the schema. That's fair. But we have already observed textual formats being... "abused" for the cryptographic purpose (e.g. JWT), so it's not too bad either to have a canonical representation or to explain why there is no canonical representation defined. > Xenon does have a reference type to other nodes, which is something that other similar formats don't have, though. There are several formats that do try to support native graph types, including YAML and Concise [1]. So that is hardly new. I think Concise actually tried very hard to make it fine! But it became quite more complex as a result. [1] https://concise-encoding.org/ https://concise-encoding.org/

zzo38computer 2y ago
> I believe there is no other feasible encoding than UTF-8 for textual formats now. I disagree, although I do not believe that this disagreement should have to affect some file formats, since some file formats should not need to care about the character encoding, except perhaps specific details, e.g. that ASCII bytes have ASCII meaning and non-ASCII bytes have non-ASCII meaning (which is true of UTF-8 and of some others). > IEEE 754 doesn't define any textual format while it does have binary decimal formats. The correct wording should have been that numeric scalars follow a specific grammar to be interpreted as an IEEE 754 binary64 number in the data model. OK. Although it seems clearly enough, probably the document should specify explicitly its working anyways, like you mention. > There are several formats that do try to support native graph types, including YAML and Concise [1]. So that is hardly new. I had seen Concise as well, and I have criticisms of that too. I did forget it though as I was writing my message. I did have a idea to add a reference type too (you can see my other comment about TER and ASN.1X), although I would have it to not have the same meaning as the data it references (therefore meaning that it cannot result in cyclic graphs, even if it references itself). I think I should not have remote references, though. Concise encoding seems to have it have the same meaning as the data it references, and I think it is useful to not do this (you could use compression if you want to deal with many of duplicated data).
- lifthrasiir 2y ago
  > I disagree, although I do not believe that this disagreement should have to affect some file formats, [...] Ah, if you just want to make the UTF-8 requirement less strict for simpler decoders, that can be actually okay. My belief is more about legacy encodings like Shift_JIS. I never seriously tried to fit any graph struture into a serialization format, so I don't yet have a very concrete opinion besides from what was already said. (I'm not even sure Concise had a good approach for that...)
  - GeneThomas 2y ago
    That is hard to believe, the data being serialized may always have a graph structure.