3 ms·

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

by wtbob 11y ago

icebraining 11y ago
Turtle! Well, I can dream..
dec0dedab0de 11y ago
I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.
- prodigal_erik 11y ago
  Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.
  - creshal 11y ago
    > Money is a string. No, it's a float. No, it's an int in micros No, it's a decimal number with attribute-dependant accuracy settings, with at least three different accuracy levels used in the same object used for different purposes. (Just something I came across today at work. Thankfully, my SOAP library handles that automatically…)
  - dec0dedab0de 11y ago
    But no matter what format any bit of data is in, it should still be documented. Then any consumers of the data are going to have to convert it into a format that suits their language and application.
    - wtbob 11y ago
      > But no matter what format any bit of data is in, it should still be documented. That's what types are: enforced documentation.
      - dec0dedab0de 11y ago
        That's what types are: enforced documentation. That's an interesting way to think about it, but I'm not sure it applies here. From the example given about money being a string or a float. A type would just enforce either or, but the consumer of the data would still need to know what it is, and convert it to whatever is necessary for them.
dragonwriter 11y ago
> what if you need a strongly-typed data exchange format I'm not convinced that "strongly-typed" is an attribute that can meaningfully be possessed by a data exchange format. "Strongly-typed" is about allowed actions in processing data, not about the inherently-static format of data exchange or serialization.

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

by wtbob 11y ago

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

icebraining 11y ago

Turtle! Well, I can dream..

dec0dedab0de 11y ago

I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.

prodigal_erik 11y ago
Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.
- creshal 11y ago
  > Money is a string. No, it's a float. No, it's an int in micros No, it's a decimal number with attribute-dependant accuracy settings, with at least three different accuracy levels used in the same object used for different purposes. (Just something I came across today at work. Thankfully, my SOAP library handles that automatically…)
- dec0dedab0de 11y ago
  But no matter what format any bit of data is in, it should still be documented. Then any consumers of the data are going to have to convert it into a format that suits their language and application.
  - wtbob 11y ago
    > But no matter what format any bit of data is in, it should still be documented. That's what types are: enforced documentation.
    - dec0dedab0de 11y ago
      That's what types are: enforced documentation. That's an interesting way to think about it, but I'm not sure it applies here. From the example given about money being a string or a float. A type would just enforce either or, but the consumer of the data would still need to know what it is, and convert it to whatever is necessary for them.

dragonwriter 11y ago

> what if you need a strongly-typed data exchange format I'm not convinced that "strongly-typed" is an attribute that can meaningfully be possessed by a data exchange format. "Strongly-typed" is about allowed actions in processing data, not about the inherently-static format of data exchange or serialization.