4 ms·
XML is for documents, s-expressions (or JSON or YAML or ...) is for data.
by bct 19y ago
XML is for documents, s-expressions (or JSON or YAML or ...) is for data.
- fauigerzigerk 19y agoSo an entire HTML page is a document whereas a fragment of a page retrieved via XHR is data, right?
- bct 19y agoIf you're just going to shove it straight in the page, then it's part of a document. It's the difference between <p>here is a <a href="http://example.com">link</a>.</p> and <name>bct</name> <dob>19xx-07-03</dob> <address>...</address> One is markup, the other is something different.
- fauigerzigerk 19y agoI see what you mean but I'm not convinced that this difference merits the use of two different representations. And the difference gets blurred if you consider that XHTML makes it possible to include basically any kind of data in the document, not just elements meant to be document structure.
- bct 19y agoOh, I don't think there's anything wrong with using XML for data - it's just that these "XML sucks" rants always seem to assume that's all it's used for. I know that a JSON version of my XHTML fragment up there would suck pretty hard; would a s-exp one be any better? (honest question)
- fauigerzigerk 19y agoWhy would the JSON version of that fragment suck pretty hard? I don't think there is any rational argument for XML, JSON or s-expressions solely based on whether something is data or a document. I think to make that judgement, we need to consider things like when do we really need namespaces? How often is a particular expression written by hand, how often is it generated automatically? How important are different character encodings? Does it have to be bandwidth efficient? Is this a type of data that might actually morph into a program or is that something we want to exclude for security or complexity reasons? Are there existing tools that help us to process one or the other representation more easily? All these things depend on many more aspects than just data or document.
- olavk 19y ago> Why would the JSON version of that fragment suck pretty hard? The fragment uses attributes and mixed content - something that would be quite ugly to express in JSON. I wont event try.
- bct 19y ago> Why would the JSON version of that fragment suck pretty hard? ["p", "this is a", ["a", { "text" : "link", "href": "http://example.com" } ], "." ] I don't do much JSON so maybe that can be improved, but I wouldn't imagine by much. Certainly there are lots of other factors to be considered, but that just goes to prove my point; that "XML Sucks" rarely looks at anything beyond very simple uses of XML.
- fauigerzigerk 19y agoMaybe like this: ["p", "this is a", ["a", "link", {href: "http://example.com http://example.com"}], "."] If that is uglier is debatable, maybe a little bit. However, the point is really that suckyness is not just a matter of esthetics. All the more I agree with your second point.
- mdemare 19y agoI knew there was a code/data divide, but not that there also was one between documents and data.
- bct 19y agoData isn't really a good word for it (because obviously a document is a kind of data), but I can't think of a better one.
- cstejerean 19y agoA document needs to contain information (most of the time) about the layout of the document. So an HTML page is a document most of the time. The data is the TEXT and most of the HTML is there simply to tell the browser how to render the data. I think the argument above was that XML is great for creating document formats where as JSON or S-Expressions are great for sending data around.
- jimbokun 19y agoOr as expressed by Glenn Reid, quoted in the article: "A markup language is predicated on the idea that the markup is an exception in a river of text."
- jsmcgd 19y agoActually s-expressions are pretty good for documents too. If you start to use lisp you'll probably wish everything was in a sexpr.