7 ms·

I find the whole JSON vs XML debate pretty tedious. Just use what ever is best for the job. If you just need a light-weight API that is only ever going to be R

by JonoW 15y ago

I find the whole JSON vs XML debate pretty tedious. Just use what ever is best for the job. If you just need a light-weight API that is only ever going to be REST orientated, then use JSON. If you're building a very complex Enterprise SOA system, use XML as the associated technologies (xsd, xsl, soap+ws-* etc) will be very useful. If people are starting to invent XML like technologies for JSON (namespaces or schemas etc), then why not just use XML? It's already been done and works well.

xyzzyz 15y ago
If you're building a very complex Enterprise SOA system, use XML as the associated technologies (xsd, xsl, soap+ws- etc) will be very useful.* What precisely are they useful for? Honest question, I have not had a job yet, let alone the "enterprise" one.
- goalieca 15y ago
  Well, same question here. I've interned on an enterprisey web service before but I couldn't imagine what sort of mental gymnastics are required to justify xml being used the way it is.
- MatthewPhillips 15y ago
  XSD is used to validate a document conforms to some standard. Say you run a legal document firm and you receive Form Foo from 100 different clients, XSD will handle validating that they are conforming to the standard for you. XSL is an umbrella for a few things, most interesting is XPath which is a super fast query language for xml documents. SOAP is just worthless. WSDL is nice though, it compiles a web service API to source code so you get a nice layer of abstraction around what you're writing to.
  - mgkimsal 15y ago
    I've never seen WSDL used without SOAP. Not saying it couldn't happen, just not seen it. Do you ever use WSDL without SOAP? Or SOAP without WSDL?
  - sk5t 15y ago
    Haven't you overlooked the fact that WSDL-based proxies and SOAP-over-HTTP are almost always used in concert?
- JonoW 15y ago
  Some examples: XSD (Schema) - lets you describe the format of your XML document. Useful if you need to tell other parties about your format. You can use XSDs to programmatically validate that a given XML document is "correct" as per your schema. IDEs can use XSDs file to do intellisense on XML files as you type. You can also include documentation within XSDs and have an external tool auto-generate documentation (e.g. in HTML) to describe your Schema in a more user-friendly way. XSL - These are XML docs that define how to transform 1 XML format into another. Can use combine this with XSDs to ensure that the result of the transformation is valid. SOAP + WS-* - WS-* is a set of standards on top of SOAP (which just defines a web-service interface). E.g. WS-Security can define that your web-service must encrypt the contents of the message, WS-Addressing makes SOAP less dependant on HTTP.
  - r00fus 15y ago
    To summarize, if you own the code for both endpoints of data exchange (and will always do so), then JSON wins by sheer terseness and schema. If you do not, then you will guaranteed run into schema differences of common objects (ie, SAP "Customer" <> Oracle "Customer <> Salesforce "Customer" etc etc). XML w/ XSL/XSD wins here.
- gaius 15y ago
  Well I am an enterprise developer and I can tell you exactly what XML is for: selling you expensive middleware. It costs a fortune and it starts with an X, it must be eXtremely good right!? I avoid it like the plague as much as I can... But everyone gets bogged down in SOAP WSDL nonsense. Before XML we had CORBA, and before that EDI, and before that ASN.1... Just reinventing the wheel and each time a little worse.
  - 6ren 15y ago
    It's unfortunate you're downvoted, as there's truth amid the cynicism. It's true that consultants get paid more for hard-to-use software, and I get the impression even some open-source projects play this card... But, usually there's some progress in successive technologies - from your position, can you see any? I'm interested in understanding the real problems here. For example (AFAIK) XML webservices tend to be less tightly coupled than CORBA's IDLs (though you can tight-couple in any language): - XML using its own format specification language (DTD; XML Schema) helps keep the external data format independent from the application's internal data structures (until some bright spark realizes they can avoid duplication! by deriving one from the other... thus re-coupling them. Because of this, SOAP is CORBA all over again). CORBA's IDL produced an interface for every object. This is fine for methods of the top-level object (that represents the main actions of the application/service), but when applied to objects that form the internal data structures (the nested object tree/graph that is received/sent as an argument/return value), it forces the external format to have the same structure as the internal data structure, thus tightly-coupling them. [And, CORBA tried to do "distributed objects", which just didn't work very well - though it sounds like a good idea.] REST seems to be making a big difference. It explicitly uses "representational state", meaning that the external format is independent of the sender and receiver's internal representation. By defining the format independently of an end-point, it seems you escape tight-coupling. In practice, devs will often derive internal object definitions from the external format - but then they do the loose-coupling themselves, internally, and so tight-coupling is still avoid. [It's seeming to me that deriving internal-->external is bad; but external-->internal is OK.] In a way, I think this progression can be seen as realizing the concept of information hiding in greater and greater depth as time goes on. Does that seem right? What do you think? Can you point me to any references that address these issues (esp about tight-coupling between internal/external representations)? Many thanks for any help!
