5 ms·

People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge ca

People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.

bananas 13y ago
And it doesn't support the multitude of accurate numeric types that XML does implicitly. XML data is not just "strings", it's a sequence of characters. The deserializer determines what sort of type it is based on either the structure or the language's capabilities. With XML, you can define these policies. With JSON you're stuck with JavaScript being the semantic standard and type definitions which ties you to floats or numbers inside strings. The latter is criminal. Edit: clarification as HN won't let me reply any more.
- icebraining 13y ago
  How so? XML by itself only supports strings; any other data types have to be derived from a schema. But you can do the same with any other format that supports strings, including JSON.
  - bhaak 13y ago
    But in the design of XML this was already acknowledged. That's why there is the distinction between well-formed and valid XML documents. Only with valid XML documents there is a schema attached that will describe these nodes with the type attribute. And because it is extendable, these types can be anything but they will be automatically validated by the parser. JSON OTOH doesn't have this extensibility. There are a couple of predefined types but if you need to go beyond them (and this happens all the time because JSON doesn't even define a date type!) any interpretation is up to the parsing program and this can vary tremendously (again, look at the handling of dates and for example the questions on stackoverflow about them).
    - icebraining 13y ago
      Only with valid XML documents there is a schema attached that will describe these nodes with the type attribute. http://json-schema.org/ http://json-schema.org/ What's the issue?
      - bhaak 13y ago
        It's still a draft (and if I may nit-pick, an expired draft). It only has "complete structural validation". Which means it doesn't feature custom types. Although it adds a workaround for the date issue by adding a handful of supported sub-types (http://json-schema.org/latest/json-schema-validation.html#anchor104 http://json-schema.org/latest/json-schema-validation.html#an...) It is far from what validation XML Schemas offer.
Patient0 13y ago
JSON is explicitly not designed to be hand-editable. Hence, for example, no comments. It's just meant to be human readable. If you want human editable "json", use Yaml: http://www.yaml.org/ http://www.yaml.org/ (it's a superset of Json that adds comments, linking etc.)
- oneeyedpigeon 13y ago
  How is YAML a superset of JSON? Do you mean 'conceptually'?
  - icebraining 13y ago
    No, it is a superset. Every JSON document is a valid YAML document.
  - _delirium 13y ago
    It's technically true because YAML includes an alternate "inline style" that lets you write objects in JSON syntax. Therefore any JSON object is a valid YAML object as well. But, not an idiomatically written YAML object, since writing YAML using only inline style is unusual.
  - turnip1979 13y ago
    To be specific, JSON syntax is a subset of YAML version 1.2. However, I hate YAML with a passion. It is worse than XML in my books. I can usually read JSON fine. I can also read XML in many cases. For the life of me, I just can't read YAML. It has something to do with "-", line indentation and different ways of writing lists. Of course, someone will say YAML is technically better ...
    - buster 13y ago
      Different for me, i would prefer YAML over XML or JSON
      - turnip1979 13y ago
mattfenwick 13y ago
> because it has more syntax edge cases Could you provide examples? I'm trying to collect more examples for a JSON validator -- http://mattfenwick.github.io/Miscue-js/ http://mattfenwick.github.io/Miscue-js/ (built during a big project using JSON, after I started running into some issues that I couldn't check using other validators) I'd love to hear more examples if you're willing to share.

People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.

bananas 13y ago

And it doesn't support the multitude of accurate numeric types that XML does implicitly. XML data is not just "strings", it's a sequence of characters. The deserializer determines what sort of type it is based on either the structure or the language's capabilities. With XML, you can define these policies. With JSON you're stuck with JavaScript being the semantic standard and type definitions which ties you to floats or numbers inside strings. The latter is criminal. Edit: clarification as HN won't let me reply any more.

icebraining 13y ago
How so? XML by itself only supports strings; any other data types have to be derived from a schema. But you can do the same with any other format that supports strings, including JSON.
- bhaak 13y ago
  But in the design of XML this was already acknowledged. That's why there is the distinction between well-formed and valid XML documents. Only with valid XML documents there is a schema attached that will describe these nodes with the type attribute. And because it is extendable, these types can be anything but they will be automatically validated by the parser. JSON OTOH doesn't have this extensibility. There are a couple of predefined types but if you need to go beyond them (and this happens all the time because JSON doesn't even define a date type!) any interpretation is up to the parsing program and this can vary tremendously (again, look at the handling of dates and for example the questions on stackoverflow about them).
  - icebraining 13y ago
    Only with valid XML documents there is a schema attached that will describe these nodes with the type attribute. http://json-schema.org/ http://json-schema.org/ What's the issue?
    - bhaak 13y ago
      It's still a draft (and if I may nit-pick, an expired draft). It only has "complete structural validation". Which means it doesn't feature custom types. Although it adds a workaround for the date issue by adding a handful of supported sub-types (http://json-schema.org/latest/json-schema-validation.html#anchor104 http://json-schema.org/latest/json-schema-validation.html#an...) It is far from what validation XML Schemas offer.

Patient0 13y ago

JSON is explicitly not designed to be hand-editable. Hence, for example, no comments. It's just meant to be human readable. If you want human editable "json", use Yaml: http://www.yaml.org/ http://www.yaml.org/ (it's a superset of Json that adds comments, linking etc.)

oneeyedpigeon 13y ago
How is YAML a superset of JSON? Do you mean 'conceptually'?
- icebraining 13y ago
  No, it is a superset. Every JSON document is a valid YAML document.
- _delirium 13y ago
  It's technically true because YAML includes an alternate "inline style" that lets you write objects in JSON syntax. Therefore any JSON object is a valid YAML object as well. But, not an idiomatically written YAML object, since writing YAML using only inline style is unusual.
- turnip1979 13y ago
  To be specific, JSON syntax is a subset of YAML version 1.2. However, I hate YAML with a passion. It is worse than XML in my books. I can usually read JSON fine. I can also read XML in many cases. For the life of me, I just can't read YAML. It has something to do with "-", line indentation and different ways of writing lists. Of course, someone will say YAML is technically better ...
  - buster 13y ago
    Different for me, i would prefer YAML over XML or JSON
    - turnip1979 13y ago

mattfenwick 13y ago

> because it has more syntax edge cases Could you provide examples? I'm trying to collect more examples for a JSON validator -- http://mattfenwick.github.io/Miscue-js/ http://mattfenwick.github.io/Miscue-js/ (built during a big project using JSON, after I started running into some issues that I couldn't check using other validators) I'd love to hear more examples if you're willing to share.