Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From XML to JSON to CBOR

cborbook.com

Post reply on HN
Print view View original

81–90 of 106 posts

Re: From XML to JSON to CBOR

#81

Post by eadmund »

flowerthoughts wrote: post #79
eadmund wrote: post #75

Earlier quoted context omitted.

Would you rather write a parser for this: SEQUENCE { SEQUENCE { OBJECT IDENTIFIER '1 2 840 113549 1 1 1' NULL } BIT STRING 0 unused bits, encapsulates { SEQUENCE { INTEGER 00 EB 11 E7 B4 46 2E 09 BB 3F 90 7E 25 98 BA 2F C4 F5 41 92 5D AB BF D8 FF 0B 8E 74 C3 F1 5E 14 9E 7F B6 14 06 55 18 4D E4 2F 6D DB CD EA 14 2D 8B F8 3D E9 5E 07 78 1F 98 98 83 24 E2 94 DC DB 39 2F 82 89 01 45 07 8C 5C 03 79 BB 74 34 FF AC 04 AD 15…

The ASN.1 notation wasn't meant for parsing. And then people started writing parsing generators for it, so they adapted. However, you're abusing a text format for human reading and pretending it's a serialization format. The BER/PER are binary formats and great where binary formats are needed. You also have XER (XML) and JER (JSON) if you want text. You can create an s-expr encoding if you want. Separate ASN.1--the d…

> However, you're abusing a text format for human reading and pretending it's a serialization format.

They should be the same, in order to facilitate human debugging. And we were discussing ASN.1, not its serialisations. Frankly, I thought that it was fairer to compare the S-expression to ASN.1, because both are human-readable, rather than to an opaque blob like:

    MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm
Sure, that blob is far more space-efficient, but it’s also completely opaque without tooling. Think how many XPKI errors over the years have been due to folks being unable to know at a glance what certificates and keys actually say.

Re: From XML to JSON to CBOR

#82

Post by sevensor »

dragonwriter wrote: post #76
sevensor wrote: post #66

Earlier quoted context omitted.

That’s my point, though! I’ve run into popular JSON libraries that will emit all of those! 9007199254740993 is problematic because it’s not representable as a 64 bit float. Python’s JSON library is happy to write it, even though you need an int to represent it, and JSON doesn’t have ints. Edit: I didn’t see my thought all the way through here. Syntax typing invites this kind of nonconformity, because different progra…

> 9007199254740993 is problematic because it’s not representable as a 64 bit float. Python’s JSON library is happy to write it, even though you need an int to represent it JSON numbers have unlimited range in terms of the format standard, but implementations are explicitly permitted to set limits on the range and precision they generate and handle, and users are warned that: [...] Since software that implements IEEE…

RFC 8259 is a good read and I wish more people would make the effort. I really don’t mean to bash JSON here. It was a great idea and it continues to be a great idea, especially if you are using javascript. However, the passage you quote illustrates the same shortcoming I’m complaining about: RFC 8259 basically says “valid primitive types in json are the valid primitive types in your programming language,” but this results in implementations like Python’s json library emitting invalid tokens like bare NaN, which can cause decoders to choke.

I think what JSON gets right is that it gives us a universal way of expressing structure: arrays and objects map onto basic notions of sequence and association that are useful in many contexts and can be represented in a variety of ways by programming languages. My ideal data interchange format would stop there and let the user decide what to do with the value text after the structure has been decoded.

Re: From XML to JSON to CBOR

#83

Post by johnisgood »

ghishadow wrote: post #77
johnisgood wrote: post #45

Erlang / Elixir has amazing support for ASN.1! I love it. https://www.erlang.org/doc/apps/asn1/asn1_getting_started.ht... https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do... ( https://www2.erlang.org/documentation/doc-14/lib/asn1-5.1/do... ) I am using ASN.1 to communicate between a client (Java / Kotlin) and server (Erlang / Elixir), but unfortunately Java / Kotlin has somewhat of a shitty support for AS…

Erlang and ASN.1 are from telecom, so it makes sense they have best support

I agree, but that does not mean that other languages should have shitty support. It does not mean that it should not either, of course.

Re: From XML to JSON to CBOR

#84

Post by conartist6 »

aidenn0 wrote: post #56
sevensor wrote: post #54

Earlier quoted context omitted.

My complaint about JSON is that it’s not minimal enough. The receiver always has to validate anyway, so what has syntax typing done for us? Different implementations of JSON disagree about what constitutes a valid value. For instance, is {“x”: NaN} valid JSON? How about 9007199254740993? Or -.053? If so, will that text round trip through your JSON library without loss of precision? Is that desirable if it does? Basic…

NaN is not a valid value in JSON. Neither are 0123 or .123 (there must always be at least one digit before the decimal marker, but extraneous leading zeroes are disallowed). JSON was originally parsed in javascript with eval() which allowed many things that aren't JSON through, but that doesn't make JSON more complex.

Yeah I would emit NaN and just hope the receiver handles it.

What's the point of lying about the data?

The format offers you no data type that would not be an outright lie when applied to this data, so you may as well not lie and break the format

Re: From XML to JSON to CBOR

#85

Post by aidenn0 »

sevensor wrote: post #66
aidenn0 wrote: post #56

Earlier quoted context omitted.

NaN is not a valid value in JSON. Neither are 0123 or .123 (there must always be at least one digit before the decimal marker, but extraneous leading zeroes are disallowed). JSON was originally parsed in javascript with eval() which allowed many things that aren't JSON through, but that doesn't make JSON more complex.

That’s my point, though! I’ve run into popular JSON libraries that will emit all of those! 9007199254740993 is problematic because it’s not representable as a 64 bit float. Python’s JSON library is happy to write it, even though you need an int to represent it, and JSON doesn’t have ints. Edit: I didn’t see my thought all the way through here. Syntax typing invites this kind of nonconformity, because different progra…

Before your edit, I was going to object to your premise because it seems like a format could get worse just by more implementations being made.

After your edit, I see that it's rather that syntax-typed formats are prone to this form of implementation divergence.

I don't think this is limited to syntax-typed formats though. For example, TNetstrings[1] have type tags, but "#" is an integer. The specification requires that integers fit into 63 bits (since the reference encoder will refuse to encode a python long), but implementations in C tend to allow 64 bits and in other languages allow bignums. It does explicitly allow "nan", "inf", and "-inf" FWIW.

1: https://tnetstrings.info/

Re: From XML to JSON to CBOR

#87

Post by sevensor »

conartist6 wrote: post #84
aidenn0 wrote: post #56

Earlier quoted context omitted.

NaN is not a valid value in JSON. Neither are 0123 or .123 (there must always be at least one digit before the decimal marker, but extraneous leading zeroes are disallowed). JSON was originally parsed in javascript with eval() which allowed many things that aren't JSON through, but that doesn't make JSON more complex.

Yeah I would emit NaN and just hope the receiver handles it. What's the point of lying about the data? The format offers you no data type that would not be an outright lie when applied to this data, so you may as well not lie and break the format

Your other option is to comply with the spec, emit a string, and expect the receiver to deal with that at validation time rather than parse time.

Re: From XML to JSON to CBOR

#88

Post by sevensor »

aidenn0 wrote: post #85
sevensor wrote: post #66

Earlier quoted context omitted.

That’s my point, though! I’ve run into popular JSON libraries that will emit all of those! 9007199254740993 is problematic because it’s not representable as a 64 bit float. Python’s JSON library is happy to write it, even though you need an int to represent it, and JSON doesn’t have ints. Edit: I didn’t see my thought all the way through here. Syntax typing invites this kind of nonconformity, because different progra…

Before your edit, I was going to object to your premise because it seems like a format could get worse just by more implementations being made. After your edit, I see that it's rather that syntax-typed formats are prone to this form of implementation divergence. I don't think this is limited to syntax-typed formats though. For example, TNetstrings[1] have type tags, but "#" is an integer. The specification requires t…

Agreed; I think there’s a problem with self-describing data as a concept. It just begs for implementation defined weirdness.

Re: From XML to JSON to CBOR

#89

Post by aidenn0 »

aidenn0 wrote: post #55

I admit I got nerd-sniped here, but the table for floats[1] suggests that 10000.0 be represented as a float32. However, isn't it exactly representable as 0x70e2 in float16[2]? There are only 10 significant bits to the mantissa (including the implicit 1), while float16 has 11 so there's even an extra bit to spare. 1: https://cborbook.com/part_1/practical_introduction_to_cbor.h... 2: i.e. 1.220703125×2¹³

Looks like it's a typo; they state:

> 0x47c35000 encodes 10000.0

But by my math that encodes 100000.0 (note the extra zero).

Re: From XML to JSON to CBOR

#90

Post by elcritch »

_the_inflator wrote: post #40

Love or hate JSON, the beauty and utility stem from the fact that you have only the fundamental datatypes as a requirement, and that's it. Structured data that, by nesting, pleases the human eye, reduced to the max in a key-value fashion, pure minimalism. And while you have to write type converters all the time for datetime, BLOBs etc., these converters are the real reasons why JSON is so useful: every OS or framewor…

CBOR (and MsgPack) still embraces that simplicity. It provides the same types of key-value, lists, and basic values.

However the types are more precise allowing you to differentiate between int32’s or int64’s or between strings or bytes.

Essentially you can replace json with it and gain performance, less ambiguity but with the same flexibility. You do need a step to print CBOR in human readable form, but it has a standardized human readable form similar to a typed json.

Post reply on HN