TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Stop Comparing JSON and XML

66 点作者 padraic7a超过 9 年前

20 条评论

jtmarmon超过 9 年前
This article is pretty garbage. compares almost nothing about xml and instead compares the tooling around xml giving no thought to the tooling around json.<p>instead, let me give you my unsolicited opinion:<p>if you need to represent both the structure of your data and characteristics within that structure, xml is great because attributes are a really good way to do that. there&#x27;s a reason most UIs are represented as XML.<p>if your data is just - well, data - use json. or better yet use edn
评论 #10842364 未加载
评论 #10842039 未加载
评论 #10842690 未加载
arocks超过 9 年前
It is a great example &quot;Worse is better&quot;[1]. XML has a lot more functionality than JSON but very few people can fully understand all the X* family of specifications, whereas JSON is a _lot_ easier and handles majority of the use cases.<p>There are many, many real life situations where a developer needs to choose between using JSON, XML or YAML to store their configuration data, message formats etc. Simply stating that JSON is good only in one scenario and XML must be used in every other is over-simplification.<p>[1]: <a href="https:&#x2F;&#x2F;www.dreamsongs.com&#x2F;RiseOfWorseIsBetter.html" rel="nofollow">https:&#x2F;&#x2F;www.dreamsongs.com&#x2F;RiseOfWorseIsBetter.html</a>
评论 #10842144 未加载
haberman超过 9 年前
The entire article rests on this:<p>&gt; JSON was not designed to have such features [as XPath, XML Schema, XSL, etc.]<p>But this claim is not justified, just stated. And the supposed inferiority of eg. JSONPath vs XPath is not justified either.<p>I would actually claim that JSONPath is <i>superior</i> to XPath. JSONPath is much simpler, easier to understand, easier to implement, and still fulfills the most common use cases. Also JSONPath can be evaluated on a streaming input, which is not possible for XPath in general (maybe some subset of XPath queries could support streaming).
Finnucane超过 9 年前
The main problem with comparing XML and JSON is that their use cases don&#x27;t perfectly overlap. I work with complex text documents, typically encoded in TEI schema, and it would be insane to try to do this work in JSON. It&#x27;s possible, but the result would be an incomprehensible mess.<p>Unfortunately, a lot of programming languages have poor support for XML, and standard libraries usually only give you XPath 1.0 compatibility. XPath 2.0 and XQuery 3.0&#x2F;3.1 are far more powerful and flexible, but you need Saxon or a good XML database to make proper use of them.
评论 #10842114 未加载
评论 #10842615 未加载
vanviegen超过 9 年前
Sure, if you define &quot;XML&quot; to include algorithms that operate on it like XSLT and XPath, but define &quot;JSON&quot; to be just the data format, then the former is indeed more featureful.
评论 #10841919 未加载
urvader超过 9 年前
Stop comparing JSON with XML... let me compare them to show why.. ;)
mehrdada超过 9 年前
The article misses the mark, but XML--the language itself, not the tooling--does have an advantage: it is designed to be quite good at one thing that&#x27;s often neglected despite being in its name: extensibility. XML provides enormous flexibility via namespaces and integrating many schemas that your application may or may not understand in one document. When done correctly, it can be a huge win in interoperability in heterogeneous environments and across versions.<p>That said, you could very well argue its additional complexity is often not worth the gain in most applications.<p>Of course, you can also define your own extensibility&#x2F;interoperability conventions with any data serialization format, but the point is XML has it baked in the standard and already provides an accepted way of doing things that everyone has implemented.
TeMPOraL超过 9 年前
It&#x27;s worth linking to the famous XML rant of Erik Naggum:<p><a href="http:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html" rel="nofollow">http:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html</a><p>It&#x27;s both very insightful and enjoyable to read.
scotty79超过 9 年前
XML is interesting case in point that syntax matters. XPath and XSL are so awesome but barely anyone cares because XML.
评论 #10836064 未加载
评论 #10841927 未加载
atilaneves超过 9 年前
Ok, let&#x27;s take the points one by one.<p>XPath: JSON doesn&#x27;t need this in, say, Python or Javascript. You write normal code once it&#x27;s a Python&#x2F;JS dict&#x2F;array&#x2F;list and you&#x27;re done. I don&#x27;t need yet another language, I have general purpose ones that will do just fine.<p>Attributes and namespaces: these can sort of be faked, but fair enough. But then you get discussions on what should be an attribute and what shouldn&#x27;t...<p>Schema: pretty sure this exists for JSON<p>XSL: Ah, the poor man&#x27;s Lisp macros... And, again, easier to do in code in a scripting language.
评论 #10842447 未加载
xchaotic超过 9 年前
Actually the reverse is true: you should compare XML (and related tech) vs JSON vs other options (say HTTP headers) and choose what&#x27;s best for you. I&#x27;ve seen projects that are all about editing books and stubbornly use JSON, where XML would let them have schemas, and I&#x27;ve seen huge chunks of XML being exchanged where a simple key value pair would suffice. Things like JSON Schema indicate that people are using JSON for things not intended for it, likewise XML can be put to bad use.
herge超过 9 年前
The main strength of JSON is that it directly maps to simple data structures that are first class citizens in many programming languages like Ruby, Python, JavaScript, Golang, etc.<p>XML is a bit more complicated, and often need dedicated libraries to manage. Every time I try to get the nth text element of node X with elementtree, it&#x27;s bit of a hassle.
white-flame超过 9 年前
The metadata argument is rarely applicable. Metadata tends to be rich, and it&#x27;s horrible to represent rich data in opaque string attribute values.<p>Rich metadata is therefore represented as child nodes, giving them similar child&#x2F;sibling status as JSON children, and the semantic ambiguity of when to use XML attributes vs child nodes remains.
javajosh超过 9 年前
Nonsense. They look very different, and that matters, at the very least. In particular I like that JSON has some sense of &quot;type&quot; built into the format, when you omit quotes you know it&#x27;s a number or a boolean. You can get that (and better than that, really) with XML Schema (or old-school DTDs) but it&#x27;s baked into JSON. Plus, dealing with JSON in a JavaScript interpreter is about as simple as it gets; only if you&#x27;re programming in XML (e.g. with Ant) would you ever say the same about XML. It&#x27;s quite nice to be able to &quot;dig in&quot; to JSON using normal, plain-vanilla JavaScript dereferencing tools and looping constructs.<p>As for the tooling around XML, that&#x27;s okay, but it&#x27;s almost always overkill, and it almost always turns out the overhead of the tooling becomes a problem in-and-of-itself.<p>Anyway, JSON is actually a better data format.
评论 #10842724 未加载
chipsy超过 9 年前
There is a point, but I think the wrong things are compared to indicate that it&#x27;s &quot;apples to oranges&quot;.<p>XML is designed towards a type of problem that is not an everyday programming problem. It is designed for a full-fledged <i>schema</i> - it builds on the lessons of SGML and its predecessors such as GML[0], for people who need those things, which has historically meant &quot;documentation writers&quot;. DocBook and DITA do not really have equals at what they do, which is semantic, textual content with rich markup. (Yes, you like TeX. But it focuses on presentation for typesetting, not semantic meaning.)<p>This means that in practice XML is really useful for describing an abstract, pre-tokenized syntax. This is a useful tool from a language design perspective; it lets you take an intermediate position between human-friendly and machine-friendly formats, without going straight to binary data or writing a full string parser. When computer language tooling emits an XML AST, they give tool-writers who would like to manipulate or inspect the AST a major leg up.<p>Simpler forms like sexps or JSON exact additional overheads on that problem that can be nearly as bad as just writing a custom string parser, once you get beyond the &quot;strings, numbers, and simple containers&quot; cases that are basically about data serialization, not data parsing. You want to have nodes that have unique names or attributes once you get into the parsing problem, but they are superfluous if you have plain old data. And as soon as you get into mixing different types of documents validation becomes a major concern and XML has the right groundwork for that.<p>It&#x27;s just that most people don&#x27;t want or need to deal with data of that complexity, especially since XML as a plaintext document just looks like angle-bracket trash. For those needs they are better off writing in something that a string parser can work with and then using XML as an intermediate, if at all. Even for the documentation-writing situation, it&#x27;s easier to write Markdown for 98% of the prose and then convert it to add the last 2%.<p>Basically, XML has been used for far too many things that it shouldn&#x27;t, and the blame for that lies on some 90&#x27;s-era hype machines that decided that XML would be the buzzword of the future and pushed it into every technology. We got some nice tooling out of it, but in the end, it&#x27;s still most useful for a certain kind of document markup.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IBM_Generalized_Markup_Language" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IBM_Generalized_Markup_Languag...</a>
评论 #10842485 未加载
EdiX超过 9 年前
<p><pre><code> But XML has XPath, XMLSchema and XSLT and JSON doesn&#x27;t </code></pre> XML has those things because it&#x27;s data model is hostile to every programming language in existence and you need tools designed specifically for it to manipulate it concisely.<p>JSON fits well with the list&#x2F;map&#x2F;primitve data model that is common to most scripting languages so those tools aren&#x27;t needed, you can just use javascript or python, something you use everyday anyway and doesn&#x27;t look alien.<p><pre><code> A similar document would look like this in XML </code></pre> ... plus encoding and schema declaration and also all the garbage involved with dealing with namespaces. Or, at least, don&#x27;t sing praise to XMLSchema and namespaces if you aren&#x27;t going to put them in your example.<p>PS. XML is a markup language, if your data is a text document with markup then XML is a good choice, otherwise leave it alone.
krick超过 9 年前
So, what screenshot from &quot;The Men Who Stare at Goats&quot; is there for?
jamesmalvi超过 9 年前
This tool will help to convert json to xml <a href="http:&#x2F;&#x2F;jsonformatter.org" rel="nofollow">http:&#x2F;&#x2F;jsonformatter.org</a>
adnam超过 9 年前
Not to mention that XML is generally more suitable for streamed i&#x2F;o.
评论 #10842539 未加载
vmorgulis超过 9 年前
Looks like a troll...