4 ms·

I like the idea of schemas but only when they're built into the message (which is probably not a good way of conveying my meaning). Essentially JSON gives you

I like the idea of schemas but only when they're built into the message (which is probably not a good way of conveying my meaning). Essentially JSON gives you numbers, strings and nulls so when accepted on the other side it obviously knows what's a number, what's a string, etc. Honestly if JSON could be expanded to essentially be the same but add additional types along with bolting on new types (extensible) then I think it would be perfect for the job. At least in my opinion.

stdbrouw 12y ago
You're talking about typing, not really about schemas. With JSON, you can know whether a value is a number as opposed to a string, but you can't know whether it's supposed to be a number.
- ochoa 12y ago
  Dumb question: why doesn't the value being a number tell us it's suppose to be a number?
  - michaelmior 12y ago
    Assuming the service is operating correctly, I think the more accurate statement is that it doesn't tell you the value will always be a number. That is, perhaps a field has multiple valid types. Maybe that field won't exist all the time or similar data may be available in a different struture. Without a schema, these questions can't really be answered.
  - kalleboo 12y ago
    Example: Postal codes. Say you're transferring an address in JSON and you have a postal code field. In the UK, postal codes are strings (e.g. "BS42BG"), easy enough. Now, someone enters a US postal code (90505). Should we transfer it as a number, or a string?
    - elros 12y ago
      Definitely as a string. Numbers aren't things that have digits. Numbers are things you do math with.
      - kalleboo 12y ago
        OK, that's logical. So where do we specify this without a schema? What happens if a client sends a number instead of a string to the server? Should it accept it and convert it, or return an error?
- deleted 12y ago
  [deleted]
haberman 12y ago
Schemas built into the message certainly have the benefit of being self-describing. But they also have downsides: - encoding the schema along with the message makes encodings like this less efficient. - without an ahead-of-time schema, you don't have any canonical list for all the fields that can exist and their types. Instead this gets specified in ad-hoc ways in documentation. For example, like this: https://developers.facebook.com/docs/graph-api/reference/v2.0/group/ https://developers.facebook.com/docs/graph-api/reference/v2.... That URL describes a schema for groups. The schema exists, it's just not machine-readable! That means you can't use it for IDE auto-completion, you can't reflect over it programmatically, and you can't use it to make encoding/decoding more CPU/memory efficient. It's so close to being useful for these purposes, why not just take that final step and put it in a machine-readable format?
- alexatkeplar 12y ago
  It's really frustrating how in 2014 almost everybody is still writing API definitions which are only human-readable. Two worthy exceptions: - https://github.com/balanced/balanced-api https://github.com/balanced/balanced-api - https://helloreverb.com/developers/swagger https://helloreverb.com/developers/swagger You can have self-describing messages without having to embed the schema in the instance. Instead you embed a reference to the schema in the message. We came up with an approach to this called self-describing JSONs: http://snowplowanalytics.com/blog/2014/05/15/introducing-self-describing-jsons/ http://snowplowanalytics.com/blog/2014/05/15/introducing-sel... The Avro community do something similar.
  - judk 12y ago
    > Instead you embed a reference to the schema in the message AKA XML DTD

stdbrouw 12y ago

You're talking about typing, not really about schemas. With JSON, you can know whether a value is a number as opposed to a string, but you can't know whether it's supposed to be a number.

ochoa 12y ago
Dumb question: why doesn't the value being a number tell us it's suppose to be a number?
- michaelmior 12y ago
  Assuming the service is operating correctly, I think the more accurate statement is that it doesn't tell you the value will always be a number. That is, perhaps a field has multiple valid types. Maybe that field won't exist all the time or similar data may be available in a different struture. Without a schema, these questions can't really be answered.
- kalleboo 12y ago
  Example: Postal codes. Say you're transferring an address in JSON and you have a postal code field. In the UK, postal codes are strings (e.g. "BS42BG"), easy enough. Now, someone enters a US postal code (90505). Should we transfer it as a number, or a string?
  - elros 12y ago
    Definitely as a string. Numbers aren't things that have digits. Numbers are things you do math with.
    - kalleboo 12y ago
      OK, that's logical. So where do we specify this without a schema? What happens if a client sends a number instead of a string to the server? Should it accept it and convert it, or return an error?
deleted 12y ago
[deleted]

haberman 12y ago

Schemas built into the message certainly have the benefit of being self-describing. But they also have downsides: - encoding the schema along with the message makes encodings like this less efficient. - without an ahead-of-time schema, you don't have any canonical list for all the fields that can exist and their types. Instead this gets specified in ad-hoc ways in documentation. For example, like this: https://developers.facebook.com/docs/graph-api/reference/v2.0/group/ https://developers.facebook.com/docs/graph-api/reference/v2.... That URL describes a schema for groups. The schema exists, it's just not machine-readable! That means you can't use it for IDE auto-completion, you can't reflect over it programmatically, and you can't use it to make encoding/decoding more CPU/memory efficient. It's so close to being useful for these purposes, why not just take that final step and put it in a machine-readable format?

alexatkeplar 12y ago
It's really frustrating how in 2014 almost everybody is still writing API definitions which are only human-readable. Two worthy exceptions: - https://github.com/balanced/balanced-api https://github.com/balanced/balanced-api - https://helloreverb.com/developers/swagger https://helloreverb.com/developers/swagger You can have self-describing messages without having to embed the schema in the instance. Instead you embed a reference to the schema in the message. We came up with an approach to this called self-describing JSONs: http://snowplowanalytics.com/blog/2014/05/15/introducing-self-describing-jsons/ http://snowplowanalytics.com/blog/2014/05/15/introducing-sel... The Avro community do something similar.
- judk 12y ago
  > Instead you embed a reference to the schema in the message AKA XML DTD