- uriel 15y ago
  They are good for creating jobs and selling expensive enterprisey software packages to PHBs.
pnathan 15y ago
JonoW, I'd like to see a definitive case study for the Enterprise SOA system's use of XML. It may be my lack of experience in the area, but I have never found big-iron solutions to be a good solution to anything I have dealt with, usually they seem to be more trouble than the actual problem.
deno 15y ago
> If you just need a light-weight API that is only ever going to be REST orientated, then use JSON. I disagree with that assertion. There is nothing open Web can possibly gain by adopting JSON for its APIs. In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML. Last but not least, what does make XML ill-suited for any ‘lightweight’ APIs? Atom fits nicely with REST and is quite lean. There's hardly anything JSON can offer, to my knowledge, that could be any lighter or more robust.
- pavel_lishin 15y ago
  Not so heterogeneous if the only data exchange format available is XML.
  - deno 15y ago
    Well that's the point, isn't it? XML unifies various independent ecosystems. At the very least, if defines such essential things like data and time representation formats, whereas JSON doesn't even attempt to do that. But then XML goes further and provides you with a contract. Now anyone can write their independent implementation and test it (validate it) to that contract. This is what Web was about in the first place. You can use any technology imaginable, any language imaginable, but in the end you are delivering to common format, HTML+JS. Now that this is insufficient, the natural evolution would be XML and REST. JSON, however, is a liability. I believe it is, in fact, the next IE6!
- EdiX 15y ago
  > In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML. XML is not any more or less typed, extendible or validatable than JSON. They are both serialisation formats that make you put data into their own structure, a tree with attributes for XML and lists and dictionaries for JSON. Exactly two types exist in XML: tree and text. And exactly six types exist in JSON: list, dictionary, string, number, boolean and null. What XML has that JSON doesn't is a solution for automating validation called XML Schema.
stesch 15y ago
Just use what ever is best for the job. If it would be so easy. A few years ago I had a boss who wanted to use XML everywhere. No matter what. The whole company only had Java+XML as a selling point.

by JonoW 15y ago

xyzzyz 15y ago

If you're building a very complex Enterprise SOA system, use XML as the associated technologies (xsd, xsl, soap+ws- etc) will be very useful.* What precisely are they useful for? Honest question, I have not had a job yet, let alone the "enterprise" one.

goalieca 15y ago
Well, same question here. I've interned on an enterprisey web service before but I couldn't imagine what sort of mental gymnastics are required to justify xml being used the way it is.
MatthewPhillips 15y ago
XSD is used to validate a document conforms to some standard. Say you run a legal document firm and you receive Form Foo from 100 different clients, XSD will handle validating that they are conforming to the standard for you. XSL is an umbrella for a few things, most interesting is XPath which is a super fast query language for xml documents. SOAP is just worthless. WSDL is nice though, it compiles a web service API to source code so you get a nice layer of abstraction around what you're writing to.
- mgkimsal 15y ago
  I've never seen WSDL used without SOAP. Not saying it couldn't happen, just not seen it. Do you ever use WSDL without SOAP? Or SOAP without WSDL?
- sk5t 15y ago
  Haven't you overlooked the fact that WSDL-based proxies and SOAP-over-HTTP are almost always used in concert?
