4 ms·
XML really is the mindkiller (and the bandwidth-killer). Let's compare & contrast XML, S-expressions and JSON for the two examples in the article: <?xml ve
by zeveb 11y ago
XML really is the mindkiller (and the bandwidth-killer). Let's compare & contrast XML, S-expressions and JSON for the two examples in the article:
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
</D:propfind>
becomes:
(propfind (prop getcontenttype getetag))
or:
{
"op": "propfind",
"prop": ["getcontenttype", "getetag"]
}
And:
<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:time-range start="20150909T000000Z" end="20300909T000000Z"/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>
becomes:
(calendar-query
(prop getcontenttype getetag)
(filter (component "VCALENDAR")
(component "VEVENT" (time-range "2015-09-09T00:00:00Z" "2030-09-09T00:00:00Z"))))
or:
{
"op": "calendar-query",
"prop": ["getcontenttype", "getetag"],
"filter": [
{
"component": "VCALENDAR"
},
{
"component": "VEVENT",
"filter": {
"time-range": ["2015-09-09T00:00:00Z", "2030-09-09T00:00:00Z"]
}
}
]
}
I think it's pretty clear which is least readable and least concise.
So, what does XML buy one in exchange for its lack of concision? Well, a pre-processing tool which knows nothing about WebDAV or CalDAV could use a schema definition to sanity-check the formatting of a query. It could probably be set up to detect if one used an invalid date format; it may or may not be configurable to detect if one searched for a VCALENDAR component inside a VEVENT. Regardless, there are semantic constraints in a data model which cannot be expressed with, e.g., a DTD or XSD.
How about JSON? What does it buy? Well, it has built-in hash tables (as opposed to faking them with (table (key val) (key2 val2))), which is a huge win, and it has a ton of libraries in every language one can imagine.
How about S-expressions? I think that they win on clarity, readability and concision. But there are not a ton of parsing libraries available for every language (OTOH, a canonical-S-expression parser can be written in a few hours for any language).
So, who wins? I think that for most projects nowadays, JSON's clearly the answer. The pain of XML simply doesn't pay off in practice, while the elegance of S-expressions doesn't outweigh the unfamiliarity of the great mass of enterprise software developers.
But if you have a choice, use S-expressions.
- tveita 11y agoWebDAV cannot be validated by schema, since an implementation must be able to ignore elements it does not understand. (RFC 4918: "A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.")
- untitaker_ 11y agoYeah, but it's not only that. In the general usecase you only want content-type and etag, so why not just send no body for that? That's what remoteStorage does. It's the only way to do folder listings.
- phlakaton 11y agoI think that's a gross oversimplification. Here you're critiquing XML's use as a substrate for a query language, for which I think you have a good point. For APIs there are reasons why JSON is generally easy enough to work with. But there is a sweet spot for semistructured documents where I would say XML still has the edge, because you don't have to quote text and errors in structure are much easier to identify. The specific problem domain matters with choices like these. See "XML Is Not S-Expressions" for a deeper treatment of the question.
- zeveb 11y ago> But there is a sweet spot for semistructured documents where I would say XML still has the edge, because you don't have to quote text and errors in structure are much easier to identify. No argument—as a markup language, XML is find (not perfect, but fine); it's a better markup language than either JSON or S-expressions. But as a data encoding, it's far inferior to JSON and S-expressions. > See "XML Is Not S-Expressions" for a deeper treatment of the question. Yeah, I've read it. He's right that XML is better for documents; he's wrong that the benefits of integrating data and document encoding are worth the pain of XML.