原文： WADL, WSDL, XSD, and the Web
更多的精彩内容，尽在Stefan Tilkov的blog，这次要讨论的内容是REST 是否需要象WSDL一样的功能，实际上指的是WADL。
我在这里想到了几点：
首先，对于依赖于XSD来描述XML的数据承载，我怀疑WADL比WSDL的真正优势所在。我承认，一些糟糕的WSDL引入正离我们远去，但是那些糟糕的地方并不是互交问题的潜藏之处。我了解WADL同时允许RNG和XSD－我不明白对于Java(或Python或Ruby)来说，RNG的导入/导出机制的状态看起来是什么样的。其实我更喜欢听在人们使用的编程语言中，使用RNG导入功能的经验。
第二，我认为Stefan在阐述(见注解)时，有点偏题了：
“由于紧密的耦合度通常产生于stub和skeleton的生成中，因此我完全不主张这点。”
最终，那些使用带有"."的语言(如：Ruby，C#，Javascript)或带有"/"的语言(如XPath，XSLT，XQuery)的人们，常常会对他们所处理的信息的“形状”作出假设。在微软，我曾经建造了一个“基于点”的编程模型，这个模型在他们允许的范围内很自由，但是，最终如果一个用户依赖于叫做"foobar"的元素的访问，那么不管这个用户用的是带有"."的语言或是带有"/"的语言，那这个元素就需要出现在这个XML中。当然，人们可以在编程中绕过缺失的/可选的数据(感谢上帝有null值)，但是大多数使用XML的程序多少都要关注元素或是属性的名称，这就使得它们成了程序定义中固有的一部分(即使在那些程序的某些部分被存储在代码流之外(例如：属性))
最后，我认为在Stefan的注解中，Erik Johnson所阐述的内容有很多有价值的地方：
“我认为那些喜欢REST(不管以什么形式)的人与其说是在抵制WS-*本身，还不如说是在反抗基于接口的编程－至少我是这么认为的。”
如今，Orcas正处于冲刺阶段，我们都在关注如何/是否有必要在WCF元数据中支持UriTemplate。为了那些期待这个功能的用户，我们很有可能会去做这件事情，但是我们很清楚，吸引人们的很大部分来至于不透名的URI和非元数据，我们保证会将这项工作做得相当出色。
更多的精彩内容，尽在Stefan Tilkov的blog，这次要讨论的内容是REST 是否需要象WSDL一样的功能，实际上指的是WADL。
我在这里想到了几点：
首先，对于依赖于XSD来描述XML的数据承载，我怀疑WADL比WSDL的真正优势所在。我承认，一些糟糕的WSDL引入正离我们远去，但是那些糟糕的地方并不是互交问题的潜藏之处。我了解WADL同时允许RNG和XSD－我不明白对于Java(或Python或Ruby)来说，RNG的导入/导出机制的状态看起来是什么样的。其实我更喜欢听在人们使用的编程语言中，使用RNG导入功能的经验。
第二，我认为Stefan在阐述(见注解)时，有点偏题了：
“由于紧密的耦合度通常产生于stub和skeleton的生成中，因此我完全不主张这点。”
最终，那些使用带有"."的语言(如：Ruby，C#，Javascript)或带有"/"的语言(如XPath，XSLT，XQuery)的人们，常常会对他们所处理的信息的“形状”作出假设。在微软，我曾经建造了一个“基于点”的编程模型，这个模型在他们允许的范围内很自由，但是，最终如果一个用户依赖于叫做"foobar"的元素的访问，那么不管这个用户用的是带有"."的语言或是带有"/"的语言，那这个元素就需要出现在这个XML中。当然，人们可以在编程中绕过缺失的/可选的数据(感谢上帝有null值)，但是大多数使用XML的程序多少都要关注元素或是属性的名称，这就使得它们成了程序定义中固有的一部分(即使在那些程序的某些部分被存储在代码流之外(例如：属性))
最后，我认为在Stefan的注解中，Erik Johnson所阐述的内容有很多有价值的地方：
“我认为那些喜欢REST(不管以什么形式)的人与其说是在抵制WS-*本身，还不如说是在反抗基于接口的编程－至少我是这么认为的。”
如今，Orcas正处于冲刺阶段，我们都在关注如何/是否有必要在WCF元数据中支持UriTemplate。为了那些期待这个功能的用户，我们很有可能会去做这件事情，但是我们很清楚，吸引人们的很大部分来至于不透名的URI和非元数据，我们保证会将这项工作做得相当出色。
