11 ms·

The irony is that CDATA isn't even very useful; there's no way to escape the ]]> closing tag so you still have to invent some special escaping mechanism to use

The irony is that CDATA isn't even very useful; there's no way to escape the ]]> closing tag so you still have to invent some special escaping mechanism to use it. Nobody expects entity definitions in XML either, and yet about once a year some new service or software is found vulnerable to XXE attacks. (Summary: a lot of XML parsers can be made to open arbitrary files or network sockets and sometimes return the content.) XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now.

TimWolla 12y ago
You are allowed to chain CDATA-tags: ]]]]><![CDATA[> > CDATA sections may occur anywhere character data may occur; (http://www.w3.org/TR/REC-xml/#sec-cdata-sect http://www.w3.org/TR/REC-xml/#sec-cdata-sect)
- TheLoneWolfling 12y ago
  Is it just me who sees this as a very bad idea?
  - dietrichepp 12y ago
    It's really handy for some use cases. For example, if you are writing documentation involving XML, you might put your example XML in CDATA sections. The way CDATA works is also far simpler than XML's predecessor, SGML. I'd say it's a good feature. It sucks that there are some shoddy libraries out there, but oh well.
    - deleted 12y ago
      [deleted]
    - TheLoneWolfling 12y ago
      I mean chaining CDATA tags as a way to escape CDATA tags as a bad idea. It'll break anything that doesn't expect it - in particular I can see anything that does round-trips from/to XML breaking.
      - jerf 12y ago
        Everything already must expect it. Nothing in XML prevents "some text content <![CDATA[blah blah]]> other text content" from appearing in a text node. There is no obligation that CDATA must be the only thing in a text node. IIRC, many parsers will already return multiple nodes for text if you put an entity in the middle ("text & text" coming back as three nodes), so you're already really and truly broken (i.e., not just "theoretically" broken) if you can't handle consecutive text-like nodes and merge them in some manner. This is especially true since you can entity-encode anything at all, so you already must be able to handle "hello world" properly anyhow or you've got a straight-up bug.
adamtulinius 12y ago
"Fortunately we have JSON now." Which doesn't support big ints. JSON isn't a silver bullet.
- NelsonMinar 12y ago
  Fair enough. Then again XML doesn't support any kind of int and yet we managed. (Unless you count XML Schema, in which case now you have N problems.)
  - 1ris 12y ago
    As a Peano-player I'd represent the interger 3 in xml as <succ> <succ> <succ> <zero></zero> </succ> </succ> </succ>
    - raverbashing 12y ago
      Don't give them ideas...
  - the_why_of_y 12y ago
    Actually they split things up nicely so you can use XMLSchema part 2 (which contains the useful data types) without part 1 (which contains the N problems you mention).
- mike_hearn 12y ago
  So far the only serialization format I've found which isn't stuffed with surprising quirks is protobufs.
  - cbsmith 12y ago
    One could make an argument that its zigzag format is mildly quirky, but in general, I'd agree. Protobufs have some surprising limitations, but their simplicity has limited their quirkiness.
    - 12y ago
jimmaswell 12y ago
The fact that some people don't properly configure their parsers isn't an argument against the format.
- 0x0 12y ago
  It kind of is, though, since the format specifies a very non-obvious feature which may have serious security consequences if left enabled, which isn't easily discoverable for users starting with xml, and, frankly has little use. A better format would bring less surprises.
  - schoen 12y ago
    Yeah, many users would actually not like some of these features. If you're using XML to serialize static tree-structured data in a fixed schema (like people commonly use JSON), would you expect that your parser would be vulnerable to this? https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs
- NelsonMinar 12y ago
  "Some people" is a pretty big category with some good company. Google in April 2014, for instance. Or PostgreSQL in 2012. http://blog.detectify.com/post/82370846588/how-we-got-read-access-on-googles-production http://blog.detectify.com/post/82370846588/how-we-got-read-a... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3489 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3489
  - ssclafani 12y ago
    Facebook as well: http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution http://www.ubercomp.com/posts/2014-01-16_facebook_remote_cod... XXE to Remote Code Execution. They paid out their largest bounty ever for it, $33,500.
- rodgerd 12y ago
  If making your parser spec-compliant makes it more vulnerable to security problems that would tend to suggest something other than the parser is problematic. See also: https://www.youtube.com/watch?v=PE9fXM7aOxo https://www.youtube.com/watch?v=PE9fXM7aOxo
lobster_johnson 12y ago
One of the main problems isn't just encoding XML correctly, but the additive mistakes that arise when information is copied and reused, where along the way some part of the chain does a mistake: - Information scraped from a web page that was in ISO-8859-1 - Stored in a database that is Windows-1252 - Then emitted through an API in UTF-8 by someone who writes strings by ("<tag>" + string concatenatation + "</tag>") - Then stored in a new database as UTF-8 but not sanity-checked (ie., MySQL instead of Postgres) - Then emitted as an XML feed ...etc. Along the way someone forgets to encode the "&" and the data contains random spatterings of ISO-8895-1 characters, and you're screwed. Most parsers I have encountered aren't lenient by default, and will barf on non-conformant input. So now the last link in the chain needs to sanitize and normalize, which is a pain.
colanderman 12y ago
XML is [...]* designed for editing text documents.* Was this ever a stated design goal? SGML, sure, probably; but I've never seen any evidence that XML had "document markup" as its sole intended application.
- nkurz 12y ago
  I'm sure it's up for interpretation, but it's a reasonably defensible position. Here's what the XML 1.0 Spec has to say: Abstract The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. ... 1. Introduction Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents. XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure. ... 1.1 Origin and Goals ... The design goals for XML are: XML shall be straightforwardly usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write programs which process XML documents. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly. The design of XML shall be formal and concise. XML documents shall be easy to create. Terseness in XML markup is of minimal importance. http://www.w3.org/TR/1998/REC-xml-19980210 http://www.w3.org/TR/1998/REC-xml-19980210
  - personZ 12y ago
    The single and only interpretation that goes from that to "designed for editing text documents" is the fact that the authors called them "XML Documents". But XML Documents != "text documents". XML Documents are big property bags of data, and have no correlation with "editing text documents". The primary use of XML was, and remains, data exchange, where system A generates data that is consumed by system B.
dietrichepp 12y ago
> XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now. XML is about as simple as it gets for structured text documents. HTML is more complicated. Plain text is not expressive enough. Markdown, Asciidoc, reStructuredText, Wiki Creole, etc. all have pretty severe shortcomings by comparison to XML, and text processing systems will sometimes just convert those formats to XML. XML is easy to parse, easy to edit, and easy to emit. XML also gives us SVG, which is lovely. Yeah, use JSON everywhere else. But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long.
- gioele 12y ago
  > But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long. Also note that the XML 1.0 specification contains the specification of the data format and of a schema language for the format itself (DTD). Without the definition of DTD, XML could be much much simpler. I second Norman Walsh's proposal for XML 2.0: Just drop the <!DOCTYPE> declaration [1]. XML is pretty good as it is for its intended scope (marking up text), dropping the DOCTYPE/DTD would remove the main source of complexity and insecurity. [1] http://www.tbray.org/ongoing/When/200x/2005/12/15/Drop-the-Doctype http://www.tbray.org/ongoing/When/200x/2005/12/15/Drop-the-D...
- haberman 12y ago
  > XML also gives us SVG, which is lovely. That implies that SVG needed XML. SVG just needed a structured data format. It could just as easily have used JSON or Protocol Buffers and it would still be SVG. > XML is easy to parse More like it seems easy to parse. Plenty of people think they are parsing XML but their ad hoc "parsers" know nothing about CDATA, DTDs, external entities, processing instructions, or comments. > easy to edit ...except for gotchas like the fact that you need to entity-escape any ampersands in attributes (like "href"). > and easy to emit Harder than it sounds. A single error renders the whole document invalid, and when you're compositing information from different data sources, it's easy to make mistakes: https://web.archive.org/web/20080701064734/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20080701064734/http://diveintoma... > The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long. Sure, but combined with the other specs which are assumed to be part of a modern XML stack (namespaces at least, and often XML schema, XSLT, etc), you have grown a pretty complicated mess that isn't a great match for what it's often used for.
ScottBurson 12y ago
> Fortunately we have JSON now. Of course, we had s-expressions long ago. But I agree about XML.
cbsmith 12y ago
> Fortunately we have JSON now. Even JSON is really a sin. Using simple binary data formats like protocol buffers makes so much more sense.
drdaeman 12y ago
XML and JSON are different data formats with different properties and different uses. Please, don't blame one and praise the other, just use what's appropriate. It's somehow like with data structures - say, one won't generally use a graph when he actually needs a set, right? Trying to stash data into a semantically inappropriate format leads to kludges, and I'd say some JSON-based formats (for example, HAL-JSON) feel like so. Obviously, it's the same (or, possibly, even worse) for XMLish abominations like SOAP. Neither XML nor JSON are silver bullets. My point is, while sure, XML has its issues and arcane features, it's not universally terrible. Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible yet still functional and expressive subset of XML for the most typical use cases, huh. Somehow in a same manner, XML was "extracted" from SGML.
- sk5t 12y ago
  Why the nasty words for SOAP/XML? I mean, it can be kind of unpleasant to work with, but it holds some major advantages over popular alternatives for building and consuming non-trivial web APIs. WSDL as a mechanism to describe serialization style, operations, endpoints, data types and enums, security bindings, etc., plus all the tooling it makes possible are quite powerful.
  - NelsonMinar 12y ago
    Wow, are some poor bastards still using WSDL somewhere? I thought it was long dead. Back in 2006 I wrote up a quick bit on why SOAP sucks, my experience of running a couple of Google public SOAP services. Basically none of the stuff you describe actually works. http://www.somebits.com/weblog/tech/bad/whySoapSucks.html http://www.somebits.com/weblog/tech/bad/whySoapSucks.html
    - sk5t 12y ago
      SOAP/XML, WSDL, and related tooling are not always a walk in the park, but they certainly haven't faded into history. Indeed there are plenty of pathological cases, and overblown, tool-bound APIs designed by architecture astronauts, but it is also possible to publish and consume them in a manner just as simple and straightforward as the examples suggest. Taking just one example from my own experience, Salesforce's SOAP/XML services have proven easy to use, sensibly managed and versioned, and far quicker than hand-building structures to manage "simpler" REST.
personZ 12y ago
designed for editing text documents This sort of argument has never held water, and it constantly perplexes me that it gets a pass in tech discussions. Even if we accept the dubious assertion that it was "designed" for editing text documents, the origins of some invention say literally nothing about its utility for a purpose. Further, as complex as XML may be, comparing the robust, rich, diverse ecosystem of XML support with the amateur hour, barely credible JSON world is quite a contrast. JSON doesn't even have a date type (and everyone seems to roll their own). It lacks any sort of robust validation or transformation system: XML schemas are really one of XML's greatest features, and the nascent, mostly broken similes in JSON world don't compare. JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.
- jhpriestley 12y ago
  With JSON you use a programming language to transform your data. You also use a programming language to validate your data. Validating and transforming data are some of the most basic capabilities of all general-purpose programming languages, and reinventing these facilities badly in a not-exactly-programming-language like XSLT or XML Schema is a waste of time.
  - Mikhail_Edoshin 12y ago
    This is same as saying that one shouldn't use parser generators or even describe the grammar of a language in Backus-Naur form. Any language is usually very well equipped with tools to read strings and BNF is absolutely not a programming language. Is it a waste of time? If you validate a couple of document formats, then maybe, but if you need to validate many different formats on a regular basis you'll soon want to split your program into 1) a language that describes the rules and 2) an interpreter that takes such a description and validates a document against it. DTD, XML Schema, and Relax NG are just such tools.
- Someone1234 12y ago
  I like XML for structured data. I also like XSL for self-documenting format to format conversion (or display). However I am going to respectfully disagree with you about XML schemas, they suck... XML schemas don't "understand" XML the language, and as a result you cannot use schemas unless you're using XML wrongly. For example, in XML: <myroot> <thing> <name>Robot</name> <size>15</size> </thing> <person> <name>John Smith</name> <id>12345</id> </person> </myroot> And: <myroot> <person> <name>John Smith</name> <id>12345</id> </person> <thing> <name>Robot</name> <size>15</size> </thing> </myroot> These two XML documents produce identical DOM and or XPaths. The fact that person and thing are inverted in the second example is irrelevant, but now try to write a schema definition which supports either thing/person or person/thing ordering. It is possible to do with just one node switch in the above example, but convoluted. As you add more and more nodes the definition becomes unmanageable, imagine 10+ nodes on the same "level" but they can be ordered randomly, and are all required (and your schema needs to check they exist). XML schema sucks, really sucks, when you use XML correctly and ignore node order. So if you choose to use a schema you're then forced to also require everything in an exacting order which can be problematic when XML is automatically generated from dozens of different systems or people. XML schema sucked so bad we wrote our own replacement in Java. It just generates an XML DOM tree (via the standard libraries), then it parses your "schema" file which is just a list of XPaths with either a required, optional, or excluded flag. It is like 20 lines of code and it is better than XML Schema language.

TimWolla 12y ago

You are allowed to chain CDATA-tags: ]]]]><![CDATA[> > CDATA sections may occur anywhere character data may occur; (http://www.w3.org/TR/REC-xml/#sec-cdata-sect http://www.w3.org/TR/REC-xml/#sec-cdata-sect)

TheLoneWolfling 12y ago
Is it just me who sees this as a very bad idea?
- dietrichepp 12y ago
  It's really handy for some use cases. For example, if you are writing documentation involving XML, you might put your example XML in CDATA sections. The way CDATA works is also far simpler than XML's predecessor, SGML. I'd say it's a good feature. It sucks that there are some shoddy libraries out there, but oh well.
  - deleted 12y ago
    [deleted]
  - TheLoneWolfling 12y ago
    I mean chaining CDATA tags as a way to escape CDATA tags as a bad idea. It'll break anything that doesn't expect it - in particular I can see anything that does round-trips from/to XML breaking.
    - jerf 12y ago
      Everything already must expect it. Nothing in XML prevents "some text content <![CDATA[blah blah]]> other text content" from appearing in a text node. There is no obligation that CDATA must be the only thing in a text node. IIRC, many parsers will already return multiple nodes for text if you put an entity in the middle ("text & text" coming back as three nodes), so you're already really and truly broken (i.e., not just "theoretically" broken) if you can't handle consecutive text-like nodes and merge them in some manner. This is especially true since you can entity-encode anything at all, so you already must be able to handle "hello world" properly anyhow or you've got a straight-up bug.

adamtulinius 12y ago

"Fortunately we have JSON now." Which doesn't support big ints. JSON isn't a silver bullet.

NelsonMinar 12y ago
Fair enough. Then again XML doesn't support any kind of int and yet we managed. (Unless you count XML Schema, in which case now you have N problems.)
- 1ris 12y ago
  As a Peano-player I'd represent the interger 3 in xml as <succ> <succ> <succ> <zero></zero> </succ> </succ> </succ>
  - raverbashing 12y ago
    Don't give them ideas...
- the_why_of_y 12y ago
  Actually they split things up nicely so you can use XMLSchema part 2 (which contains the useful data types) without part 1 (which contains the N problems you mention).
mike_hearn 12y ago
So far the only serialization format I've found which isn't stuffed with surprising quirks is protobufs.
- cbsmith 12y ago
  One could make an argument that its zigzag format is mildly quirky, but in general, I'd agree. Protobufs have some surprising limitations, but their simplicity has limited their quirkiness.
  - 12y ago

jimmaswell 12y ago

The fact that some people don't properly configure their parsers isn't an argument against the format.

0x0 12y ago
It kind of is, though, since the format specifies a very non-obvious feature which may have serious security consequences if left enabled, which isn't easily discoverable for users starting with xml, and, frankly has little use. A better format would bring less surprises.
- schoen 12y ago
  Yeah, many users would actually not like some of these features. If you're using XML to serialize static tree-structured data in a fixed schema (like people commonly use JSON), would you expect that your parser would be vulnerable to this? https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs
NelsonMinar 12y ago
"Some people" is a pretty big category with some good company. Google in April 2014, for instance. Or PostgreSQL in 2012. http://blog.detectify.com/post/82370846588/how-we-got-read-access-on-googles-production http://blog.detectify.com/post/82370846588/how-we-got-read-a... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3489 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3489
- ssclafani 12y ago
  Facebook as well: http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution http://www.ubercomp.com/posts/2014-01-16_facebook_remote_cod... XXE to Remote Code Execution. They paid out their largest bounty ever for it, $33,500.
rodgerd 12y ago
If making your parser spec-compliant makes it more vulnerable to security problems that would tend to suggest something other than the parser is problematic. See also: https://www.youtube.com/watch?v=PE9fXM7aOxo https://www.youtube.com/watch?v=PE9fXM7aOxo

lobster_johnson 12y ago

One of the main problems isn't just encoding XML correctly, but the additive mistakes that arise when information is copied and reused, where along the way some part of the chain does a mistake: - Information scraped from a web page that was in ISO-8859-1 - Stored in a database that is Windows-1252 - Then emitted through an API in UTF-8 by someone who writes strings by ("<tag>" + string concatenatation + "</tag>") - Then stored in a new database as UTF-8 but not sanity-checked (ie., MySQL instead of Postgres) - Then emitted as an XML feed ...etc. Along the way someone forgets to encode the "&" and the data contains random spatterings of ISO-8895-1 characters, and you're screwed. Most parsers I have encountered aren't lenient by default, and will barf on non-conformant input. So now the last link in the chain needs to sanitize and normalize, which is a pain.

colanderman 12y ago

XML is [...]* designed for editing text documents.* Was this ever a stated design goal? SGML, sure, probably; but I've never seen any evidence that XML had "document markup" as its sole intended application.

nkurz 12y ago
I'm sure it's up for interpretation, but it's a reasonably defensible position. Here's what the XML 1.0 Spec has to say: Abstract The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. ... 1. Introduction Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents. XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure. ... 1.1 Origin and Goals ... The design goals for XML are: XML shall be straightforwardly usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write programs which process XML documents. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly. The design of XML shall be formal and concise. XML documents shall be easy to create. Terseness in XML markup is of minimal importance. http://www.w3.org/TR/1998/REC-xml-19980210 http://www.w3.org/TR/1998/REC-xml-19980210
- personZ 12y ago
  The single and only interpretation that goes from that to "designed for editing text documents" is the fact that the authors called them "XML Documents". But XML Documents != "text documents". XML Documents are big property bags of data, and have no correlation with "editing text documents". The primary use of XML was, and remains, data exchange, where system A generates data that is consumed by system B.

dietrichepp 12y ago

> XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now. XML is about as simple as it gets for structured text documents. HTML is more complicated. Plain text is not expressive enough. Markdown, Asciidoc, reStructuredText, Wiki Creole, etc. all have pretty severe shortcomings by comparison to XML, and text processing systems will sometimes just convert those formats to XML. XML is easy to parse, easy to edit, and easy to emit. XML also gives us SVG, which is lovely. Yeah, use JSON everywhere else. But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long.

gioele 12y ago
> But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long. Also note that the XML 1.0 specification contains the specification of the data format and of a schema language for the format itself (DTD). Without the definition of DTD, XML could be much much simpler. I second Norman Walsh's proposal for XML 2.0: Just drop the <!DOCTYPE> declaration [1]. XML is pretty good as it is for its intended scope (marking up text), dropping the DOCTYPE/DTD would remove the main source of complexity and insecurity. [1] http://www.tbray.org/ongoing/When/200x/2005/12/15/Drop-the-Doctype http://www.tbray.org/ongoing/When/200x/2005/12/15/Drop-the-D...
haberman 12y ago
> XML also gives us SVG, which is lovely. That implies that SVG needed XML. SVG just needed a structured data format. It could just as easily have used JSON or Protocol Buffers and it would still be SVG. > XML is easy to parse More like it seems easy to parse. Plenty of people think they are parsing XML but their ad hoc "parsers" know nothing about CDATA, DTDs, external entities, processing instructions, or comments. > easy to edit ...except for gotchas like the fact that you need to entity-escape any ampersands in attributes (like "href"). > and easy to emit Harder than it sounds. A single error renders the whole document invalid, and when you're compositing information from different data sources, it's easy to make mistakes: https://web.archive.org/web/20080701064734/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20080701064734/http://diveintoma... > The 1.0 specification http://www.w3.org/TR/REC-xml/ http://www.w3.org/TR/REC-xml/ is not very long. Sure, but combined with the other specs which are assumed to be part of a modern XML stack (namespaces at least, and often XML schema, XSLT, etc), you have grown a pretty complicated mess that isn't a great match for what it's often used for.

ScottBurson 12y ago

> Fortunately we have JSON now. Of course, we had s-expressions long ago. But I agree about XML.

cbsmith 12y ago

> Fortunately we have JSON now. Even JSON is really a sin. Using simple binary data formats like protocol buffers makes so much more sense.

drdaeman 12y ago

XML and JSON are different data formats with different properties and different uses. Please, don't blame one and praise the other, just use what's appropriate. It's somehow like with data structures - say, one won't generally use a graph when he actually needs a set, right? Trying to stash data into a semantically inappropriate format leads to kludges, and I'd say some JSON-based formats (for example, HAL-JSON) feel like so. Obviously, it's the same (or, possibly, even worse) for XMLish abominations like SOAP. Neither XML nor JSON are silver bullets. My point is, while sure, XML has its issues and arcane features, it's not universally terrible. Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible yet still functional and expressive subset of XML for the most typical use cases, huh. Somehow in a same manner, XML was "extracted" from SGML.

sk5t 12y ago
Why the nasty words for SOAP/XML? I mean, it can be kind of unpleasant to work with, but it holds some major advantages over popular alternatives for building and consuming non-trivial web APIs. WSDL as a mechanism to describe serialization style, operations, endpoints, data types and enums, security bindings, etc., plus all the tooling it makes possible are quite powerful.
- NelsonMinar 12y ago
  Wow, are some poor bastards still using WSDL somewhere? I thought it was long dead. Back in 2006 I wrote up a quick bit on why SOAP sucks, my experience of running a couple of Google public SOAP services. Basically none of the stuff you describe actually works. http://www.somebits.com/weblog/tech/bad/whySoapSucks.html http://www.somebits.com/weblog/tech/bad/whySoapSucks.html
  - sk5t 12y ago
    SOAP/XML, WSDL, and related tooling are not always a walk in the park, but they certainly haven't faded into history. Indeed there are plenty of pathological cases, and overblown, tool-bound APIs designed by architecture astronauts, but it is also possible to publish and consume them in a manner just as simple and straightforward as the examples suggest. Taking just one example from my own experience, Salesforce's SOAP/XML services have proven easy to use, sensibly managed and versioned, and far quicker than hand-building structures to manage "simpler" REST.

personZ 12y ago

designed for editing text documents This sort of argument has never held water, and it constantly perplexes me that it gets a pass in tech discussions. Even if we accept the dubious assertion that it was "designed" for editing text documents, the origins of some invention say literally nothing about its utility for a purpose. Further, as complex as XML may be, comparing the robust, rich, diverse ecosystem of XML support with the amateur hour, barely credible JSON world is quite a contrast. JSON doesn't even have a date type (and everyone seems to roll their own). It lacks any sort of robust validation or transformation system: XML schemas are really one of XML's greatest features, and the nascent, mostly broken similes in JSON world don't compare. JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.

jhpriestley 12y ago
With JSON you use a programming language to transform your data. You also use a programming language to validate your data. Validating and transforming data are some of the most basic capabilities of all general-purpose programming languages, and reinventing these facilities badly in a not-exactly-programming-language like XSLT or XML Schema is a waste of time.
- Mikhail_Edoshin 12y ago
  This is same as saying that one shouldn't use parser generators or even describe the grammar of a language in Backus-Naur form. Any language is usually very well equipped with tools to read strings and BNF is absolutely not a programming language. Is it a waste of time? If you validate a couple of document formats, then maybe, but if you need to validate many different formats on a regular basis you'll soon want to split your program into 1) a language that describes the rules and 2) an interpreter that takes such a description and validates a document against it. DTD, XML Schema, and Relax NG are just such tools.
Someone1234 12y ago
I like XML for structured data. I also like XSL for self-documenting format to format conversion (or display). However I am going to respectfully disagree with you about XML schemas, they suck... XML schemas don't "understand" XML the language, and as a result you cannot use schemas unless you're using XML wrongly. For example, in XML: <myroot> <thing> <name>Robot</name> <size>15</size> </thing> <person> <name>John Smith</name> <id>12345</id> </person> </myroot> And: <myroot> <person> <name>John Smith</name> <id>12345</id> </person> <thing> <name>Robot</name> <size>15</size> </thing> </myroot> These two XML documents produce identical DOM and or XPaths. The fact that person and thing are inverted in the second example is irrelevant, but now try to write a schema definition which supports either thing/person or person/thing ordering. It is possible to do with just one node switch in the above example, but convoluted. As you add more and more nodes the definition becomes unmanageable, imagine 10+ nodes on the same "level" but they can be ordered randomly, and are all required (and your schema needs to check they exist). XML schema sucks, really sucks, when you use XML correctly and ignore node order. So if you choose to use a schema you're then forced to also require everything in an exacting order which can be problematic when XML is automatically generated from dozens of different systems or people. XML schema sucked so bad we wrote our own replacement in Java. It just generates an XML DOM tree (via the standard libraries), then it parses your "schema" file which is just a list of XPaths with either a required, optional, or excluded flag. It is like 20 lines of code and it is better than XML Schema language.