4．7 应答
由服务器返回给客户端操作结果
4．8 地图
地理数据的图示化表达
4．9 空间参考系
投影坐标或地理坐标参考系统
4．10 性能XML（capabilities XML）
用于描述从服务实例可获取的操作和服务内容的服务级元数据
5 约定
5.1 规范化动词
在本文档中那些标明为规范性内容的章节里，关键词“required”, “shall”“,shall not”, “should”, “should not”, “recommended”, “may”, 和“optional”要按照[IETF RFC 2119]中的描述进行解释。
动词“deprecate”表明是为了与早期版本兼容才在这个规范中保留所引用的部分。但是在本规范的未来版本中可在未进一步说明的情况下将其删除。
5.2 缩写术语 CGI 公共网关接口 DCP 分布式计算平台 DTD 文件类型定义 EPSG 欧洲石油测量组 GIF 图形交换格式 GIS 地理信息系统
GML 地理标记语言 HTTP 超文本传输协议 IETF 网络工程任务组 JPEG 联合图象专家组
MIME 多用途网络邮件扩充协议 OGC 开放式地理信息系统联盟
OWS 开放式地理信息系统联盟网络服务 PNG 可移植的网络图象文件 RFC 征求意见 SLD 格式化层描述符 SVG 可缩放的矢量图形 URL 统一的资源定位
WebCGM 网络计算机图形元文件 WCS 网络覆盖服务 WFS 网络要素服务
15
WMS 网络地图服务 XML 可扩展标记语言
6 基本服务要素
这个条款规定了对网络地图服务器行为（更明确的是OGC网络服务器的行为）的有关要求，它独立于特定的操作，或属于几个操作共有的。
6.1 版本的编号和协商
6.1.1 版本号的形式
已公布的规范版本号包括三个正整数，它们用小数点分开，以“x.y.z”的形式出现，数字“y”和“z”不超过99。每个OWS规范都是独立的编号。
6.1.2 版本号的变化
对于一个特定的规范来说，随着每次修订，规范的版本号必须改变。版本号必须单调的增加，并由不超过三个用小数点分隔的正整数组成，其中，第一个整数重要。在号码序列上可以出现中断。有一些版本号表示了实验性的或是临时性的版本。服务实例及其客户端不需要支持所有已定义的版本，但是应该遵守下面将要叙述的协商规则。
6.1.3 在请求中和服务元数据中的出现
版本号至少出现两个地方：描述服务的Capabilities XML和客户请求服务的参数列表。客户对一个特定服务进行请求时使用的版本号必须是该服务已申明支持的版本号（如下所述的协调情况除外）。一个服务实例可以支持好几个版本，客户端可以根据协商规则得到其具体的版本号。
6.1.4 版本号协商
一个OWS客户端可以和服务实例进行协商，以确定一个对双方都合适的规范版本号。依照以下规则，版本号协商是运用如下规则通过GetCapabilities操作（在7.1节中讲述）完成的。
所有的Capabilities XML都必须包括一个协议版本号。在应答包含了一个版本号的GetCapabilities请求时，OGC网络服务必须按照请求中使用的规范版本进行回应，或者当请求中的版本在本服务器上没有实施时，必须与客户端进行协商，寻求一个对双方都合适的版本。如果在请求里没有说明版本号，服务器必须以它能理解的最高版本的规范来应答，并且在应答中标注规范版本。
版本号按照如下规则进行协商：
1） 如果服务器实现了所请求的版本号，服务器必须发送那个版本。
2a） 如果所请求的是服务器未知的版本，服务器必须发送低于请求版本号的最高版本。
2b） 如果客户端请求的版本低于服务器已知的任何版本，那么服务器必须发送它所知的最低版本。
16
3a） 如果客户理解不了由服务器发送的新版本，它可以停止与服务器交流，或是发送一个新的请求，新请求包含一个客户端能理解的但是低于服务器发送的版本（假设服务器已经响应了一个较低的版本）。
3b) 如果服务器发送了一个更高的版本（因为请求的版本低于服务器已知的任何版本），并且客户并不理解发送的版本。这时，客户可以发送一个新的请求，新请求中的版本高于服务器发送的版本。
这个过程一直重复，直到找到一个相互认可的版本。或者直到客户端确定不再或者不能和服务器交流。
例1：服务器理解1，2，4，5和8号版本，客户端理解1，3，4，6和7号版本。客户端请求7号版本。服务器发送5号版本。客户请求4号版本。服务器发送4号版本，这个版本客户能理解，这时交流成功结束。
例2：服务器理解4，5和8号版本，客户理解3号版本。客户请求3号版本，服务器发送4号版本。客户不懂那个版本或是任何更高的版本，因此交流失败并且客户停止与服务器的进行交流。
6.2 HTTP请求的一般规则
目前，OGC网络服务明确支持的唯一的分布式计算平台（DCP）就是是万维网本身，更明确地说是实现了超文本传递协议（HTTP）[IETF RFC 2616]的网络主机。因此，每个由服务实例支持的各操作的在线资源都是一个HTTP的统一资源定位器（URL）。对于每个操作来说，URL可以不同，也可以相同，这由服务提供者来决定。除了在其它情况下依赖于具体的实现以外，每个URL必须符合[IETF RFC 2616]中的描述（见3.2.2节，“HTTP URL”），惟有构成服务请求本身的参数是由OGC网络服务规范来规定。
HTTP支持两个请求方法：GET和POST。特定的OGC网络服务类型和服务实例可以只定义和实现其中的一种，或者二者全部定义和实现，在这两种情况中的在线资源URL是不同的。并且在线信息源定位的应用在每种模式中不同。一个基本的WMS规范仅仅定义用来调用操作的HTTP GET。（一个格式化的层描述符WMS[3] 为某些操作定义了HTTP POST）。
6.2.1 HTTP GET URL中的保留字符
URL规范[IETF RFC 2396]保留了一些特定的字符并赋予它们必要的意义，并要求在可能与其定义的用途相冲突时避免使用它们。该WMS规范明确的保留了这些字符中的几个，用于HTTP GET请求中的查询部分。当字符\和 \起表1所定义的作用时，它们必须是在URL中。当这些字符出现在其它的地方（例如，在参数值里），它们将按照[IETF RFC 2396]所定义的进行编码。
表1 HTTP GET查询中的保留字符
字符 ? & = / :
用 途 查询语句开始的分隔符 查询语句参数之间的分隔符 参数名字和参数值之间的分隔符 格式参数值中MIME类型子类型之间的分隔符 SRS参数值中命名空间和标识之间的分隔符 17
,
6.2.2 HTTP GET
清单型参数中单个值的分隔符 用于HTTP GET请求的在线资源URL事实上仅仅是一个URL前缀，为了建立一个有效的操作请求，在其后还添加了另外的参数。URL前缀被定义为一个不透明的字符串，它包括协议、主机名、端口号（可选）、路径、和一个问号“？”，还可以包括一个或几个用于具体服务器的参数并以“&”结束。该前缀唯一地标识了具体的服务实例，客户端在其后添加以名/值对形式出现的必要的请求参数，格式为“name=value&”。根据HTTP公共网关接口标准，最终的URL必须是有效的。该标准要求符号“？”处于查询参数序列之前，符号“&”界于参数之间。
URL前缀必须以“？“（在没有附加的适用与具体的服务器的参数的情况下）或者”&“结束。然而，在实践中，为了建立有效URL请求，客户端应该预备在添加按本规范定义的操作参数之前，增补一个必要的 “？”或“&”。
表2总结了操作请求URL的各个构件
表2 普通OGC网络服务请求
URL 构件 描 述 服务操作的URL前缀。[ ]表示可选择0个或1个事http://host[:port]/path?{name[=value]&} 件；{}表示0个或更多的事件。前缀完全取决于服务提供者。 由OGC网络服务定义的一个或更多的标准请求参name=value& 数的名称和数值对。对于每个操作，相应的的OWS规范都规定了请求中使用的必选和可选参数的实际列表。
6.2.3 HTTP POST
用于HTTP POST请求的在线资源URL是一个完整和有效的URL，客户端在POST请求中向它传输请求参数。在给操作请求建立一个有效的目标时，WMS不能要求在该URL上添加额外的参数。
对应于基本网络地图服务的HTTP POST操作请求还没有定义。
6.3 基本HTTP的响应规则
服务在接收到有效请求时，必须按照相应规范中的详细规定作出准确的应答。只有在进行版本协商情况下（如上面所述），服务器才可以给出不同的结果。
在接到一个无效要求情况下，服务必须发送一个6.4节里面描述的服务异常。
注：实际上，在WWW环境中，客户端也许接收一个有效的结果，也许什么也没有，也许是其他任何的结果。这是因为客户端自身可能会构造一个不完善的请求，并在OGC网络服务以外的其它地方意外地触发了一个回答，因为服务器自身也可能就不完善。
18
应答对象必须伴随一个适当的多用途网络邮件扩充协议（MIME）类型[IETF RFC 2045]。以下将论述操作应答和服务异常允许的类型。
应答对象应该尽可能地伴随一个适当的HTTP实体头。特别是，过期（Expire）和最后修改（Last-Modified）头为存储提供了重要的信息；客户端可以通过内容长度（Content-Length）了解数据传输什么时候完成，并为结果有效地分配空间。为了正确地解释结果，内容编码（Content-Encoding）或内容传输编码（Content-Transfer-Encoding）可能是必要的。
6.4 请求参数规则
6.4.1 参数顺序和大小写
参数名字将不可区分大小写，但是参数值必须会区分大小写。在这个文档里，为了印刷清晰，参数名都以大写字母出现。
请求中的参数可以按任何顺序指明。
OGC网络服务必须准备遇到不属于这个规范中的参数。就利用该规范产生出结果来说，OGC网络服务不可要求这些参数。
6.4.2 参数列表
由列表组成的参数（例如，在WMS GETMAP里的LAYERS和STYLES）必须用逗号“，”作为列表里各个项之间分隔符，不可要求另外用空格来分隔各个列表项。如果参数值包含了空格或是逗号，必须使用URL编码规则[IETF RFC 2396]进行换码。
在列表中的单个项可以为空，并用两个连续的逗号来表示（“，，”）。
6．5 公用请求参数
6.5.1 VERSION
版本参数详细指定了协议的版本号码。版本号格式和版本协商问题在6.1节中已经讲述了。
6.5.2 REQUEST
REQUEST参数指明了调用的是哪个服务操作。其值必须是OGC网络服务实例提供的操作的名称之一。
6.5.3 FORMAT
FORMAT参数指明了一个操作应答的输出格式。
一个OGC网络服务可以只提供该类操作所有已知格式的一个子集，但是服务器必须在Capabilities XML中公告它所支持的那些格式，并且必须接受对其已公告格式的服务请求。一个服务实例可以提供此前其它服务实例没有提供过的新的格式，但应该认识到这并不意味着要求客户端接受或处理这种未知的格式。如果一
19