5 ms·

I mean, you can use JSON Schema as well to have similar functionality to XML Schema.

by Deukhoofd 3y ago

znpy 3y ago
That's exactly the point being made: json is becoming xml.
- tgv 3y ago
  The point also feels like passive-aggressively ignoring the reason why people use JSON and not XML.
  - Devasta 3y ago
    Honestly for a lot of people they use JSON because thats what they have always used; XMLs heyday was like 15 years ago, you could be a very senior engineer now and have never touched XML.
  - w23j 3y ago
    Can you name some of these reasons? Or give me link? Honest question!
    - alpaca128 3y ago
      One reason would be massively reduced syntax overhead and better readability. I've seen plenty of XML files where XML syntax makes up more than 50% of the file's content, and trying to read the actual content is tedious. Now JSON isn't ideal either - technically you could get rid of all commas, colons, and the quotes around most keys - but I sure prefer `{"foo": "some \"stuff\""}` over something like `<foo><![CDATA[some <stuff>]]></foo>`
      - w23j 3y ago
        I agree, I would prefer JSON (or YAML) for example for configuration files. That is for stuff that humans actually read. I was thinking about using JSON/XML as a data exchange format between computers, because the context of this discussion has revolved about things like JSON/XML-Schema, JSON/XPath and SOAP/OpenAPI. There is a large trend to replace XML with JSON as data format for inter machine communication, and it is confusing to me.
    - tgv 3y ago
      XML is too unwieldy for human consumption. Editing it is error-prone, and those schema-directed editors are even worse, because everything requires clicking and clicking and clicking. For machine-to-machine communication, it's very well suited, but most data is simple enough, and the XML libraries I've used tended to be --let's say-- over-engineered, while there are no hoops to jump through when you want to parse JSON. And one thing I always disliked about XML was the CDATA section: it makes the message even harder to read, and it's not like you're going to use that binary data unparsed/unchecked. XML just tried to formalize data transfer and description prematurely, which made it rigid and not even sufficiently powerful. I must say that XSLT and XPath were great additions, though.
    - eviks 3y ago
      It's unreadable
w23j 3y ago
I haven't looked at JSON Schema in detail so please correct me if I am wrong, but I had the impression that the JSON Schema specification is still largely unfinished and evolving. That means you need to know which version the tool you use supports. And when I was looking for JSON Schema validators for Java all I found were projects on GitHub, which often were abandoned and referred the user to another GitHub project which was also abandoned. There does not seem to be support from an established project or vendor. Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.). What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling? (And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)
- pydry 3y ago
  All schema languages are a bit like that. You can almost always add another layer on top of the validation and screw down the validation a bit harder. The strictest validation will only be achievable using a turing complete language. OpenAPI is probably used a bit more than json schema, but it's contextually limited to APIs (which, to be fair, is mostly what JSON is used for).
  - w23j 3y ago
    I probably phrased my question poorly. Why would I use a tool which is not or poorly maintained for a probably already outdated version of a specs, when I can use something else, that has been used for years by countless companies in productions? The advantages must be huge. And I don't know what they are. OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.

I mean, you can use JSON Schema as well to have similar functionality to XML Schema.

znpy 3y ago

That's exactly the point being made: json is becoming xml.

tgv 3y ago
The point also feels like passive-aggressively ignoring the reason why people use JSON and not XML.
- Devasta 3y ago
  Honestly for a lot of people they use JSON because thats what they have always used; XMLs heyday was like 15 years ago, you could be a very senior engineer now and have never touched XML.
- w23j 3y ago
  Can you name some of these reasons? Or give me link? Honest question!
  - alpaca128 3y ago
    One reason would be massively reduced syntax overhead and better readability. I've seen plenty of XML files where XML syntax makes up more than 50% of the file's content, and trying to read the actual content is tedious. Now JSON isn't ideal either - technically you could get rid of all commas, colons, and the quotes around most keys - but I sure prefer `{"foo": "some \"stuff\""}` over something like `<foo><![CDATA[some <stuff>]]></foo>`
    - w23j 3y ago
      I agree, I would prefer JSON (or YAML) for example for configuration files. That is for stuff that humans actually read. I was thinking about using JSON/XML as a data exchange format between computers, because the context of this discussion has revolved about things like JSON/XML-Schema, JSON/XPath and SOAP/OpenAPI. There is a large trend to replace XML with JSON as data format for inter machine communication, and it is confusing to me.
  - tgv 3y ago
    XML is too unwieldy for human consumption. Editing it is error-prone, and those schema-directed editors are even worse, because everything requires clicking and clicking and clicking. For machine-to-machine communication, it's very well suited, but most data is simple enough, and the XML libraries I've used tended to be --let's say-- over-engineered, while there are no hoops to jump through when you want to parse JSON. And one thing I always disliked about XML was the CDATA section: it makes the message even harder to read, and it's not like you're going to use that binary data unparsed/unchecked. XML just tried to formalize data transfer and description prematurely, which made it rigid and not even sufficiently powerful. I must say that XSLT and XPath were great additions, though.
  - eviks 3y ago
    It's unreadable

w23j 3y ago

I haven't looked at JSON Schema in detail so please correct me if I am wrong, but I had the impression that the JSON Schema specification is still largely unfinished and evolving. That means you need to know which version the tool you use supports. And when I was looking for JSON Schema validators for Java all I found were projects on GitHub, which often were abandoned and referred the user to another GitHub project which was also abandoned. There does not seem to be support from an established project or vendor. Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.). What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling? (And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)

pydry 3y ago
All schema languages are a bit like that. You can almost always add another layer on top of the validation and screw down the validation a bit harder. The strictest validation will only be achievable using a turing complete language. OpenAPI is probably used a bit more than json schema, but it's contextually limited to APIs (which, to be fair, is mostly what JSON is used for).
- w23j 3y ago
  I probably phrased my question poorly. Why would I use a tool which is not or poorly maintained for a probably already outdated version of a specs, when I can use something else, that has been used for years by countless companies in productions? The advantages must be huge. And I don't know what they are. OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.