11 ms·

Gotta love JSON. It's XML without the tools so you get to reinvent everything to pad your resume. XML -> JSON WSDL -> JSON schema XPath -> JSON pat

by arkh 9y ago

Gotta love JSON. It's XML without the tools so you get to reinvent everything to pad your resume. XML -> JSON WSDL -> JSON schema XPath -> JSON path XSLT -> JSON template? SOAP -> Swagger and friends One or two decades from now there will be too many tools and things to learn about JSON so another generation will reinvent a new "perfect format for everything". And a new cycle will have started.

dualogy 9y ago
The fact that all these use-cases pop up again tells us that they're real. I was dubious the first-time-around =) Well in green-field projects it's certainly advisable to minimize what is "done in"/"expressed in"/achieved-via the current-interchange-format de-jour --- but in messy real-world projects such rabbit holes can unavoidably open. And then you sooner or later end up thinking, as I did back then, "XML is kinda sucky but XPath and XSLT make it actually pretty nifty & fun to deal with and somewhat escape its own very suckiness".
DLA 9y ago
Yeah, makes total sense to traffic in XML then convert back and forth to/from JSON for web layer. Gotta love XML.
rtpg 9y ago
I kinda get this criticism, but this is also a bit like lamenting that we write the same libraries for different programming languages. I mean... yeah. Some ideas are good across protocols. That's why they're copied. On a merits-based thing, if you're just looking at XML, it has a lot of things going against it .If someone sends me something "in JSON", I can have a good guess what it'll look like. Not as much luck with XML. XML punishes you for using attributes (because you can't place composed types within them), but the awkward alternative is placing attributes in sub-elements. I have a list of products with prices. I store the price as a quantity attribute on a <product>. I decide later on to store currencies for all my "money" objects. Do I now double the amount of attributes? It's all super awkward, and JSON's mental model is more straightforward, even if you end up with approximations.
- jimktrains2 9y ago
  Why is it super awkward and how does JSON solve this problem any better?
  - simonw 9y ago
    When you’re designing an XML schema, answering the question “should this be an attribute or a nested elember” is awkward because there is rarely an obvious correct answer. With JSON, the answer is always a name/value pair.
    - dragonwriter 9y ago
      That's a problem with XML Schema, not XML. A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.
  - tchaffee 9y ago
    JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus <employees> <employee> <name>John Crichton</name> <gender>male</gender> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees>
    - skocznymroczny 9y ago
      Or <employees> <employee name="John Crichton" gender="male" /> <employee name="Aeryn Sun" gender=female" /> </employees>
      - 9y ago
zwerdlds 9y ago
Oi... XML wasn't the first format to be used for data interchange and encounter these problems either. At least JSON is designed for data interchange in the first place... Too many tools? Are you not selective about what tools you use anyways? The field is decades old. Do you program in assembly? Fortran?
anon1253 9y ago
Yep. I agree. Although maybe XML schema (https://www.w3.org/XML/Schema https://www.w3.org/XML/Schema) -> JSON Schema. And then there's also XQuery, DTDs, namespaces, entities,… which are also in need of reinventing I guess.
- nikolay 9y ago
  JMESPath [0], started by Amazon and used by Microsoft in Azure, is something that tries to accomplish some of the XQuery goals in a simpler way. [0]: http://jmespath.org/ http://jmespath.org/
eranation 9y ago
And it goes on... XML comments -> JSON: nah -> YAML XML CDATA (multiline raw strings) -> JSON: nope -> YAML
mtrn 9y ago
> It's XML without the tools. XML can be really powerful, but a lot of real users actually don't know how to use XML. Many just use it as an enterprise version of JSON in which case I am happy to just work with JSON, plain and simply. Also JSON processing can be easily parallelized, because it is easy to express in a newline delimited format (http://ndjson.org/ http://ndjson.org/).
coding123 9y ago
Seems like JSON should have already been overturned. It hasn't and I don't think it will. My personal belief was that XML was kicked out because it allowed this: <books:book> stuff here <xsd:schema .../> <xslt:transform .../> </books:book> And so you couldn't just READ that, you had to have a parser that fully understood EVERYTHING going on there. JSON won't get namespaces, and therefore it will remain good. We will continue to replace what namespaces did for XML, but will keep that data in its own metadata document, outside the main document. I think that's why JSON won't be replaced as quickly as XML. Also XML didn't kill XML, webservices (ws-* standards) killed XML.
earthboundkid 9y ago
I tweeted in Apr. 2016, "You know how you feel when you have to parse XML from 2005? That’s how we’ll all feel about JSON in 2025. It’s not bad, just bloat-y." XML, JSON, gRPC… These are all technologies to solve a problem. The trouble is people confuse technology with a business solution and they start applying it as though by "having a REST API" you've done something. You can't say you've accomplished anything until you actually demonstrably deliver value!
nikolay 9y ago
Exactly my observation! JSON became famous as a revolt against the complex XML ecosystem, but it reinvented a square wheel. YAML is no different - its specification and feature set is quite overwhelming. There's so much quality work done with XML that all this effort is a complete waste. From streaming parsers to the XQuery, and great projects such as VTD-XML [0], it's sad to see us spinning wheels. I see TOML as another wasteful attempt at something that's only slightly better but requiring a new toolchain and an ecosystem. [0]: https://vtd-xml.sourceforge.io/ https://vtd-xml.sourceforge.io/
nikolay 9y ago
I'm not sure why we didn't at least adopt JSON5 [0] or Hjson [1]! [0]: http://json5.org/ http://json5.org/ [1]: http://hjson.org/ http://hjson.org/
bryanrasmussen 9y ago
WSDL -> JSON schema is the wrong mapping, obviously should be XML Schema (WSDL is an awful web services things - so is there some combination of a router and JSON schema spec somewhere out there?)
- arkh 9y ago
  > WSDL is an awful web services things The thing is, when creating webservices you like creating tests. With WSDL you have tools which given a WSDL will generate a test-suite for you and some mocked services. With JSON you'll have to hack-up something using Swagger.

by arkh 9y ago

dualogy 9y ago

The fact that all these use-cases pop up again tells us that they're real. I was dubious the first-time-around =) Well in green-field projects it's certainly advisable to minimize what is "done in"/"expressed in"/achieved-via the current-interchange-format de-jour --- but in messy real-world projects such rabbit holes can unavoidably open. And then you sooner or later end up thinking, as I did back then, "XML is kinda sucky but XPath and XSLT make it actually pretty nifty & fun to deal with and somewhat escape its own very suckiness".

DLA 9y ago

Yeah, makes total sense to traffic in XML then convert back and forth to/from JSON for web layer. Gotta love XML.

rtpg 9y ago

I kinda get this criticism, but this is also a bit like lamenting that we write the same libraries for different programming languages. I mean... yeah. Some ideas are good across protocols. That's why they're copied. On a merits-based thing, if you're just looking at XML, it has a lot of things going against it .If someone sends me something "in JSON", I can have a good guess what it'll look like. Not as much luck with XML. XML punishes you for using attributes (because you can't place composed types within them), but the awkward alternative is placing attributes in sub-elements. I have a list of products with prices. I store the price as a quantity attribute on a <product>. I decide later on to store currencies for all my "money" objects. Do I now double the amount of attributes? It's all super awkward, and JSON's mental model is more straightforward, even if you end up with approximations.

jimktrains2 9y ago
Why is it super awkward and how does JSON solve this problem any better?
- simonw 9y ago
  When you’re designing an XML schema, answering the question “should this be an attribute or a nested elember” is awkward because there is rarely an obvious correct answer. With JSON, the answer is always a name/value pair.
  - dragonwriter 9y ago
    That's a problem with XML Schema, not XML. A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.
- tchaffee 9y ago
  JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus <employees> <employee> <name>John Crichton</name> <gender>male</gender> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees>
  - skocznymroczny 9y ago
    Or <employees> <employee name="John Crichton" gender="male" /> <employee name="Aeryn Sun" gender=female" /> </employees>
    - 9y ago

zwerdlds 9y ago

Oi... XML wasn't the first format to be used for data interchange and encounter these problems either. At least JSON is designed for data interchange in the first place... Too many tools? Are you not selective about what tools you use anyways? The field is decades old. Do you program in assembly? Fortran?

anon1253 9y ago

Yep. I agree. Although maybe XML schema (https://www.w3.org/XML/Schema https://www.w3.org/XML/Schema) -> JSON Schema. And then there's also XQuery, DTDs, namespaces, entities,… which are also in need of reinventing I guess.

nikolay 9y ago
JMESPath [0], started by Amazon and used by Microsoft in Azure, is something that tries to accomplish some of the XQuery goals in a simpler way. [0]: http://jmespath.org/ http://jmespath.org/

eranation 9y ago

And it goes on... XML comments -> JSON: nah -> YAML XML CDATA (multiline raw strings) -> JSON: nope -> YAML

mtrn 9y ago

> It's XML without the tools. XML can be really powerful, but a lot of real users actually don't know how to use XML. Many just use it as an enterprise version of JSON in which case I am happy to just work with JSON, plain and simply. Also JSON processing can be easily parallelized, because it is easy to express in a newline delimited format (http://ndjson.org/ http://ndjson.org/).

coding123 9y ago

Seems like JSON should have already been overturned. It hasn't and I don't think it will. My personal belief was that XML was kicked out because it allowed this: <books:book> stuff here <xsd:schema .../> <xslt:transform .../> </books:book> And so you couldn't just READ that, you had to have a parser that fully understood EVERYTHING going on there. JSON won't get namespaces, and therefore it will remain good. We will continue to replace what namespaces did for XML, but will keep that data in its own metadata document, outside the main document. I think that's why JSON won't be replaced as quickly as XML. Also XML didn't kill XML, webservices (ws-* standards) killed XML.

earthboundkid 9y ago

I tweeted in Apr. 2016, "You know how you feel when you have to parse XML from 2005? That’s how we’ll all feel about JSON in 2025. It’s not bad, just bloat-y." XML, JSON, gRPC… These are all technologies to solve a problem. The trouble is people confuse technology with a business solution and they start applying it as though by "having a REST API" you've done something. You can't say you've accomplished anything until you actually demonstrably deliver value!

nikolay 9y ago

Exactly my observation! JSON became famous as a revolt against the complex XML ecosystem, but it reinvented a square wheel. YAML is no different - its specification and feature set is quite overwhelming. There's so much quality work done with XML that all this effort is a complete waste. From streaming parsers to the XQuery, and great projects such as VTD-XML [0], it's sad to see us spinning wheels. I see TOML as another wasteful attempt at something that's only slightly better but requiring a new toolchain and an ecosystem. [0]: https://vtd-xml.sourceforge.io/ https://vtd-xml.sourceforge.io/

nikolay 9y ago

I'm not sure why we didn't at least adopt JSON5 [0] or Hjson [1]! [0]: http://json5.org/ http://json5.org/ [1]: http://hjson.org/ http://hjson.org/

bryanrasmussen 9y ago

WSDL -> JSON schema is the wrong mapping, obviously should be XML Schema (WSDL is an awful web services things - so is there some combination of a router and JSON schema spec somewhere out there?)

arkh 9y ago
> WSDL is an awful web services things The thing is, when creating webservices you like creating tests. With WSDL you have tools which given a WSDL will generate a test-suite for you and some mocked services. With JSON you'll have to hack-up something using Swagger.