Google Maps API V3，响应 XML 的 XSD
我正在尝试使用 JAXB 解析 Google 地图 XML 响应。如果有 google 提供的 XSD 文件那就太好了。有人知道哪里可以得到吗？
如果根本没有现有的 xsd，有人知道为什么 google 不会正式提供此架构吗？他们自己可能同时也在使用这个文件。
谢谢， 用户1146450
I'm trying to parse Google-Maps XML response using JAXB. It'll be very nice to have XSD file provided by google. Anybody knows where to get it?
In case there is no existing xsd at all, anybody knows why google will not offer this schema officially? They themselves are probably also using this file in the meanwhile.
thanks,
user1146450
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的猜测是，没有官方 XSD 可以满足您所寻找的内容；原因是 API 文档的编写方式，特别是它带有首选处理模型，对于 XML 响应来说，该模型是基于 XPath 的。
Google 的 XML 也不是典型的使用 WSDL+XSD 组合描述的传统 Web 服务；它缺少 XML 名称空间，这违反了 WS-I Basic Profile 规则 R1014。
至于为什么，我认为你的问题将会对这个问题产生相当个人的看法，除非你很幸运能从内部人士那里得到答案……届时我将立即删除我的答案……在那之前，这是我认为何时使用 XSD 可能不是一个好主意。
如果世界上只有纯 XML 处理堆栈可用于开发（例如 XML、XSLT 等，XML 设备如 Datapower、Forum、Layer 7 等），那么我会考虑不提供 XML 模式（XSD或其他）几乎是“犯罪”。
如果使用强类型语言，例如 Java 和 C#，那么就会失去 XML 带来的许多灵活性。 XSD 被用作主要工件来促进这些“绑定”技术；它既有助于 XML 的采用，又阻碍了我所说的基于 XML 的处理模型，Google 的 XPath 就是其中之一。
如果语义是通过 XPath 锚定的，那么根据需要对现有 XML 结构进行更改以适应新功能，对于现有处理器来说应该无关紧要。但这就是 JAXB 和 .NET 绑定的瓶颈......
为了缓解这种情况，人们开始使用对于普通开发人员来说过于复杂的 XSD 功能，或者构建描述非常抽象模型的 XSD。所以现在，人们开始以高燃烧率尝试支持所有这一切……
结果可能是，对于简单的结构，从支持的角度来看，一起跳过 XSD 可能会更便宜；大多数人（无论如何）都希望查看示例 XML 来了解 XSD 的含义。如果规范所有者决定在他/她认为合适的任何地方添加新标签，没有人会抱怨，因为基于 XPath 的数据提取始终不受此类更改的影响......尝试使用 XSD 做这样的事情要么是不可能的或非常丑陋......
就 Google 而言，如果大部分都是针对浏览器的，为什么还要费心回答“如何使用 javascript 验证 XML？”......并且没有人希望服务器端应用程序每次都崩溃需要添加一个新标签XML...对于那些认为 xsd 通配符是答案的人来说，我认为这并不总是可能的（请参阅 UPA），或者它会影响 XSD 的易读性，或者它实际上将良好的 XmlNode 重新带回图片中...
总而言之，我认为，从长远来看，XSD +（这里是您的语言）代码绑定会造成更多麻烦和就业；）——比其他任何事情都多！
It is rather my educated guess that there is no official XSD for what you're looking for; reason being the way the API documentation is written, specifically that it comes with a preferred processing model, which for XML responses is XPath based.
Google's XML is also not typical for a traditional Web Service described using a WSDL+XSD combination; it lacks XML namespaces, a violation of a WS-I Basic Profile rule R1014.
As to why, I think your question is poised to get rather personal views on the subject unless you're lucky to get an answer from an insider... At which point I shall delete my answer immeditely... Until then, this is my view on when the use of XSD might not be such a bright idea.
If there would be a world where only a pure XML processing stack would be available for development (e.g. XML, XSLT and the like, XML Appliances such as Datapower, Forum, Layer 7, etc.) then I would consider not providing an XML schema (XSD or other) almost a "crime".
If you throw in strong typed languages, such as Java and C#, then one loses a lot of the flexibility XML brings to the table. XSD was used as the main artifact to facilitate these "bindings" techniques; it both helped with the adoption of XML, and hindered what I call XML-based processing models, of which Google's XPath is one.
If the semantics are anchored with XPaths, then changes to an existing XML structure, as needed to accommodate new features, should not matter to an existing processor. But this is where JAXB and.NET bindings choke...
To alleviate some of this, people start using XSD features that for the average developer are too complex, or build XSDs that describe very abstract models. So now, one starts to have high burning rates trying to support all of this...
It might turn out that for simple structures, it might be cheaper from a support perspective to skip XSD all together; most of the people (anyway) want to see a sample XML to understand what the XSD is all about. If the spec owner decides to add new tags, anywhere s/he sees fit, no one can cry foul as an XPath-based extraction of data would always be impervious to such changes... Trying to do such a thing with XSD would either be impossible or very ugly...
And in Google’s case, if most of it is targeting the browser, why bother to answer “how do I validate XML using javascript?”... And no one wants server side applications crash royally every time one needs to add a new tag to the XML... For those thinking xsd wildcards are the answer, I argue it is not always possible (see UPA), or it affects XSD legibility, or that it actually brings the good XmlNode back into picture...
To sum it up, I am of opinion that XSD + (your language here) code bindings, in long run, caused more hassle, and employment ;) – than anything else!
我想这会对你有帮助。它展示了如何使用 XPath 在 Google Maps API 上处理 XML
https://developers.google.com/maps/documentation/webservices/index#ParsingXML
I think that will help you. it shows how to use XPath to work with XML on Google Maps API
https://developers.google.com/maps/documentation/webservices/index#ParsingXML
（例如）
您可以从地理编码查询接收 XML，然后将其粘贴到在线 XML to XSD 创建器。最后，您需要编辑结果以匹配不同的响应（我必须将目标命名空间和 minOccurs="0" maxOccurs="unbounded" 添加到元素以匹配多个位置）。
你应该得到类似这样的东西（上面的例子是XSD）
(for example)
You can receive an XML from a geocode query, then paste it to online XML to XSD creator. Finally, you need to edit the result to match different responses (I had to add target namespace and minOccurs="0" maxOccurs="unbounded" to the element to match multiple places).
You should get something like this (XSD for the above example)