授予XML是非常有用的，但是可能很冗长。 有哪些替代方案，它们是否专门用于任何特定目的？ 库支持轻松查询内容是一大优势。
似乎有很多对JSON的多平台支持。
杰夫(Jeff)在"尖括号税"(The Angle Bracket Tax)上的文章总结了许多替代方法(嗯，主要是YAML)，并引导我进入有关轻量标记语言的Wiki文章。
更新：尽管对于某些应用程序，YAML可能是XML的"替代品"，但正如我首先想到的那样，两者不是同构的。
确实，它"不是标记语言"。
此外，YAML看上去并不像"轻量级"。对于可以用纯XML表示的文档(例如Jeff的示例)，YAML显然不那么冗长。但是，YAML提供了许多其他专门的结构，其中包含的字符和序列比XML保留的要多得多。
最重要的是，如果您正在寻找XML-without-angle-brackets，YAML不是。
不要忘记YAML！
JSON似乎有更好的支持。例如，Prototype JS库具有出色的内置JSON函数。
我不会关闭纯文本，例如CSV或制表符分隔的文本。
HDF5是一种非常紧凑的数据格式，具有与xml类似的某些特征。 .net库尚有许多不足之处，但该格式在大小和性能方面都可以很好地扩展。
您可以尝试使用Google的protobuf。它比XML快得多。有C，C ++，C＃，Java和Python的库(有针对ruby和perl的alpha versons)。但这是二进制的。
我使用XML的工作几乎都是以文档为中心的XML，该文件必须对任意嵌套结构的长序列进行建模。我还没有使用过JSON，但是我的印象是，使用类似文档的数据很麻烦，但是如果使用类似记录的数据则适应性很好，甚至很优雅。在做出决定时，请考虑数据的形状。
如果您不需要将属性应用于元素，则S-Expressions效果很好。另一种选择是YAML。
TOML是新的大事。它具有YAML的优点，没有很大的规格。它扩展了常见且熟悉的配置文件格式。它直接类似于JSON(并可以翻译成JSON)。有所有主要语言的支持。由Github联合创始人/总裁Tom创建，并自恋。这很棒。试一试！
TOML示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| # This is a TOML document. Boom.
title ="TOML Example"
[owner]
name ="Tom Preston-Werner"
organization ="GitHub"
bio ="GitHub Cofounder & CEO\
Likes tater tots and beer."
dob = 1979-05-27T07:32:00Z # First class dates? Why not?
[database]
server ="192.168.1.1"
ports = [ 8001, 8001, 8002 ]
connection_max = 5000
enabled = true
[servers]
# You can indent as you please. Tabs or spaces. TOML don't care.
[servers.alpha]
ip ="10.0.0.1"
dc ="eqdc10"
[servers.beta]
ip ="10.0.0.2"
dc ="eqdc10"
[clients]
data = [ ["gamma","delta"], [1, 2] ]
# Line breaks are OK when inside arrays
hosts = [
"alpha",
"omega"
] |
XML通常用于配置，在这种情况下，还经常使用其他一些简单的存储格式(较少面向文档)：
.property文件
INI文件
根据平台和语言的不同，有多种读写方式。
如果有人查找XML的详细程度较低的替代品，而XML或多或少是同构的，则可以使用AXON。 为了解释，考虑XML和AXON中等效表示的示例。 还有支持AXON格式的python库pyaxon。
XML格式
1
2
3
4
5
| <person>
<name>Alex</name>
34</age>
mail@example.com</email>
</person> |
轴突
1
2
3
4
| person {
name {"Alex"}
age {34}
email {"mail@example.com"}} |
XML格式
1
2
3
4
5
6
7
8
9
10
11
| <memo date="2008-02-14">
<from>
<name>The Whole World</name>us@world.org</email>
</from>
<to>
<name>Dawg</name>dawg158@aol.com</email>
</to>
<message>
Dear sir, you won the internet. http://is.gd/fh0
</message>
</memo> |
轴突
1
2
3
4
5
6
7
8
| memo {
date:2008-02-14
from {
name{"The Whole World"} email{"us@world.org"}}
to {
name{"Dawg"} email{"dawg158@aol.com"}}
message {"Dear sir, you won the internet. http://is.gd/fh0"}
} |
XML格式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| <club>
<players>
<player id="kramnik"
name="Vladimir Kramnik"
rating="2700"
status="GM" />
<player id="fritz"
name="Deep Fritz"
rating="2700"
status="Computer" />
<player id="mertz"
name="David Mertz"
rating="1400"
status="Amateur" />
</players>
<matches>
<match>
<Date>2002-10-04</Date>
<White refid="fritz" />
<Black refid="kramnik" />
<Result>Draw</Result>
</match>
<match>
<Date>2002-10-06</Date>
<White refid="kramnik" />
<Black refid="fritz" />
<Result>White</Result>
</match>
</matches>
</club> |
轴突
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| club {
players {
player {
id:"kramnik"
name:"Vladimir Kramnik"
rating:2700
status:"GM"}
player {
id:"fritz"
name:"Deep Fritz"
rating:2700
status:"Computer"}
player {
id:"mertz"
name:"David Mertz"
rating:1400
status:"Amateur"}}
matches {
match {
Date{2002-10-04}
White{refid:"fritz"}
Black{refid:"kramnik"}
Result{"Draw"}}
match {
Date{2002-10-06}
White{refid:"kramnik"}
Black{refid:"fritz"}
Result{"White"}}}} |
您要如何处理数据？存放吗？通过它吗？显示吗？这些问题将推动您寻找合适的技术。仅仅询问您应如何格式化数据就好比询问您应使用哪种语言进行编程，而无需指定要完成的工作。
对于大多数数据任务，Codd博士可以解决：http：//en.wikipedia.org/wiki/Edgar_F._Codd。数据库应该能够执行您所想到的任何事情。
如果您要传递它，我建议您使用纯文本。当您滚动自己的二进制格式时，解析器将消失，数据也会消失。
对于纯文本，更深层的问题是元数据的放置位置。它应该在数据文件的外部还是内部("自我描述")。
例如，XML是纯文本，但是源代码也是如此。对于源文件，有一个关于语法和语义的详细说明，而XML应该是自描述的。问题是事实并非如此。此外，它是从文档表示和标记的基础上发展而来的，但是现在被滥用于各种数据序列化，传输和存储。
为了完整起见，我会提到Edifact，我很久以前就为此写了一个接口。
JSON是有效的YAML，可能非常有用。二对一！
但是要花多少钱呢？
在许多情况下，我全都支持JSON，尤其是在需要考虑重量或客户端工作的情况下，但是从XML移走将失去可读性(在那些配置文件中如此重要)，以及XSLT和XPath等未来问题解决方案的强大功能。一定要确定为什么以及何时离开：这是事实上的标准，这是有原因的。
(此外：我的习惯是在内部使用XML，然后将其转换为JSON，这是所需的输出)
异端！ XML是数据之王。
对篡夺者说"不"，请昂首阔步！
XML万岁！
但是如果需要数据，请认真使用Json，以获得支持和优雅，但是如果您需要格式化，xpath(例如查询，其他元数据等)，请坚持使用XML
注意：我使用Xml进行配置系统构建代码生成和类似任务，但使用Json进行Rpc，Sql进行查询和持久性，最后使用Yaml在这里和那里进行日志记录和快速任务，换句话说，根据需要选择适当的格式。
对于诸如序列化和配置之类的常见任务，简单声明性语言是XML的不错替代。它提供了一个C＃和Java解析器库。我认为它擅长指定各种元数据而无需XML冗长。
I wouldn't dismiss plain text, like CSV or tab-delimited.
我真的在寻找具有定义的结构和(跨平台，多语言)库支持的替代方案。我对研究不同的设计及其优缺点感兴趣。我喜欢可以具有文本和"二进制"(紧凑，"编译"，快速I / O，较小占用空间)格式的格式的想法。拥有库的优点是它们可以执行解析，还可以为您执行额外的数据操作/验证。
尽管这么说，但绝对可以使用.ini，.plist和CSV等简单格式。您不必总是使用锤子来敲开螺母。
如果您以DSL的角度询问，Guide Scheme可能会有所帮助，正如S表达式已经建议的那样。
我个人也将JSON用于AJAX事务。
XML适用于文本标记，但对于通用结构而言，序列化是一个非常糟糕的选择，JSON更适合于此。
您喜欢的任何东西，只要它不是ASN.1
JSON可以以多种方式使用，但是它特别适合与我发现的MySQL表一起使用。它也可以很好地与Android(GSON库或JSON)一起使用。除此之外，它还可以单独或作为数组传输少量数据。
对于存储类似代码的数据，LES(Loyc表达式语法)是一种崭新的选择。我注意到许多人将XML用于类似代码的结构，例如支持条件，命令调用甚至有时甚至是循环的构建系统。在LES中，这些事情看起来很自然：
1
2
3
4
5
6
7
8
9
| // LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite] // an"attribute"
Output(
if version > 4.0 {
$ProjectDir/Src/Foo;
} else {
$ProjectDir/Foo;
}
); |
但是，它还没有强大的工具支持。当前唯一的LES库适用于C＃。当前，只有一个应用程序使用LES：LLLPG。
从理论上讲，您可以使用LES进行数据或标记，但是对于如何做到这一点没有标准：
1
2
3
4
5
6
7
8
9
| body {
'''Click here to use the World's '''
a href="http://google.com" {
strong"most popular";" search engine!"
};
};
point = (2, -3);
tasteMap = {"lemon" -> sour;"sugar" -> sweet;"grape" -> yummy }; |
为了提及...请看一下我的建议：
http://igagis.github.io/stob/
它非常简单，并且不会重载各种特殊符号，基本上只是{}和"。
支持C ++样式注释。
有C ++，C＃和Java库。
例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| "String object"
AnotherStringObject
"String with children"{
"child 1"
Child2
"child three"{
SubChild1
"Subchild two"
Property1 {Value1}
"Property two" {"Value 2"}
//comment
/* multi-line
comment */
"multi-line
string"
"Escape sequences \" \
\
\\t \\\"
}
} |
