如果不了解更多，我们无法真正回答这个问题。仅仅因为您当前不依赖任何其他项目，您是否有可能在将来的某个时候与它们进行交互？如果是这样，他们更喜欢什么技术？在 BBC，我们有一些“仅 JSON”的项目，却发现想要访问我们 API 的 Java 开发人员恳求我们提供一个简单的 XML API，仅仅是因为他们有这样的能力。许多工具都是围绕 XML 构建的。他们甚至不关心命名空间、属性或其他任何东西；他们只是想要那些尖括号。
话虽这么说，我不了解你的系统，所以很难说正确的做法是什么。另外，JSON 和 YAML 并不完全可以与 XML 互换。细微的差异可能并且会让你犯错。
We can't really answer that without knowing a lot more. Just because you're not currently dependent on any other projects, are you likely to interact with them at some point in the future? If so, what technologies do they prefer? At the BBC, we've had some projects "JSON-only", only to find out that Java developers who wanted to access our API were begging us to provide a simple XML API simply because they have so many tool built around XML. They didn't even care about namespaces, attributes, or anything else; they just wanted those angle-brackets.
As for "storing feeds", I also not sure what you mean there. You explain the data in the feed, but what are you then going to do with those feeds? Parse them? Cache and reserve them? Write them out to cuneiform tablets? :)
I sounds like what you actually want is a database and you want to persist the data there and later make it serialisable as JSON/YAML/XML or whatever your desired format is. What I'd recommend is to be able to pull the data out into a Perl data structure and then have "formatters" which know how to serialise that data structure to the desired output. That way you can serialise to, say, JSON, and later if that's not good enough, easily switch to YAML or something else. In fact, if others need your data (one-way data tends not to be useful), they can ask for JSON, YAML, XML or whatever. You have more flexibility and aren't tied into a decision that you made up front.
That being said, I don't know your system, so it's tough to say what the right thing to do is. Also, not that JSON and YAML aren't exactly interchangeable with XML. Subtle differences can and will trip you up.
XML 的优点是更多语言捆绑了相关库，并且对于您提到的存储很有用。因此，它对于在不同的系统（“运动中”和“静止”）之间传递是有价值的。
YAML 具有适用于所有语言的库，但不太常用，因此您更有可能必须找到并引入一个库。
Each will do the job.
JSON has the advantage of super-easy parsing in JavaScript, though you'll probably have to find and introduce a library in other languages.
XML has the advantage that more languages bundle the relevant libraries, and is useful for the storage you mention. So, it is valuable for passing around through different systems, both "in-motion" and "at-rest".
YAML has libraries for all languages, but is somewhat less commonly used, so you are more likely to have to find and introduce a library.
我认为 JSON 一旦经过美化就非常可读，这很容易做到。 YAML 很难变得紧凑，因为它依赖于空格。当然，您应该依靠压缩来节省带宽。 YAML 中的引用可能会节省一些字节，但会增加很多复杂性。如果您确实要处理大量数据，因此避免重复很重要，我建议您在另一个层面上解决该问题。甚至 XML 也不支持此类宏。
I think XML has been thoroughly explained by the others. However, YAML and JSON are both elegant languages, and they are not as similar as you might believe at first glance.
- person: &id002
name: James
age: 5.0
- person: *id001
The second person is an associative array equal to the first.
Casting data types
foobar: !!str 123
foobar is "123" (type string).
Uncommon data types not supported by every implementation
Wikipedia:
Particularly interesting ones [...] are sets, ordered maps, timestamps, and hexadecimal.
Therefore, I consider JSON a lot simpler.
An argument for JSON
Not just for JavaScript
While it might seem stupid to use the "JavaScript Object Notation" for your application if you don't use JavaScript, you should really consider it anyway, because the data types offered in JSON are probably the most common ones in your language too.
Readable, even if the whitespace is optional
I think JSON is very readable once prettified, which is very easy to do. YAML is difficult to make compact, since it relies on the whitespace. Granted, you should rely on compression for saving bandwidth. The references in YAML might save you a few bytes, but they add a lot of complexity. If you are really dealing with amounts of data that makes it important to avoid duplication, I'd suggest solving that problem on a whole other level. Not even XML supports these kind of macros.
如果您需要与您无法控制的系统进行互操作（XML 模式在这里非常宝贵），如果您要将数据广泛转换为文本、HTML 或 XML（尽管有讨厌的人，XSLT 是无与伦比的），如果您的数据包括大量文本标记，如果您的数据需要人工编辑（尽管有讨厌的人，针对模式进行验证的可编辑 XML 对于很多工作来说是一个非常好的工具），和/或如果您需要互操作无数的数据使用 XML 的工具和技术。
如果您确实不介意上述任何一项，请选择 JSON。
如果您在有大量 YAML 支持的环境中工作，请选择 YAML。
Choose XML if you need to interoperate with systems you don't control (XML Schema is invaluable here), if you will be transforming the data extensively into text, HTML, or XML (haters notwithstanding, XSLT is peerless), if your data includes a lot of text markup, if your data needs to be human-editable (haters notwithstanding, editable XML that's validated against a schema is a pretty good tool for a lot of jobs), and/or if you need to interoperate any of the myriad of tools and technologies that work with XML.
Choose JSON if you really can't be bothered with any of the above.
Choose YAML if you're working in an environment that's got a lot of YAML support.
I agree with Joe. For example, if it's a javascript app; json would be a strong candidate. Personally, I'd go with json for just about anything but only because that is the one I'm most comfortable with.
JSON would be my pick. JSON and YAML are lightweight and easy to get started with (no formal Schema required). JSON is more widely used and more compatible with various other technologies than YAML. For example, PHP has a built-in function to decode or encode JSON, not YAML. JavaScript of course just loves JSON, considering it’s a strict subset of valid JavaScript.
I prefer YAML in that case. for interaction with javascript use json. If you truly need to define your own grammar (read: schema) then xml is it. Very powerful, you have to decide what you are trying to do - otherwise your question is too broad to give a definitive answer.
If the data's not hierarchical or going to have data interspersed in e.g., the description This product is great for <targetDemo/> who love it's <featureSet/>), you may want to consider Comma Separated Values (CSV) or some other format like tab separated.
It's old school but it gets the job done without weighing your file down with a bunch of describing text. I.e., in XML, you'd have the following non-value data for each feed.
<feed name="" price="" type="" description=""/>
...contrasted with CSV:
"", , "", ""
If you want, you can add header row at the top for documentation purposes.
There's also plenty of tooling around CSV, from command line utilities like awk to GUIs such as Excel.
Another alternative, if you don't really need the data to be editable via a text editor but don't want to deploy a more robust database service, would be SQLite which allows you to perform RDBMS-style CRUD operations on a flat binary file.
YAML 可以使用 &/* 表示法处理非树数据结构。 XML 和 JSON 都没有内置的方法来执行此操作。不过，您的用途不需要它。
In the absence of interoperability concerns, i don't think there's much in it. There are good libraries for all of them in all languages; some of them are built-in, some aren't. Yur interface to those libraries will be narrow - just in data-access code - so if one has a painful API, even that doesn't matter much.
JSON is, for me, the most pleasant to edit by hand, which is a small plus.
YAML can handle non-tree data structures using the &/* notation. Neither XML nor JSON have a built-in way to do that. Your use doesn't need it, though.
I think xml is for big data and json is for small and not too complex data that do not need multiple dimension of array. I might be wrong. ^^ And i only see yaml in google app engine. Which appear to me , it is quite suitable for storing preferences and data of an application.
发布评论
评论（10）
如果不了解更多，我们无法真正回答这个问题。仅仅因为您当前不依赖任何其他项目，您是否有可能在将来的某个时候与它们进行交互？如果是这样，他们更喜欢什么技术？在 BBC，我们有一些“仅 JSON”的项目，却发现想要访问我们 API 的 Java 开发人员恳求我们提供一个简单的 XML API，仅仅是因为他们有这样的能力。许多工具都是围绕 XML 构建的。他们甚至不关心命名空间、属性或其他任何东西；他们只是想要那些尖括号。
至于“存储提要”，我也不确定你的意思。您解释了提要中的数据，但是您将如何处理这些提要呢？解析它们？缓存并保留它们？把它们写成楔形文字板？ :)
我听起来你真正想要的是一个数据库，并且你想将数据保存在那里，然后将其序列化为 JSON/YAML/XML 或任何你想要的格式。我建议能够将数据提取到 Perl 数据结构中，然后使用知道如何将该数据结构序列化为所需输出的“格式化程序”。这样您就可以序列化为 JSON，然后如果这还不够好，可以轻松切换到 YAML 或其他格式。事实上，如果其他人需要您的数据（单向数据往往没有用），他们可以要求 JSON、YAML、XML 或其他任何数据。您拥有更大的灵活性，并且不会受制于您预先做出的决定。
话虽这么说，我不了解你的系统，所以很难说正确的做法是什么。另外，JSON 和 YAML 并不完全可以与 XML 互换。细微的差异可能并且会让你犯错。
We can't really answer that without knowing a lot more. Just because you're not currently dependent on any other projects, are you likely to interact with them at some point in the future? If so, what technologies do they prefer? At the BBC, we've had some projects "JSON-only", only to find out that Java developers who wanted to access our API were begging us to provide a simple XML API simply because they have so many tool built around XML. They didn't even care about namespaces, attributes, or anything else; they just wanted those angle-brackets.
As for "storing feeds", I also not sure what you mean there. You explain the data in the feed, but what are you then going to do with those feeds? Parse them? Cache and reserve them? Write them out to cuneiform tablets? :)
I sounds like what you actually want is a database and you want to persist the data there and later make it serialisable as JSON/YAML/XML or whatever your desired format is. What I'd recommend is to be able to pull the data out into a Perl data structure and then have "formatters" which know how to serialise that data structure to the desired output. That way you can serialise to, say, JSON, and later if that's not good enough, easily switch to YAML or something else. In fact, if others need your data (one-way data tends not to be useful), they can ask for JSON, YAML, XML or whatever. You have more flexibility and aren't tied into a decision that you made up front.
That being said, I don't know your system, so it's tough to say what the right thing to do is. Also, not that JSON and YAML aren't exactly interchangeable with XML. Subtle differences can and will trip you up.
每个人都会完成工作。
JSON 的优点是可以在 JavaScript 中进行超级简单的解析，尽管您可能需要找到并引入其他语言的库。
XML 的优点是更多语言捆绑了相关库，并且对于您提到的存储很有用。因此，它对于在不同的系统（“运动中”和“静止”）之间传递是有价值的。
YAML 具有适用于所有语言的库，但不太常用，因此您更有可能必须找到并引入一个库。
Each will do the job.
JSON has the advantage of super-easy parsing in JavaScript, though you'll probably have to find and introduce a library in other languages.
XML has the advantage that more languages bundle the relevant libraries, and is useful for the storage you mention. So, it is valuable for passing around through different systems, both "in-motion" and "at-rest".
YAML has libraries for all languages, but is somewhat less commonly used, so you are more likely to have to find and introduce a library.
我认为 XML 已经被其他人彻底解释过了。然而，YAML 和 JSON 都是优雅的语言，它们并不像您乍一看那样相似。
有关 YAML 的一些特殊性
参考
<块引用>
<前><代码>-人员：&id002
姓名：詹姆斯
年龄：5.0
- 人员：*id001
第二人称是与第一人称相同的关联数组。
转换数据类型
<块引用>
foobar 是“123”（字符串类型）。
并非所有实现都支持不常见的数据类型
维基百科：
<块引用>
特别有趣的是集合、有序映射、时间戳和十六进制。
因此，我认为 JSON 简单很多。
JSON 的论点
不仅仅适用于 JavaScript
如果您不使用 JavaScript，那么在您的应用程序中使用“JavaScript 对象表示法”可能看起来很愚蠢，但无论如何您都应该考虑它，因为数据类型以 JSON 提供的可能也是您的语言中最常见的。
可读，即使空格是可选的
我认为 JSON 一旦经过美化就非常可读，这很容易做到。 YAML 很难变得紧凑，因为它依赖于空格。当然，您应该依靠压缩来节省带宽。 YAML 中的引用可能会节省一些字节，但会增加很多复杂性。如果您确实要处理大量数据，因此避免重复很重要，我建议您在另一个层面上解决该问题。甚至 XML 也不支持此类宏。
I think XML has been thoroughly explained by the others. However, YAML and JSON are both elegant languages, and they are not as similar as you might believe at first glance.
Some of the particularities about YAML
References
The second person is an associative array equal to the first.
Casting data types
foobar is "123" (type string).
Uncommon data types not supported by every implementation
Wikipedia:
Therefore, I consider JSON a lot simpler.
An argument for JSON
Not just for JavaScript
While it might seem stupid to use the "JavaScript Object Notation" for your application if you don't use JavaScript, you should really consider it anyway, because the data types offered in JSON are probably the most common ones in your language too.
Readable, even if the whitespace is optional
I think JSON is very readable once prettified, which is very easy to do. YAML is difficult to make compact, since it relies on the whitespace. Granted, you should rely on compression for saving bandwidth. The references in YAML might save you a few bytes, but they add a lot of complexity. If you are really dealing with amounts of data that makes it important to avoid duplication, I'd suggest solving that problem on a whole other level. Not even XML supports these kind of macros.
如果您需要与您无法控制的系统进行互操作（XML 模式在这里非常宝贵），如果您要将数据广泛转换为文本、HTML 或 XML（尽管有讨厌的人，XSLT 是无与伦比的），如果您的数据包括大量文本标记，如果您的数据需要人工编辑（尽管有讨厌的人，针对模式进行验证的可编辑 XML 对于很多工作来说是一个非常好的工具），和/或如果您需要互操作无数的数据使用 XML 的工具和技术。
如果您确实不介意上述任何一项，请选择 JSON。
如果您在有大量 YAML 支持的环境中工作，请选择 YAML。
Choose XML if you need to interoperate with systems you don't control (XML Schema is invaluable here), if you will be transforming the data extensively into text, HTML, or XML (haters notwithstanding, XSLT is peerless), if your data includes a lot of text markup, if your data needs to be human-editable (haters notwithstanding, editable XML that's validated against a schema is a pretty good tool for a lot of jobs), and/or if you need to interoperate any of the myriad of tools and technologies that work with XML.
Choose JSON if you really can't be bothered with any of the above.
Choose YAML if you're working in an environment that's got a lot of YAML support.
我同意乔的观点。例如，如果它是一个 javascript 应用程序； json 将是一个强有力的候选者。就我个人而言，我几乎会使用 json 来处理任何事情，但这只是因为这是我最舒服的方式。
I agree with Joe. For example, if it's a javascript app; json would be a strong candidate. Personally, I'd go with json for just about anything but only because that is the one I'm most comfortable with.
JSON 将是我的选择。 JSON 和 YAML 是轻量级的且易于上手（不需要正式的架构）。 JSON 比 YAML 使用更广泛，并且与各种其他技术更兼容。例如，PHP 有一个内置函数来解码或编码 JSON，而不是 YAML。 JavaScript 当然只是喜欢 JSON，因为它是有效 JavaScript 的严格子集。
JSON would be my pick. JSON and YAML are lightweight and easy to get started with (no formal Schema required). JSON is more widely used and more compatible with various other technologies than YAML. For example, PHP has a built-in function to decode or encode JSON, not YAML. JavaScript of course just loves JSON, considering it’s a strict subset of valid JavaScript.
取决于您的需求。对于小型、轻量级应用程序，我个人认为 XML 太过分了： http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
在这种情况下我更喜欢 YAML。
要与 javascript 交互，请使用 json。
如果您确实需要定义自己的语法（阅读：模式），那么 xml 就是它。非常强大，你必须决定你想要做什么 - 否则你的问题太宽泛而无法给出明确的答案。
Depends on your needs. For small, lightweight apps I personally think XML is overkill: http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
I prefer YAML in that case.
for interaction with javascript use json.
If you truly need to define your own grammar (read: schema) then xml is it. Very powerful, you have to decide what you are trying to do - otherwise your question is too broad to give a definitive answer.
如果数据不是分层的或者数据散布在例如描述中
该产品非常适合>如果您喜欢它的 )，您可能需要考虑逗号分隔值 (CSV) 或其他一些格式，例如制表符分隔。这是老式的，但它可以完成工作，而无需用一堆描述文本来压垮你的文件。即，在 XML 中，每个提要都具有以下非值数据。
...与 CSV 对比：
如果需要，您可以在顶部添加标题行以用于文档目的。
还有大量围绕 CSV 的工具，从 awk 等命令行实用程序到 Excel 等 GUI。
如果您确实不需要通过文本编辑器编辑数据，但又不想部署更强大的数据库服务，则另一种选择是 SQLite 允许您对平面二进制文件执行 RDBMS 样式的 CRUD 操作。
If the data's not hierarchical or going to have data interspersed in e.g., the description
This product is great for <targetDemo/> who love it's <featureSet/>), you may want to consider Comma Separated Values (CSV) or some other format like tab separated.It's old school but it gets the job done without weighing your file down with a bunch of describing text. I.e., in XML, you'd have the following non-value data for each feed.
...contrasted with CSV:
If you want, you can add header row at the top for documentation purposes.
There's also plenty of tooling around CSV, from command line utilities like awk to GUIs such as Excel.
Another alternative, if you don't really need the data to be editable via a text editor but don't want to deploy a more robust database service, would be SQLite which allows you to perform RDBMS-style CRUD operations on a flat binary file.
在没有互操作性问题的情况下，我认为其中没有太多意义。对于所有语言都有很好的库；其中一些是内置的，一些不是。你与这些库的接口会很窄——仅在数据访问代码中——所以如果一个人有一个痛苦的 API，即使这样也没什么关系。
对我来说，JSON 是最令人愉快的手动编辑方式，这是一个小小的优点。
YAML 可以使用 &/* 表示法处理非树数据结构。 XML 和 JSON 都没有内置的方法来执行此操作。不过，您的用途不需要它。
In the absence of interoperability concerns, i don't think there's much in it. There are good libraries for all of them in all languages; some of them are built-in, some aren't. Yur interface to those libraries will be narrow - just in data-access code - so if one has a painful API, even that doesn't matter much.
JSON is, for me, the most pleasant to edit by hand, which is a small plus.
YAML can handle non-tree data structures using the &/* notation. Neither XML nor JSON have a built-in way to do that. Your use doesn't need it, though.
我认为xml适用于大数据，json适用于小型且不太复杂的数据，不需要多维数组。我可能错了。 ^^
我只在谷歌应用程序引擎中看到 yaml 。在我看来，它非常适合存储应用程序的首选项和数据。
I think xml is for big data and json is for small and not too complex data that do not need multiple dimension of array. I might be wrong. ^^
And i only see yaml in google app engine. Which appear to me , it is quite suitable for storing preferences and data of an application.