版本号与协商

版本号格式

已发布的规范的版本号由3个正整数组成，并由小数点分隔，其形式为“x.y.z”。数字“y”和“z”不能超过99。每个规范都独立地编号。比如，WMS 的版本有1.1.1，1.3.0等。

版本变化

一个特定规范的版本号将会随每次改版而发生变化。数字不断增加，并且将会由不多于3个由小数点分隔的正整数组成。第一个整数最有意义。在数字序列中，可能出现断沟，一些数字可能意味着实验的或过渡的版本。服务实例和客户端不需要支持所有的版本，但是必须遵守下面的协商规则。

在请求中和在服务元数据中的出现形式

版本号至少出现在两个地方：描述服务能力的 XML 文档中和客户端对这种服务的请求的参数列表中。客户端请求的一个指定服务实例中使用的版本号必须等于这个实例已经申明支持的版本号。一个服务实例可以支持多种版本，客户端根据协商规则可以发现它们的值。

版本号协商

一个客户端会和一个服务实例协商已决定双方都同意的规范的版本号。协商时通过 GetCapabilitities 操作完成的，并依据下面的规则。

所有的能力 XML 文档必须包含一个协议版本号。为了响应一个包含版本号的 GetCapabilitities 请求，OGC 网络地图服务必须或者响应输出与这个规范版本一致的版本，或者在请求的版本号没有被服务器实现时协商一个双方都同意的版本号。如果请求中没有声明版本号，服务器必须响应一个它能理解的最高的版本号，并标记此响应。

版本号协商如下：

• 如果服务器实现了请求的版本号，必须发送这个版本号；
• 如果客户端请求了一个未知的版本号，此版本号高于服务器能理解的最低的版本号，服务器必须发送低于请求版本号的最高版本号。
• 如果客户端发送的版本号低于服务器所能理解的所有版本号，服务器必须发送一个它能理解的最低版本号。
• 如果客户端不能理解服务器传递的新版本号，它可能或者停止与服务器通信，或者发送一个带有客户端能理解的的新版本号的请求，但这个版本号必须小于服务器发送的版本号（如果服务器已经响应了一个低版本号）。
• 如果服务器已经响应了一个较高的版本号（因为请求中的版本号低于任何服务器能理解的版本号），并且客户端不理解这个版本号，客户端可能会发送一个新的带有高于服务器发送的版本号的版本号。

这个过程会不断重复，直到取得双方都能理解的版本，或者直到客户认为它不能和这个服务通信。

例1，服务器版本1，2，3，4，5和8。客户端理解版本1，3，4，6和7。客户端请求版本7。服务器响应版本5。客户端请求版本4。服务器响应版本4，客户端和服务器都理解版本4，协商成功结束。

例2，服务器响应版本4，5和8。客户端理解版本3。客户端请求版本3。服务器响应版本4。客户端不理解这个版本或者任何更高的版本，因此协商失败，客户端和服务器通信终止。