JonoW 15y ago
Some examples: XSD (Schema) - lets you describe the format of your XML document. Useful if you need to tell other parties about your format. You can use XSDs to programmatically validate that a given XML document is "correct" as per your schema. IDEs can use XSDs file to do intellisense on XML files as you type. You can also include documentation within XSDs and have an external tool auto-generate documentation (e.g. in HTML) to describe your Schema in a more user-friendly way. XSL - These are XML docs that define how to transform 1 XML format into another. Can use combine this with XSDs to ensure that the result of the transformation is valid. SOAP + WS-* - WS-* is a set of standards on top of SOAP (which just defines a web-service interface). E.g. WS-Security can define that your web-service must encrypt the contents of the message, WS-Addressing makes SOAP less dependant on HTTP.
- r00fus 15y ago
  To summarize, if you own the code for both endpoints of data exchange (and will always do so), then JSON wins by sheer terseness and schema. If you do not, then you will guaranteed run into schema differences of common objects (ie, SAP "Customer" <> Oracle "Customer <> Salesforce "Customer" etc etc). XML w/ XSL/XSD wins here.
gaius 15y ago
Well I am an enterprise developer and I can tell you exactly what XML is for: selling you expensive middleware. It costs a fortune and it starts with an X, it must be eXtremely good right!? I avoid it like the plague as much as I can... But everyone gets bogged down in SOAP WSDL nonsense. Before XML we had CORBA, and before that EDI, and before that ASN.1... Just reinventing the wheel and each time a little worse.
- 6ren 15y ago
  It's unfortunate you're downvoted, as there's truth amid the cynicism. It's true that consultants get paid more for hard-to-use software, and I get the impression even some open-source projects play this card... But, usually there's some progress in successive technologies - from your position, can you see any? I'm interested in understanding the real problems here. For example (AFAIK) XML webservices tend to be less tightly coupled than CORBA's IDLs (though you can tight-couple in any language): - XML using its own format specification language (DTD; XML Schema) helps keep the external data format independent from the application's internal data structures (until some bright spark realizes they can avoid duplication! by deriving one from the other... thus re-coupling them. Because of this, SOAP is CORBA all over again). CORBA's IDL produced an interface for every object. This is fine for methods of the top-level object (that represents the main actions of the application/service), but when applied to objects that form the internal data structures (the nested object tree/graph that is received/sent as an argument/return value), it forces the external format to have the same structure as the internal data structure, thus tightly-coupling them. [And, CORBA tried to do "distributed objects", which just didn't work very well - though it sounds like a good idea.] REST seems to be making a big difference. It explicitly uses "representational state", meaning that the external format is independent of the sender and receiver's internal representation. By defining the format independently of an end-point, it seems you escape tight-coupling. In practice, devs will often derive internal object definitions from the external format - but then they do the loose-coupling themselves, internally, and so tight-coupling is still avoid. [It's seeming to me that deriving internal-->external is bad; but external-->internal is OK.] In a way, I think this progression can be seen as realizing the concept of information hiding in greater and greater depth as time goes on. Does that seem right? What do you think? Can you point me to any references that address these issues (esp about tight-coupling between internal/external representations)? Many thanks for any help!
uriel 15y ago
They are good for creating jobs and selling expensive enterprisey software packages to PHBs.

pnathan 15y ago

JonoW, I'd like to see a definitive case study for the Enterprise SOA system's use of XML. It may be my lack of experience in the area, but I have never found big-iron solutions to be a good solution to anything I have dealt with, usually they seem to be more trouble than the actual problem.

deno 15y ago

> If you just need a light-weight API that is only ever going to be REST orientated, then use JSON. I disagree with that assertion. There is nothing open Web can possibly gain by adopting JSON for its APIs. In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML. Last but not least, what does make XML ill-suited for any ‘lightweight’ APIs? Atom fits nicely with REST and is quite lean. There's hardly anything JSON can offer, to my knowledge, that could be any lighter or more robust.

pavel_lishin 15y ago
Not so heterogeneous if the only data exchange format available is XML.
- deno 15y ago
  Well that's the point, isn't it? XML unifies various independent ecosystems. At the very least, if defines such essential things like data and time representation formats, whereas JSON doesn't even attempt to do that. But then XML goes further and provides you with a contract. Now anyone can write their independent implementation and test it (validate it) to that contract. This is what Web was about in the first place. You can use any technology imaginable, any language imaginable, but in the end you are delivering to common format, HTML+JS. Now that this is insufficient, the natural evolution would be XML and REST. JSON, however, is a liability. I believe it is, in fact, the next IE6!
EdiX 15y ago
> In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML. XML is not any more or less typed, extendible or validatable than JSON. They are both serialisation formats that make you put data into their own structure, a tree with attributes for XML and lists and dictionaries for JSON. Exactly two types exist in XML: tree and text. And exactly six types exist in JSON: list, dictionary, string, number, boolean and null. What XML has that JSON doesn't is a solution for automating validation called XML Schema.

stesch 15y ago

Just use what ever is best for the job. If it would be so easy. A few years ago I had a boss who wanted to use XML everywhere. No matter what. The whole company only had Java+XML as a selling point.