🚀 go-pugleaf

ժҪ��
����Twitter streaming APIȡ����XML֧�֣�FoursquareҲֻ֧��JSON�����Dz�
����ζ��JSon��XML������ȡ��
norman.walsh��Ϊ������ˣ�
1����web API designers��˵������ֻ��Ҫ����һЩ�����������ɵ���ݽṹ��
��ǣ�浽�ǽṹ����ݣ����ҿ��Ա���xml��javascript�����mapping����ֱ�ۣ�
����JSon��㡣
2��XML�����Ͳ���ר���������Ӧ��������ģ�XML���ó��ڴ���ǽṹ�����
��mixed content�������������Ƶ�Schema���塣����Ϊ�ǽṹ����ݵĽ�����ʽ��
һ���ϣ�XML��Ȼ�Dz�������


http://norman.walsh.name/2010/11/17/deprecatingXML
Someone asked me recently what I thought about XML being removed 
from the Twitter streaming API. Around the same time, I heard that 
Foursquare are also moving to a JSON-only API. ¶

As an unrepentant XML fan, here's the full extent of my reaction: ¶

��Meh��. ¶

If all you want to pass around are atomic values or lists or hashes 
of atomic values, JSON has many of the advantages of XML: it's 
straightforwardly usable over the Internet, supports a wide variety 
of applications, it's easy to write programs to process JSON, it 
has few optional features, it's human-legible and reasonably clear, 
its design is formal and concise, JSON documents are easy to 
create, and it uses Unicode. ¶

If you're writing JavaScript in a web browser, JSON is a natural 
fit. The XML APIs in the browser are comparitively clumsy and the 
natural mapping from JavaScript objects to JSON eliminates the 
serialization issues that arise if you're careless with XML. ¶

One line of argument for JSON over XML is simplicity. If you mean 
it's simpler to have a single data interchange format instead of 
two, that's incontrovertibly the case. If you mean JSON is 
intrinsically simpler than XML, well, I'm not sure that's so 
obvious. For bundles of atomic values, it's a little simpler. And 
the JavaScript APIs are definitely simpler. But I've seen attempts 
to represent mixed content in JSON and simple they aren't. ¶

In short, if all you need are bundles of atomic values and 
especially if you expect to exchange data with JavaScript, JSON is 
the obvious choice. I don't lose any sleep over that. ¶

XML wasn't designed to solve the problem of transmitting structured 
bundles of atomic values. XML was designed to solve the problem of 
unstructured data. In a word or two: mixed content. ¶

XML deals remarkably well with the full richness of unstructured 
data. I'm not worried about the future of XML at all even if its 
death is gleefully 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? ¶

I predict there will come a day when someone wants to federate JSON 
data across several application domains. I wonder, when they 
discover that the key ��width�� means different things to different 
constituencies, will they invent namespaces too? ¶

In the meantime, I'll continue to model the full and rich 
complexity of data that crosses my path with XML, and bring a broad 
arsenal of powerful tools to bear when I need to process it, easily 
and efficiently extracting value from all of its richness. I'll 
send JSON to the browser when it's convenient and I'll map the the 
output of JSON web APIs into XML when it's convenient. ¶

JSON vs. XML? Meh.
--

�� ��Դ:��ˮľ���� http://newsmth.net��[FROM: 198.80.129.*]