Comparing JSON and XML? Stop it!
中国人は比較が大好きらしい.どのプログラミング言語がもっといいですか?サービス側を書くのがいいですか、それともクライアントを書くのがいいですか.Androidがいいですか、iosがいいですか.デスクトップがいいですか、モバイルがいいですか、それともホームページがいいですか.待って...
このような人は最後に何も学べないと思います.もっと多いのはC言語が分からないので、1行のコードが書けないので、このような問題を提起します.
=================================================
c/s開発をしている人は、JavaScriptが分からなくても、JSONもXMLも聞いたことがあるに違いありません.
これは、データを格納する2つのフォーマットです.
では、中国人の本性は発作しました:who is better?
JSONとXMLはどちらがいいですか?誰がもっと速いですか.私はいったいどれを使うべきですか?自転車と車のどちらがいいかを比較するように?
まず何も言わないで、断片を見てください.
上の2つのセグメントは最も基本的なxmlとjson構造で、誰がこれに基づいてwho is betterを判断することができます!!!1つ目のセグメントは合計140文字、2つ目のセグメントは167文字で、これによってwho is betterを判断することができますか?
彼らの長所と短所を見てみましょう:JSONの長所:Simple syntax,which results in less"markup"overhead compared to XML.Easy to use with JavaScript as the markup is a subset of JS object literal notation and has the same basic data types as JavaScript. JSON Schema for description and datatype and structure validation欠点:Simple syntax,only a handful of different data types are supported.サポートされるデータ型が少ない.
XMLの利点:Generaized markup;it is possible to create “dialects” for any kind of purpose XML Schema for datatype, structure validation. Makes it also possible to create new datatypes XSLT for transformation into different output formats XPath/XQuery for extracting information(which makes getting information in deeply nested structures much easier then with JSON)built in support for namespaces欠点:Relatively wordy compared to JSON(results in more data for the same amount of information). より多くのタイプをサポートし、より多くの情報を追加できます.
また、JSON is a good data format,and it is just a data format
したがって、多くの場合、jsonはxmlに代わることができない:XML is not a data format;it is a language. A very powerful one
foreignerの文章から伏せた理由:リンクhttp://www.yegor256.com/2015/11/16/json-vs-xml.html XPath. To get data like the year of publication from the document above, I just send an XPath query:/book/published/year/text(). However, there has to be an XPath processor that understands my request and returns 2004. The beauty of this is that XPath 2.0 is a very powerful query engine with its own functions, predicates, axes, etc. You can literally put any logic into your XPath request without writing any traversing logic in Java, for example. You may ask “How many books were published by David West in 2004?” and get an answer, just via XPath. JSON is not even close to this.
Attributes and Namespaces. You can attach metadata to your data, just like it’s done above with the id attribute. The data stays inside elements, just like the name of the book author, for example, while metadata (data about data) can and should be placed into attributes. This significantly helps in organizing and structuring information. On top of that, both elements and attributes can be marked as belonging to certain namespaces. This is a very useful technique during times when a few applications are working with the same XML document.
XML Schema. When you create an XML document in one place, modify it a few times somewhere else, and then transfer it to yet another place, you want to make sure its structure is not broken by any of these actions. One of them may use to store the publication date while another uses with ISO-8601. To avoid that mess in structure, create a supplementary document, which is called XML Schema, and ship it together with the main document. Everyone who wants to work with the main document will first validate its correctness using the schema supplied. This is a sort of integration testing in production. RelaxNG is a similar but simpler mechanism; give it a try if you find XML Schema too complex.
XSL. You can make modifications to your XML document without any Java/Ruby/etc. code at all. Just create an XSL transformation document and “apply” it to your original XML. As an output, you will get a new XML. The XSL language (it is purely functional, by the way) is designed for hierarchical data manipulations. It is much more suitable for this task than Java or any other OOP/procedural approach. You can transform an XML document into anything, including plain text and HTML. Some complain about XSL’s complexity, but please give it a try. You won’t need all of it, while its core functionality is pretty straight-forward.
最後の最後に、自分でまとめたいと思っていましたが、stackoverflowでもっとよく見えて、しっかりしていました.
atomic valuesを簡単に伝えたいだけなら、jsonはxmlより使いやすいです.jsonはインターネットに直接使うことができ、多くのアプリケーションに広くサポートされています.そして、簡単なプログラムを書いてjsonを処理することができます.jsonは作成されやすく、Unicode符号化を使用しています.
非構造化データの場合はxmlを使用します
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
彩蛋:I’m not worried about the future of XML at all even if its death is gleefly celebrated by a cadre of web API designers.
And I can’t resist tucking an “I told you so!” token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow? …
最後に、xmlをボイコットする人の多くはintegration developersではなくWeb Developersだという人を見た.
笑って黙って~~
このような人は最後に何も学べないと思います.もっと多いのはC言語が分からないので、1行のコードが書けないので、このような問題を提起します.
=================================================
c/s開発をしている人は、JavaScriptが分からなくても、JSONもXMLも聞いたことがあるに違いありません.
これは、データを格納する2つのフォーマットです.
では、中国人の本性は発作しました:who is better?
JSONとXMLはどちらがいいですか?誰がもっと速いですか.私はいったいどれを使うべきですか?自転車と車のどちらがいいかを比較するように?
まず何も言わないで、断片を見てください.
{
"id": 110,
"title": "Living or Die",
"author": "Wang Shubo",
"published": { "by": "gcd", "year": 2016 } }<?xml version="1.0"?>
<book id="110">
<title>Living or Die</title>
<author>Wang Shubo</author>
<published>
<by>gcd</by>
<year>2016</year>
</published>
</book>上の2つのセグメントは最も基本的なxmlとjson構造で、誰がこれに基づいてwho is betterを判断することができます!!!1つ目のセグメントは合計140文字、2つ目のセグメントは167文字で、これによってwho is betterを判断することができますか?
彼らの長所と短所を見てみましょう:JSONの長所:Simple syntax,which results in less"markup"overhead compared to XML.Easy to use with JavaScript as the markup is a subset of JS object literal notation and has the same basic data types as JavaScript. JSON Schema for description and datatype and structure validation欠点:Simple syntax,only a handful of different data types are supported.サポートされるデータ型が少ない.
XMLの利点:Generaized markup;it is possible to create “dialects” for any kind of purpose XML Schema for datatype, structure validation. Makes it also possible to create new datatypes XSLT for transformation into different output formats XPath/XQuery for extracting information(which makes getting information in deeply nested structures much easier then with JSON)built in support for namespaces欠点:Relatively wordy compared to JSON(results in more data for the same amount of information). より多くのタイプをサポートし、より多くの情報を追加できます.
また、JSON is a good data format,and it is just a data format
したがって、多くの場合、jsonはxmlに代わることができない:XML is not a data format;it is a language. A very powerful one
foreignerの文章から伏せた理由:リンクhttp://www.yegor256.com/2015/11/16/json-vs-xml.html XPath. To get data like the year of publication from the document above, I just send an XPath query:/book/published/year/text(). However, there has to be an XPath processor that understands my request and returns 2004. The beauty of this is that XPath 2.0 is a very powerful query engine with its own functions, predicates, axes, etc. You can literally put any logic into your XPath request without writing any traversing logic in Java, for example. You may ask “How many books were published by David West in 2004?” and get an answer, just via XPath. JSON is not even close to this.
Attributes and Namespaces. You can attach metadata to your data, just like it’s done above with the id attribute. The data stays inside elements, just like the name of the book author, for example, while metadata (data about data) can and should be placed into attributes. This significantly helps in organizing and structuring information. On top of that, both elements and attributes can be marked as belonging to certain namespaces. This is a very useful technique during times when a few applications are working with the same XML document.
XML Schema. When you create an XML document in one place, modify it a few times somewhere else, and then transfer it to yet another place, you want to make sure its structure is not broken by any of these actions. One of them may use to store the publication date while another uses with ISO-8601. To avoid that mess in structure, create a supplementary document, which is called XML Schema, and ship it together with the main document. Everyone who wants to work with the main document will first validate its correctness using the schema supplied. This is a sort of integration testing in production. RelaxNG is a similar but simpler mechanism; give it a try if you find XML Schema too complex.
XSL. You can make modifications to your XML document without any Java/Ruby/etc. code at all. Just create an XSL transformation document and “apply” it to your original XML. As an output, you will get a new XML. The XSL language (it is purely functional, by the way) is designed for hierarchical data manipulations. It is much more suitable for this task than Java or any other OOP/procedural approach. You can transform an XML document into anything, including plain text and HTML. Some complain about XSL’s complexity, but please give it a try. You won’t need all of it, while its core functionality is pretty straight-forward.
最後の最後に、自分でまとめたいと思っていましたが、stackoverflowでもっとよく見えて、しっかりしていました.
atomic valuesを簡単に伝えたいだけなら、jsonはxmlより使いやすいです.jsonはインターネットに直接使うことができ、多くのアプリケーションに広くサポートされています.そして、簡単なプログラムを書いてjsonを処理することができます.jsonは作成されやすく、Unicode符号化を使用しています.
非構造化データの場合はxmlを使用します
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
彩蛋:I’m not worried about the future of XML at all even if its death is gleefly celebrated by a cadre of web API designers.
And I can’t resist tucking an “I told you so!” token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow? …
最後に、xmlをボイコットする人の多くはintegration developersではなくWeb Developersだという人を見た.
笑って黙って~~