SLD中文翻译
i. 序言
这篇文章解释了怎样把WMS扩展到适用于用户自定义的数据符号。你应该参照最新版的WMS说明书一起阅读。最新版的WMS说明书是在WMS1.1.1的基础上写成的。
介绍（Introduction）
地理数据视觉化的重要性不能被过分的强调。用来描绘数据（不管它是地理或制表用的数据）的技术是把原始信息转换成一个说明的或者支持决定的工具。从USGS的地形学地图系列到NOAA,从NIMA的航海图表到AAA的Triptik,细致的控制数据制图上的表达是对任何专业制图人员最基本的要求。
地理空间的用户（人或机器）可以参考这份文件来控制数据的视觉画像。现在的WMS说明书可以让信息的提供者通过为每一个数据组指定一组预先装置的视觉绘图来指明非常基本的设计选择。然而，尽管WMS现在可以为用户提供一系列的设计选项，但是它只能将每个样式的名字告诉给用户，而不能将图像在地图上的样子展示给你。更重要的是，用户不能自定义设计规则。人或机器要想去定义这些规则就需要一种用户和服务器都能理解的设计语言。定义这种语言（SLD）是这篇文章的重点，它可以用于描绘Web Map Servers, Web Feature Servers 和 Web Coverage Servers的输出。然而在很多情况下，用户需要了解一些存在于视讯遥控服务器上的数据，来以此作出一个合理的要求。因此在定义设计语言的基础上还要定义OGC services 新的执行指令。
描绘一个数据组有2种基本的方法。最简单的就是用同样的方法为所有的特征上色。例如，你可以想象WMS把a layer描绘成水道图，包括线条（河流和小溪）和多边形（湖泊，水塘，大海）。用户可能会告诉服务器把所有多边形里面都涂成浅蓝色，把多边形的边和所有的线条染成深蓝色。这种方法不需要了解数据的属性或特征类型，只需要一种语言去描述这些类型。这种方法在SLD文件的FeatureTypeStyle element里有所介绍。
另一个比较复杂的方法是根据一些属性，以不同的方式来描述数据的特征。例如，在一份道路数据组里，用3像素的红线表示高速路；2像素的黑线表示4车道的路；1像素的黑线表示2车道的路。要做到这点，用户需要知道数据组的什么属性代表道路类型。WMS已经有一个选项命令来执行这个要求，叫做DescribeLayer。这个命令返回了特征类型，并且WFS接口的DescribeFeatureType 命令可以告诉我们属性。
SLD执行规则
4．术语和定义
下面是出现在这篇文章里的术语和定义。
4．1
Operation- 一个物体被叫去执行一个改变或疑问的说明。
4．2
Interface- 被命名的命令组，描述一个整体的行为。
4．3
Service- 一个整体通过interface所提供的功能的不同的部分。
4．4
Service instance server- 一个Service实际的执行。
4．5
Client- 软件的组成部分，可以运用一个Server 里的一条执行命令。
4．6
Request- 一条命令被一个Client的执行。
4．7
Response- 从Server 返回到Client的命令的结果。
4．8
Map- 图像化表示的地理数据。
4．9
Capabilities XML- Service水平的描述命令的metadata和可被service instance利用的内容。
Web-Map-Server Integration
6.1 WMS1.1.1的简介
WMS1.1.1描述了以 “styled layer” 形式出现的地图的外观。“styled layer” 可以被看成一张有被符号化了的特征在上面的透明的纸。 “Map”是由许多个以特定顺序放在一起的“styled layer”组成的。它被说成是 “Z-ordered”. 用户可以通过加减“styled layer” 来定义更加复杂或简单的地图。
一个“styled layer” 代表了一种特定的 “layer” 和 “style” 的组合，在“style” 里“layer” 被符号化了。从概念上来说，“layer” 定义了一系列的特征，“style” 定义了这些特征是怎样被符号化了的。这个概念被体现在这样的事实里：一个 “layer” 可以以多种形式符号化。
在WMS的说明书里，对于一张地图的请求被译成一个HTTP-GET的请求，一张地图图像的样子是被“layer”和“style” 这两个参数来决定的。请看下面这个地图请求的例子（不完整的）（被分成多行显示只是为了方便演示）：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline
结果被显示在下面：这个可以被看成是3个‘styled layer’，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中线）
Rivers:CenterLine （河流：中线）
冒号用在这里是为了有助于讨论。河流styled layer位于道路styled layer下面，因为WMS使用的是“painter’s model”, 把LAYER列表里每个连续的layer画在前面一个的上面。因此，道路看起来是“跨越”了河流。同样的layer可以重复出现，但很少是以同一种style出现。
在表现直线物体的边界时，一个常用的制图技巧是先用一条彩色的加粗线画，然后再用一条比较细的浅色的线重新描一遍。这个被用在了下面道路绘制的例子里。
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Roads,Roads,Houses&
STYLES=Casing,CenterLine,Outline
根据上面所说的规则所绘制出来的图：被看成是3个styled layers，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中心线）
Roads:Casing （道路：外罩）
值得注意的是,WMS不能被询问指出哪些styled layers 可以被有意义的组合和怎样组合。然而，一个可变通的client会允许用户去探究各种不同的可能性。
WMS1.1.1 处理WMS“认识”的，以名字来识别的styles 和layers。鉴于这个原因，在后面的文章里我们把上面提到的这样的styles 和layers 叫做“被命名的styles”和“被命名的layers”。WMS只提供了一种定义styled layer的方法，这里的styled layer是一个被命名的style和一个被命名的layer的组合。
6．2 通用于WMS和SLD的HTTP Request规则
现今，唯一一个直接被OGC网络服务器支持的DCP是WWW,或者更确切一点说是执行HTTP的互联网主服务器。这样每一个被service instance所支持的执行命令的在线资料都是HTTP URL。每个执行命令的URL可以不同也可以相同，由网络服务公司来决定。每个URL应该遵照[IETF RFC 2616]中的规则，要不然就是依赖于执行；只有构成service request的参数被OGC网络服务规范所批准。
HTTP支持2种请求方式：GET和POST。其中之一或者两者都是被定义成某一个OGC网络服务类型并且由一个service instance提供，在线资源URL的用法在每个情况下是不同的。基本的WMS规则为了执行命令只定义HTTP GET（对于某些命令，SLD WMS[10]定义HTTP POST）。
6．3 SLD
6.1介绍了WMS规则下的地图的外观怎样用styled layers的顺序来决定。设计也可以被描述成用用户定义的XML来将地图的外观译成编码，叫做SLD。SLD格式将在7-11部分里被详细的讨论。简单地来说，一个SLD包括一个由一序列styled-layer定义组成的SLD XML元素。这些styled-layer定义可能会使用被命名的或者用户自定义的layer和style。下面是一个简单的SLD例子，对应于前面部分的第一个例子：
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
NamedLayer和NamedStyle对应于CGI 参数的LAYERS和STYLES，“painter’s model”同样被用于Z-ordering。用了用户自定义设计后SLD XML文件会变得更加复杂。WMS-1.2 styled-layer 程序和SLD-1.0.0格式是相一致的。
6．4 用SLD的WMS Request
有三种途径可以让一个client得益于SLD符号表示：
Client用HTTP GET和WMS交流，但是Request可以参考一个远程的SLD。
Client用HTTP GET的方法但是包括SLD XML文件以一个SLD_BODY CGI参数并列于GET Request（特征被恰当地编码）。
Client用HTTP POST和WMS交流，GetMap Request被编译在XML里，并且包括一个被嵌入的SLD。
理论上第三种方法优于其他2个，但是缺少卖主对于XML-POST GetMap-request 方法的支持。
第二种方法是介于第一和第三种之间的，使用第二种方法可能会由于过度长的URL而遇到问题。
需要值得注意的是无论在哪种情况下WMS都不会提前知道SLD的内容。Clients的范围很广。其中一些可能会允许用户在一些提前定义好的地图之间转换，每个地图都是由它自己提前定义的SLD来指明。其他的一些会允许用户互动地去描述他们心中地图的样子并且建立必要的SLD。上面所描述的几种方法都允许一个client申请来做，但是第一种需要client能够把SLD文件放置在一个易被WMS获取到的网络地址上。
再来看一下前面部分里那个不完整的GetMap request 的例子：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
在6.2里我们已经讨论了怎样把LAYERS和STYLES参数编译于SLD。Request用了一个SLD参数来提及SLD，这个参数取代了LAYERS和STYLES参数。SLD本身必须易被WMS获取到并且被一个URL指明。URL必须在被包含为一个参数值前被编码，就像layer和style名字已经被编码一样。假设这个准备好的SLD文件的URL是：http://myclientsite.com/mySLD.xml
那么地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
这个例子的SLD文件包含了6.2
StyledLayerDescriptor例子里的内容，并带有适当的标准XML题头标签。SLD文件还可以被并列包含在GET request里，就像在下面这个长的例子里：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD_BODY=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%
3F%3E%3C!DOCTYPE+StyledLayerDescriptor+SYSTEM+%22http%3A%2F%2Fsom
.site.com%2Fsld%2Fsld_072.xsd%22%3E%3CStyledLayerDescriptor+versi
on%3D%221.0.0%22%3E%3CNamedLayer%3E%3CName%3ERivers%3C%2FName%3E%
3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3ERoads%3C%2FName%3E
%3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle
%3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3EHouses%3C%2FName%
3E%3CNamedStyle%3E%3CName%3EOutline%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3C%2FStyledLayerDescriptor%3E
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
如果在7-bit ASCII范围以外的UTF-8字符被应用，除了格外长的URL以外将会有其他复杂的情况出现，因为HTTP被规定使用ISO Latin-1字符组。这种方法的优点是client不需要把SLD文件发布在网络上并且不能用POST的简单的Client可以使用这个方法。
另一种方法是用带有SLD作为WMS1.2+一个组成部分的HTTP POST去和WMS交流。用这种方法，上面的例子可以被翻译成下面这个编译为POST的XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE GetMap
SYSTEM "http://some.site.com/wms/GetMap.xsd">
<ogc:GetMap xmlns:ogc="http://www.opengis.net/ows"
xmlns:gml="http://www.opengis.net/gml"
env:encodingStyle="http://www.w3.org/2001/09/soap-encoding" version="1.2.0" service="WMS">
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
<BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coord>
<gml:X>-180.0</gml:X>
<gml:Y>-90.0</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>180.0</gml:X>
<gml:Y>90.0</gml:Y>
</gml:coord>
</BoundingBox>
<Output>
<Format>image/jpeg</Format>
<Transparent>false</Transparent>
<Size>
<Width>1024</Width>
<Height>512</Height>
</Size>
</Output>
<Exceptions>application/vnd.ogc.se+xml</Exceptions>
</ogc:GetMap>
虽然这个例子描述了一个WMS规则request怎样被转换成可以使用SLD，这个流程可以被用于任何一个有效的SLD。具体来说，它可以被用于一个包含了用户自定义符号表示的SLD。
为了使HTTP-GET更加实用，SLD也可以被用在2个不同模式下，取决于LAYERS参数是否出现在request里。如果没有，那么在SLD文件里的所有被指明的layers被赋予所有定义的styles，相当于XML-POST的用法。如果出现了，那么只有被那个参数指明的layer被赋予，SLD被作为“style图书馆”来使用。
当一个SLD被作为style图书馆来使用，STYLES CGI参数在GetMap request里被按通常的方法来翻译，除了对于style名字的处理被规范化了，为的是要使在SLD里被定义的styles优先于那些储存于地图服务器里的被命名的styles。用户自定义的SLD styles可以被赋予名字，并且它们可以被标注为一个layer预设的style。更具体地来说，如果一个叫做“CenterLine”的style被指定给一个layer并且一个有着同样名字的style在SLD里被定义给了相应的layer，那么这个SLD style定义被使用了。否则标准的建立在地图服务器内部的被命名的style流程被使用。如果一个预设style的使用被指定了并且一个style 被指定成SLD中相对应的layer 的预设选项，那么SLD中的预设layer 被使用了；否则地图服务器里标准的预设style被使用。
6．5 WMS和WFS/WCS
如果一个WMS是用用户自定义的符号使特征符号化，确认特征数据的来源是必要的。设计这个规则的目的是要允许各种各样的支持用户自定义符号表达的WMS的执行。例如WMS会使特征或保存在远程WFS/WCS里的coverage数据符号化，或者它只能符号化来自某个预设特征/coverage 仓库里的数据。
为了支持这个观点，叫做REMOTE_OWS_TYPE 和REMOTE_OWS_URL的选项参数被引入到HTTP-GET GetMap requests,用来指引WMS到一个远程的WFS,WCS或者其他的作为特征/coverage数据预设来源的OWS服务器。目前REMOTE_OWS_TYPE参数允许的数值是“WFS” 和 “WCS”,未来可能会有更多的被允许。REMOTE_OWS_URL参数交出服务器基础的URL来用。（以前，单一的一个WFS参数被提供给这个程序，但是那样局限性很大）。例如，一个WFS的URL是http://anothersite.com/WFS?那么前面部分里的地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=http%3A%2F%2Fanothersite.com%2FWFS%3
这个例子代表了WMS和WFS/WCS之间最简单的关系。但是还有很多其他有可能出现的关系。为了使讨论便于理解，这篇文章里引入了2个概念：‘component servers’和 ‘integrated servers’
Component servers: 这些服务器松散的连接在一起并且可以在任何组合下工作。例如，一个component WMS 可以将来自任何一个它被指引去的WFS/WCS的特征/coverage数据符号化。
Integrated servers: 这些服务器紧密地联合在一起并且只能在特定的配置下工作。例如，一个integrated WMS可能只能将来自和它联系在一起的WFS/WCS的特征/coverage数据符号化。一个服务器是component还是integrated告诉我们它是怎样被执行的。例如一个WMS是一个有效的OGC WMS使得它正确地支持WMS接口。这并没有告诉我们任何消息关于WMS是怎样被执行的。但是，一个可以将特征/coverage数据符号化的 ‘component’ WMS只能通过WFS/WCS接口和数据接触,这里确实说了关于执行的事。当然一个component WMS被指向什么类型的WFS/WCS(component 或integrated)是不重要的。值得注意的是将会有其他的WMS出现，他们可以用不是来自特征数据的资源制作地图。
有一批可以支持用户自定义符号的WMS。更加详细地说明这一系列的2端是怎样的是最好的解释，一个‘component’ WMS代表着一端，‘integrated’ WMS代表着另一端。
•• Component WMS
主要地它是一个可以把从一个或多个远程WFS/WCS收集来的特征数据符号化的绘图机器。 它主要有以下这些特征：
o 没有事先定义的‘被命名的 ’layers 或styles。
o 只是支持WMS 接口。
o 可以符号化来自任何WFS/WCS的特征数据。
o 支持用户自定义的layers 和styles。
基于XSLT技术的WMS是属于这个类型的。
• Integrated WMS
这个服务器代表了一个紧密联系的特征仓库和一个绘图机器。它主要有以下这些特征：
o 有事先定义的‘被命名的’layers和styles。
o 支持WMS接口，WFS接口的DescribeFeatureType request，WCS接口的GetCapabilities或者 可供选择的 DescribeCoverageLayer requests。
o 只能符号化来自它自身内部的特征仓库的数据。
o 只能支持用户自定义的styles用于事先定义的‘被命名的’layers。
不管是用component 还是integrated WMS，它必须可以讯问潜在的特征仓库（虽然只是在相对表面的水平）。这是因为用户自定义的符号化用到的概念在以前是不被WMS所需要的。例如，WMS1.1使得可以使用[Named]Layer和[Named]Style 这样的概念来接触WMS，而用不到特征类型这样的概念。相反地用户自定义符号化需要能够利用特征类型和特征类型属性来定义新的layers和styles。例如，一个新的layer可能会被定义成某一个特征类型的全部特征。这份规则就是要试着确保建立支持用户自定义符号化WMS的障碍越低越好。
通过WFS/WCS接口，潜在的特征/coverage仓库被询问了。对于一个component WMS来说这不是什么问题，因为特征/coverage仓库本身就是一个远程的WFS/WCS。对于一个integrated WMS来说，服务器必须既支持WMS接口也支持最小范围的WFS/WCS操作。它必须支持WFS的DescribeFeatureType request 或者WCS的GetCapabilities和可供选择的DescribeCoverageLayer。这体现了一个在request里被用名字来指明的特征/coverage 类型的属性。并且如果WMS支持用户自定义layers，那么它必须支持WFS GetCapabilities request。对于一个WFS 的返回，WFS支持所有特征类型的名字。合起来这2个WFS requests允许clients 收集所有建立用户自定义符号化所需要的信息。单独地WCS GetCapabilities request 对于一个WCS已经足够了。
指出在哪里WMS可以找到要被符号化的特征数据也是很重要的.下面是所用到的规则：
1． 如果SLD在UserLayer元素的RemoteOWS元素中指明一个WFS或者WCS,那么它将被使用（见Section 7）; 否则
2． 如果GetMap request包括CGI REMOTE_OWS_TYPE和REMOTE_OWS_URL参数那么那个远程服务器将被使用；否则
3． WMS将使用一个预设的WFS或者WCS。
这种方法不允许来自不同WFS/WCS的特征/coverage被包含在相同的styled layer里;然而，它却允许不同的styled layers建立在来自不同的WFS/WCS的特征数据上。前2个规则只能被用于那些可以被引导到远程WFS/WCS的WMS。在响应一个GetCapabilities request时，WMS将显示出这种能力（见6.7）。对于一个integrated WMS来说，预设的WFC/WCS就是那个和它结合在一起的。然而，没有人知道为什么一个component WMS不能够使一个预设的WFS/WCS被定义。
6．6 DescribeLayer Request
定义一个用户自定义的style 需要被符号化的特征的信息，或者至少知道它们的特征类型。因为用户自定义的styles可以被用于一个被命名的layer， 所以我们需要一个程序，通过它client可以得到一个被命名的layer的特征/coverage 类型信息。这是另一个将WMS概念下的layers/styles和WFS/WCS概念下的特征类型/coverage layer连接起来的例子。为了做到这点，WMS会选择性地支持DescribeLayer request。它适用于多个layers。体现在下面的例子中：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=DescribeLayer&
LAYERS=Rivers,Roads,Houses
例子中的DescribeLayer 是REQUEST 参数的一个新的选项。LAYERS 是一个参数，它允许被命名的layers被用名字来指出。它被认为是一个比使WMS Capabilities 文件更加超负荷的更好的方法。
它的返回将是一个描述被指出的命名的layers的XML文件。如果任何一个被命名的layer都没有出现，那么返回将是一个报告例外的XML文件。
对于每个被命名的layer,描述里应该指出它是否确实建立在特征数据上，如果是，它将显示WFS/WCS（通过一个URL前缀）和特征类型。值得注意的是它对那些不能以这种方式被描述的命名layer是完全有效地。我们可以再利用WFS程序来显示怎样在一个WFS里指出特征类型，那就是使用Query 元素。附件B给出了返回的DTD。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMS_DescribeLayerResponse
SYSTEM "http://some.site.com/sld/DSR.dtd" >
<WMS_DescribeLayerResponse version="1.1.0" >
<!-- 'Layer_A' comes from the wfs specified by
the prefix "http://www.mywfs.com/WFS?" and has features
of types 'Road_FT' and 'Route_FT' -->
<LayerDescription name="Layer_A"
wfs="http://www.mywfs.com/WFS?">
<Query typeName="Road_FT" />
<Query typeName="Route_FT" />
</LayerDescription>
<!-- 'Layer_B' cannot be described in terms of
a WFS and so has no wfs attribute and no contents -->
<LayerDescription name="Layer_B">
</LayerDescription>
</WMS_DescribeLayerResponse>
即使是一个integrated WMS也要给出一个WFS/WCS前缀，因为这样可以允许DescribeFeatureType requests 的运行。但是常见的是，也许一个WMS不支持UserLayers 却允许UserStyles 被用于命名的layers。在这种情况下，支持DescribeLayer request 是唯一的可相互操作的方法使得一个client能够指定用户自定义的符号化。
6．7 对于WMS GetCapabilities的加强
被WMS支持的GetCapabilities request 必须返回足够的信息，使client可以继续建立有效的requests。例如，一个WMS的capabilities包括哪个被命名的layers是WMS知道的。GetMap request 不是有效的如果它指向一个WMS不知道的被命名的layer。为了保证和不同的WMS有效地联系，包括上面所说的integrated/component WMS，capabilities 返回已经被加强了。具体地说，它可以描述下面这些信息：
1 WMS提供SLD支持么？
2 Client可以用HTTP POST(有一个嵌入的SLD)和/或HTTP GET(有一个SLD或SLD_BODY参数)去发表一个request么？
3 WMS支持用户自定义的layers么？
4 WMS支持用户自定义的styles么？
5 WMS可以被‘引导’到远程的OWS服务器么？（WMS支持在HTTP-GET requests里的REMOTE_OWS_SERVICE 和 REMOTE_OWS_URL参数么？支持在SLD里的RemoteOWS 么？）
6 WMS支持DescribeLayer request么？
一个WMS可能不支持被命名的layers/styles，体现在当描述它的capabilities时不会返回任何Layer元素。这个方法使得它能支持用户自定义的styles而不用支持用户自定义的layers。这种情况对于那些只描述远程特征的component WMS最为普遍。然而，这个对于WMS capabilities的描述没有明确地提到‘integrated’和 ‘component’类型。
前四条都代表了驾驭用户自定义符号化的能力的不同方面。1.1.0 WMS-Capabilities DTD引入了包含在Capability元素里面的UserDefinedSymbolization元素。这个新的元素包含了WMS支持用户自定义符号化能力的信息：
<!-- Elements indicating the level of support the WMS provides
for user-defined symbolization. By default there is no support.
-->
<!ELEMENT UserDefinedSymbolization (SupportedSLDVersion*)>
<!ATTLIST UserDefinedSymbolization
<!-- If the WMS supports a
StyledLayerDescriptor (SLD) then the
SLD parameter can be used in place of LAYERS and STYLES
parameters in a GetMap request. -->
SupportSLD (0 | 1) "0"
<!-- If the WMS supports UserLayers then users can define their
own layers in the SLD in addition to NamedLayers already known to
the WMS. -->
UserLayer (0 | 1) "0"
<!-- If the WMS supports UserStyles then users can define their
own styles in the SLD to be applied to previously specified
layers. -->
UserStyle (0 | 1) "0"
<!-- If the WMS supports remote WFS or WCS then a remote service
can be specified as the source of features to be symbolized. -->
RemoteWFS (0 | 1) "0"
RemoteWCS (0 | 1) "0">
<!-- Indication of what SLD version(s) are supported by a WMS -->
<!ELEMENT SupportedSLDVersion (#PCDATA)>
最后2条需要是可以被capabilities描绘地，用WMS capabilities的元素来处理，另外加上一个由DescribeLayer元素表现的新request 类型。这个Request元素可以被用来描述是否一个request可以被HTTP操作（作为一个DCP特定的instance）,如果是，这个request是否可以使用HTTP GET 和/或POST。
<!-- DescribeLayer interface: Presence of theDescribeLayer
element means this server can return a description of a specified
layer -->
<!ELEMENT DescribeLayer (Format+, DCPType+)>
现在被DescribeLayer request支持的唯一的格式是XML译码（在附件B里有解释）。对于WMS1.0.0到1.0.7，这种格式被叫做“WMS_XML”。对于WMS1.0.8以上，它是MIME 格式“application/vnd.ogc.wms_xml”.
Layers
7.1 SLD Root Element
一个SLD文件被定义为一个styled layers的序列。Root StyledLayerDescriptor被下面的XML-方案片断所定义：
<xs:element name="StyledLayerDescriptor">
<xs:complexType>
<xs:choice minOccurs="0"
maxOccurs="unbounded">
<xs:element ref="sld:NamedLayer"/>
<xs:element ref="sld:UserLayer"/>
</xs:choice>
<xs:attribute name="version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
这篇文章解释了怎样把WMS扩展到适用于用户自定义的数据符号。你应该参照最新版的WMS说明书一起阅读。最新版的WMS说明书是在WMS1.1.1的基础上写成的。
介绍（Introduction）
地理数据视觉化的重要性不能被过分的强调。用来描绘数据（不管它是地理或制表用的数据）的技术是把原始信息转换成一个说明的或者支持决定的工具。从USGS的地形学地图系列到NOAA,从NIMA的航海图表到AAA的Triptik,细致的控制数据制图上的表达是对任何专业制图人员最基本的要求。
地理空间的用户（人或机器）可以参考这份文件来控制数据的视觉画像。现在的WMS说明书可以让信息的提供者通过为每一个数据组指定一组预先装置的视觉绘图来指明非常基本的设计选择。然而，尽管WMS现在可以为用户提供一系列的设计选项，但是它只能将每个样式的名字告诉给用户，而不能将图像在地图上的样子展示给你。更重要的是，用户不能自定义设计规则。人或机器要想去定义这些规则就需要一种用户和服务器都能理解的设计语言。定义这种语言（SLD）是这篇文章的重点，它可以用于描绘Web Map Servers, Web Feature Servers 和 Web Coverage Servers的输出。然而在很多情况下，用户需要了解一些存在于视讯遥控服务器上的数据，来以此作出一个合理的要求。因此在定义设计语言的基础上还要定义OGC services 新的执行指令。
描绘一个数据组有2种基本的方法。最简单的就是用同样的方法为所有的特征上色。例如，你可以想象WMS把a layer描绘成水道图，包括线条（河流和小溪）和多边形（湖泊，水塘，大海）。用户可能会告诉服务器把所有多边形里面都涂成浅蓝色，把多边形的边和所有的线条染成深蓝色。这种方法不需要了解数据的属性或特征类型，只需要一种语言去描述这些类型。这种方法在SLD文件的FeatureTypeStyle element里有所介绍。
另一个比较复杂的方法是根据一些属性，以不同的方式来描述数据的特征。例如，在一份道路数据组里，用3像素的红线表示高速路；2像素的黑线表示4车道的路；1像素的黑线表示2车道的路。要做到这点，用户需要知道数据组的什么属性代表道路类型。WMS已经有一个选项命令来执行这个要求，叫做DescribeLayer。这个命令返回了特征类型，并且WFS接口的DescribeFeatureType 命令可以告诉我们属性。
SLD执行规则
4．术语和定义
下面是出现在这篇文章里的术语和定义。
4．1
Operation- 一个物体被叫去执行一个改变或疑问的说明。
4．2
Interface- 被命名的命令组，描述一个整体的行为。
4．3
Service- 一个整体通过interface所提供的功能的不同的部分。
4．4
Service instance server- 一个Service实际的执行。
4．5
Client- 软件的组成部分，可以运用一个Server 里的一条执行命令。
4．6
Request- 一条命令被一个Client的执行。
4．7
Response- 从Server 返回到Client的命令的结果。
4．8
Map- 图像化表示的地理数据。
4．9
Capabilities XML- Service水平的描述命令的metadata和可被service instance利用的内容。
Web-Map-Server Integration
6.1 WMS1.1.1的简介
WMS1.1.1描述了以 “styled layer” 形式出现的地图的外观。“styled layer” 可以被看成一张有被符号化了的特征在上面的透明的纸。 “Map”是由许多个以特定顺序放在一起的“styled layer”组成的。它被说成是 “Z-ordered”. 用户可以通过加减“styled layer” 来定义更加复杂或简单的地图。
一个“styled layer” 代表了一种特定的 “layer” 和 “style” 的组合，在“style” 里“layer” 被符号化了。从概念上来说，“layer” 定义了一系列的特征，“style” 定义了这些特征是怎样被符号化了的。这个概念被体现在这样的事实里：一个 “layer” 可以以多种形式符号化。
在WMS的说明书里，对于一张地图的请求被译成一个HTTP-GET的请求，一张地图图像的样子是被“layer”和“style” 这两个参数来决定的。请看下面这个地图请求的例子（不完整的）（被分成多行显示只是为了方便演示）：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline
结果被显示在下面：这个可以被看成是3个‘styled layer’，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中线）
Rivers:CenterLine （河流：中线）
冒号用在这里是为了有助于讨论。河流styled layer位于道路styled layer下面，因为WMS使用的是“painter’s model”, 把LAYER列表里每个连续的layer画在前面一个的上面。因此，道路看起来是“跨越”了河流。同样的layer可以重复出现，但很少是以同一种style出现。
在表现直线物体的边界时，一个常用的制图技巧是先用一条彩色的加粗线画，然后再用一条比较细的浅色的线重新描一遍。这个被用在了下面道路绘制的例子里。
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Roads,Roads,Houses&
STYLES=Casing,CenterLine,Outline
根据上面所说的规则所绘制出来的图：被看成是3个styled layers，他们是：
Houses:Outline （房屋：轮廓）
Roads:CenterLine （道路：中心线）
Roads:Casing （道路：外罩）
值得注意的是,WMS不能被询问指出哪些styled layers 可以被有意义的组合和怎样组合。然而，一个可变通的client会允许用户去探究各种不同的可能性。
WMS1.1.1 处理WMS“认识”的，以名字来识别的styles 和layers。鉴于这个原因，在后面的文章里我们把上面提到的这样的styles 和layers 叫做“被命名的styles”和“被命名的layers”。WMS只提供了一种定义styled layer的方法，这里的styled layer是一个被命名的style和一个被命名的layer的组合。
6．2 通用于WMS和SLD的HTTP Request规则
现今，唯一一个直接被OGC网络服务器支持的DCP是WWW,或者更确切一点说是执行HTTP的互联网主服务器。这样每一个被service instance所支持的执行命令的在线资料都是HTTP URL。每个执行命令的URL可以不同也可以相同，由网络服务公司来决定。每个URL应该遵照[IETF RFC 2616]中的规则，要不然就是依赖于执行；只有构成service request的参数被OGC网络服务规范所批准。
HTTP支持2种请求方式：GET和POST。其中之一或者两者都是被定义成某一个OGC网络服务类型并且由一个service instance提供，在线资源URL的用法在每个情况下是不同的。基本的WMS规则为了执行命令只定义HTTP GET（对于某些命令，SLD WMS[10]定义HTTP POST）。
6．3 SLD
6.1介绍了WMS规则下的地图的外观怎样用styled layers的顺序来决定。设计也可以被描述成用用户定义的XML来将地图的外观译成编码，叫做SLD。SLD格式将在7-11部分里被详细的讨论。简单地来说，一个SLD包括一个由一序列styled-layer定义组成的SLD XML元素。这些styled-layer定义可能会使用被命名的或者用户自定义的layer和style。下面是一个简单的SLD例子，对应于前面部分的第一个例子：
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
NamedLayer和NamedStyle对应于CGI 参数的LAYERS和STYLES，“painter’s model”同样被用于Z-ordering。用了用户自定义设计后SLD XML文件会变得更加复杂。WMS-1.2 styled-layer 程序和SLD-1.0.0格式是相一致的。
6．4 用SLD的WMS Request
有三种途径可以让一个client得益于SLD符号表示：
Client用HTTP GET和WMS交流，但是Request可以参考一个远程的SLD。
Client用HTTP GET的方法但是包括SLD XML文件以一个SLD_BODY CGI参数并列于GET Request（特征被恰当地编码）。
Client用HTTP POST和WMS交流，GetMap Request被编译在XML里，并且包括一个被嵌入的SLD。
理论上第三种方法优于其他2个，但是缺少卖主对于XML-POST GetMap-request 方法的支持。
第二种方法是介于第一和第三种之间的，使用第二种方法可能会由于过度长的URL而遇到问题。
需要值得注意的是无论在哪种情况下WMS都不会提前知道SLD的内容。Clients的范围很广。其中一些可能会允许用户在一些提前定义好的地图之间转换，每个地图都是由它自己提前定义的SLD来指明。其他的一些会允许用户互动地去描述他们心中地图的样子并且建立必要的SLD。上面所描述的几种方法都允许一个client申请来做，但是第一种需要client能够把SLD文件放置在一个易被WMS获取到的网络地址上。
再来看一下前面部分里那个不完整的GetMap request 的例子：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=GetMap&
BBOX=0.0,0.0,1.0,1.0&
LAYERS=Rivers,Roads,Houses&
STYLES=CenterLine,CenterLine,Outline&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
在6.2里我们已经讨论了怎样把LAYERS和STYLES参数编译于SLD。Request用了一个SLD参数来提及SLD，这个参数取代了LAYERS和STYLES参数。SLD本身必须易被WMS获取到并且被一个URL指明。URL必须在被包含为一个参数值前被编码，就像layer和style名字已经被编码一样。假设这个准备好的SLD文件的URL是：http://myclientsite.com/mySLD.xml
那么地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
这个例子的SLD文件包含了6.2
StyledLayerDescriptor例子里的内容，并带有适当的标准XML题头标签。SLD文件还可以被并列包含在GET request里，就像在下面这个长的例子里：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD_BODY=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%
3F%3E%3C!DOCTYPE+StyledLayerDescriptor+SYSTEM+%22http%3A%2F%2Fsom
.site.com%2Fsld%2Fsld_072.xsd%22%3E%3CStyledLayerDescriptor+versi
on%3D%221.0.0%22%3E%3CNamedLayer%3E%3CName%3ERivers%3C%2FName%3E%
3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3ERoads%3C%2FName%3E
%3CNamedStyle%3E%3CName%3ECenterLine%3C%2FName%3E%3C%2FNamedStyle
%3E%3C%2FNamedLayer%3E%3CNamedLayer%3E%3CName%3EHouses%3C%2FName%
3E%3CNamedStyle%3E%3CName%3EOutline%3C%2FName%3E%3C%2FNamedStyle%
3E%3C%2FNamedLayer%3E%3C%2FStyledLayerDescriptor%3E
WIDTH=400&
HEIGHT=400&
FORMAT=PNG
如果在7-bit ASCII范围以外的UTF-8字符被应用，除了格外长的URL以外将会有其他复杂的情况出现，因为HTTP被规定使用ISO Latin-1字符组。这种方法的优点是client不需要把SLD文件发布在网络上并且不能用POST的简单的Client可以使用这个方法。
另一种方法是用带有SLD作为WMS1.2+一个组成部分的HTTP POST去和WMS交流。用这种方法，上面的例子可以被翻译成下面这个编译为POST的XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE GetMap
SYSTEM "http://some.site.com/wms/GetMap.xsd">
<ogc:GetMap xmlns:ogc="http://www.opengis.net/ows"
xmlns:gml="http://www.opengis.net/gml"
env:encodingStyle="http://www.w3.org/2001/09/soap-encoding" version="1.2.0" service="WMS">
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>Rivers</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Roads</Name>
<NamedStyle>
<Name>CenterLine</Name>
</NamedStyle>
</NamedLayer>
<NamedLayer>
<Name>Houses</Name>
<NamedStyle>
<Name>Outline</Name>
</NamedStyle>
</NamedLayer>
</StyledLayerDescriptor>
<BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coord>
<gml:X>-180.0</gml:X>
<gml:Y>-90.0</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>180.0</gml:X>
<gml:Y>90.0</gml:Y>
</gml:coord>
</BoundingBox>
<Output>
<Format>image/jpeg</Format>
<Transparent>false</Transparent>
<Size>
<Width>1024</Width>
<Height>512</Height>
</Size>
</Output>
<Exceptions>application/vnd.ogc.se+xml</Exceptions>
</ogc:GetMap>
虽然这个例子描述了一个WMS规则request怎样被转换成可以使用SLD，这个流程可以被用于任何一个有效的SLD。具体来说，它可以被用于一个包含了用户自定义符号表示的SLD。
为了使HTTP-GET更加实用，SLD也可以被用在2个不同模式下，取决于LAYERS参数是否出现在request里。如果没有，那么在SLD文件里的所有被指明的layers被赋予所有定义的styles，相当于XML-POST的用法。如果出现了，那么只有被那个参数指明的layer被赋予，SLD被作为“style图书馆”来使用。
当一个SLD被作为style图书馆来使用，STYLES CGI参数在GetMap request里被按通常的方法来翻译，除了对于style名字的处理被规范化了，为的是要使在SLD里被定义的styles优先于那些储存于地图服务器里的被命名的styles。用户自定义的SLD styles可以被赋予名字，并且它们可以被标注为一个layer预设的style。更具体地来说，如果一个叫做“CenterLine”的style被指定给一个layer并且一个有着同样名字的style在SLD里被定义给了相应的layer，那么这个SLD style定义被使用了。否则标准的建立在地图服务器内部的被命名的style流程被使用。如果一个预设style的使用被指定了并且一个style 被指定成SLD中相对应的layer 的预设选项，那么SLD中的预设layer 被使用了；否则地图服务器里标准的预设style被使用。
6．5 WMS和WFS/WCS
如果一个WMS是用用户自定义的符号使特征符号化，确认特征数据的来源是必要的。设计这个规则的目的是要允许各种各样的支持用户自定义符号表达的WMS的执行。例如WMS会使特征或保存在远程WFS/WCS里的coverage数据符号化，或者它只能符号化来自某个预设特征/coverage 仓库里的数据。
为了支持这个观点，叫做REMOTE_OWS_TYPE 和REMOTE_OWS_URL的选项参数被引入到HTTP-GET GetMap requests,用来指引WMS到一个远程的WFS,WCS或者其他的作为特征/coverage数据预设来源的OWS服务器。目前REMOTE_OWS_TYPE参数允许的数值是“WFS” 和 “WCS”,未来可能会有更多的被允许。REMOTE_OWS_URL参数交出服务器基础的URL来用。（以前，单一的一个WFS参数被提供给这个程序，但是那样局限性很大）。例如，一个WFS的URL是http://anothersite.com/WFS?那么前面部分里的地图request将被转换成：
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=http%3A%2F%2Fanothersite.com%2FWFS%3
这个例子代表了WMS和WFS/WCS之间最简单的关系。但是还有很多其他有可能出现的关系。为了使讨论便于理解，这篇文章里引入了2个概念：‘component servers’和 ‘integrated servers’
Component servers: 这些服务器松散的连接在一起并且可以在任何组合下工作。例如，一个component WMS 可以将来自任何一个它被指引去的WFS/WCS的特征/coverage数据符号化。
Integrated servers: 这些服务器紧密地联合在一起并且只能在特定的配置下工作。例如，一个integrated WMS可能只能将来自和它联系在一起的WFS/WCS的特征/coverage数据符号化。一个服务器是component还是integrated告诉我们它是怎样被执行的。例如一个WMS是一个有效的OGC WMS使得它正确地支持WMS接口。这并没有告诉我们任何消息关于WMS是怎样被执行的。但是，一个可以将特征/coverage数据符号化的 ‘component’ WMS只能通过WFS/WCS接口和数据接触,这里确实说了关于执行的事。当然一个component WMS被指向什么类型的WFS/WCS(component 或integrated)是不重要的。值得注意的是将会有其他的WMS出现，他们可以用不是来自特征数据的资源制作地图。
有一批可以支持用户自定义符号的WMS。更加详细地说明这一系列的2端是怎样的是最好的解释，一个‘component’ WMS代表着一端，‘integrated’ WMS代表着另一端。
•• Component WMS
主要地它是一个可以把从一个或多个远程WFS/WCS收集来的特征数据符号化的绘图机器。 它主要有以下这些特征：
o 没有事先定义的‘被命名的 ’layers 或styles。
o 只是支持WMS 接口。
o 可以符号化来自任何WFS/WCS的特征数据。
o 支持用户自定义的layers 和styles。
基于XSLT技术的WMS是属于这个类型的。
• Integrated WMS
这个服务器代表了一个紧密联系的特征仓库和一个绘图机器。它主要有以下这些特征：
o 有事先定义的‘被命名的’layers和styles。
o 支持WMS接口，WFS接口的DescribeFeatureType request，WCS接口的GetCapabilities或者 可供选择的 DescribeCoverageLayer requests。
o 只能符号化来自它自身内部的特征仓库的数据。
o 只能支持用户自定义的styles用于事先定义的‘被命名的’layers。
不管是用component 还是integrated WMS，它必须可以讯问潜在的特征仓库（虽然只是在相对表面的水平）。这是因为用户自定义的符号化用到的概念在以前是不被WMS所需要的。例如，WMS1.1使得可以使用[Named]Layer和[Named]Style 这样的概念来接触WMS，而用不到特征类型这样的概念。相反地用户自定义符号化需要能够利用特征类型和特征类型属性来定义新的layers和styles。例如，一个新的layer可能会被定义成某一个特征类型的全部特征。这份规则就是要试着确保建立支持用户自定义符号化WMS的障碍越低越好。
通过WFS/WCS接口，潜在的特征/coverage仓库被询问了。对于一个component WMS来说这不是什么问题，因为特征/coverage仓库本身就是一个远程的WFS/WCS。对于一个integrated WMS来说，服务器必须既支持WMS接口也支持最小范围的WFS/WCS操作。它必须支持WFS的DescribeFeatureType request 或者WCS的GetCapabilities和可供选择的DescribeCoverageLayer。这体现了一个在request里被用名字来指明的特征/coverage 类型的属性。并且如果WMS支持用户自定义layers，那么它必须支持WFS GetCapabilities request。对于一个WFS 的返回，WFS支持所有特征类型的名字。合起来这2个WFS requests允许clients 收集所有建立用户自定义符号化所需要的信息。单独地WCS GetCapabilities request 对于一个WCS已经足够了。
指出在哪里WMS可以找到要被符号化的特征数据也是很重要的.下面是所用到的规则：
1． 如果SLD在UserLayer元素的RemoteOWS元素中指明一个WFS或者WCS,那么它将被使用（见Section 7）; 否则
2． 如果GetMap request包括CGI REMOTE_OWS_TYPE和REMOTE_OWS_URL参数那么那个远程服务器将被使用；否则
3． WMS将使用一个预设的WFS或者WCS。
这种方法不允许来自不同WFS/WCS的特征/coverage被包含在相同的styled layer里;然而，它却允许不同的styled layers建立在来自不同的WFS/WCS的特征数据上。前2个规则只能被用于那些可以被引导到远程WFS/WCS的WMS。在响应一个GetCapabilities request时，WMS将显示出这种能力（见6.7）。对于一个integrated WMS来说，预设的WFC/WCS就是那个和它结合在一起的。然而，没有人知道为什么一个component WMS不能够使一个预设的WFS/WCS被定义。
6．6 DescribeLayer Request
定义一个用户自定义的style 需要被符号化的特征的信息，或者至少知道它们的特征类型。因为用户自定义的styles可以被用于一个被命名的layer， 所以我们需要一个程序，通过它client可以得到一个被命名的layer的特征/coverage 类型信息。这是另一个将WMS概念下的layers/styles和WFS/WCS概念下的特征类型/coverage layer连接起来的例子。为了做到这点，WMS会选择性地支持DescribeLayer request。它适用于多个layers。体现在下面的例子中：
http://yourfavoritesite.com/WMS?
VERSION=1.1.0&
REQUEST=DescribeLayer&
LAYERS=Rivers,Roads,Houses
例子中的DescribeLayer 是REQUEST 参数的一个新的选项。LAYERS 是一个参数，它允许被命名的layers被用名字来指出。它被认为是一个比使WMS Capabilities 文件更加超负荷的更好的方法。
它的返回将是一个描述被指出的命名的layers的XML文件。如果任何一个被命名的layer都没有出现，那么返回将是一个报告例外的XML文件。
对于每个被命名的layer,描述里应该指出它是否确实建立在特征数据上，如果是，它将显示WFS/WCS（通过一个URL前缀）和特征类型。值得注意的是它对那些不能以这种方式被描述的命名layer是完全有效地。我们可以再利用WFS程序来显示怎样在一个WFS里指出特征类型，那就是使用Query 元素。附件B给出了返回的DTD。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMS_DescribeLayerResponse
SYSTEM "http://some.site.com/sld/DSR.dtd" >
<WMS_DescribeLayerResponse version="1.1.0" >
<!-- 'Layer_A' comes from the wfs specified by
the prefix "http://www.mywfs.com/WFS?" and has features
of types 'Road_FT' and 'Route_FT' -->
<LayerDescription name="Layer_A"
wfs="http://www.mywfs.com/WFS?">
<Query typeName="Road_FT" />
<Query typeName="Route_FT" />
</LayerDescription>
<!-- 'Layer_B' cannot be described in terms of
a WFS and so has no wfs attribute and no contents -->
<LayerDescription name="Layer_B">
</LayerDescription>
</WMS_DescribeLayerResponse>
即使是一个integrated WMS也要给出一个WFS/WCS前缀，因为这样可以允许DescribeFeatureType requests 的运行。但是常见的是，也许一个WMS不支持UserLayers 却允许UserStyles 被用于命名的layers。在这种情况下，支持DescribeLayer request 是唯一的可相互操作的方法使得一个client能够指定用户自定义的符号化。
6．7 对于WMS GetCapabilities的加强
被WMS支持的GetCapabilities request 必须返回足够的信息，使client可以继续建立有效的requests。例如，一个WMS的capabilities包括哪个被命名的layers是WMS知道的。GetMap request 不是有效的如果它指向一个WMS不知道的被命名的layer。为了保证和不同的WMS有效地联系，包括上面所说的integrated/component WMS，capabilities 返回已经被加强了。具体地说，它可以描述下面这些信息：
1 WMS提供SLD支持么？
2 Client可以用HTTP POST(有一个嵌入的SLD)和/或HTTP GET(有一个SLD或SLD_BODY参数)去发表一个request么？
3 WMS支持用户自定义的layers么？
4 WMS支持用户自定义的styles么？
5 WMS可以被‘引导’到远程的OWS服务器么？（WMS支持在HTTP-GET requests里的REMOTE_OWS_SERVICE 和 REMOTE_OWS_URL参数么？支持在SLD里的RemoteOWS 么？）
6 WMS支持DescribeLayer request么？
一个WMS可能不支持被命名的layers/styles，体现在当描述它的capabilities时不会返回任何Layer元素。这个方法使得它能支持用户自定义的styles而不用支持用户自定义的layers。这种情况对于那些只描述远程特征的component WMS最为普遍。然而，这个对于WMS capabilities的描述没有明确地提到‘integrated’和 ‘component’类型。
前四条都代表了驾驭用户自定义符号化的能力的不同方面。1.1.0 WMS-Capabilities DTD引入了包含在Capability元素里面的UserDefinedSymbolization元素。这个新的元素包含了WMS支持用户自定义符号化能力的信息：
<!-- Elements indicating the level of support the WMS provides
for user-defined symbolization. By default there is no support.
-->
<!ELEMENT UserDefinedSymbolization (SupportedSLDVersion*)>
<!ATTLIST UserDefinedSymbolization
<!-- If the WMS supports a
StyledLayerDescriptor (SLD) then the
SLD parameter can be used in place of LAYERS and STYLES
parameters in a GetMap request. -->
SupportSLD (0 | 1) "0"
<!-- If the WMS supports UserLayers then users can define their
own layers in the SLD in addition to NamedLayers already known to
the WMS. -->
UserLayer (0 | 1) "0"
<!-- If the WMS supports UserStyles then users can define their
own styles in the SLD to be applied to previously specified
layers. -->
UserStyle (0 | 1) "0"
<!-- If the WMS supports remote WFS or WCS then a remote service
can be specified as the source of features to be symbolized. -->
RemoteWFS (0 | 1) "0"
RemoteWCS (0 | 1) "0">
<!-- Indication of what SLD version(s) are supported by a WMS -->
<!ELEMENT SupportedSLDVersion (#PCDATA)>
最后2条需要是可以被capabilities描绘地，用WMS capabilities的元素来处理，另外加上一个由DescribeLayer元素表现的新request 类型。这个Request元素可以被用来描述是否一个request可以被HTTP操作（作为一个DCP特定的instance）,如果是，这个request是否可以使用HTTP GET 和/或POST。
<!-- DescribeLayer interface: Presence of theDescribeLayer
element means this server can return a description of a specified
layer -->
<!ELEMENT DescribeLayer (Format+, DCPType+)>
现在被DescribeLayer request支持的唯一的格式是XML译码（在附件B里有解释）。对于WMS1.0.0到1.0.7，这种格式被叫做“WMS_XML”。对于WMS1.0.8以上，它是MIME 格式“application/vnd.ogc.wms_xml”.
Layers
7.1 SLD Root Element
一个SLD文件被定义为一个styled layers的序列。Root StyledLayerDescriptor被下面的XML-方案片断所定义：
<xs:element name="StyledLayerDescriptor">
<xs:complexType>
<xs:choice minOccurs="0"
maxOccurs="unbounded">
<xs:element ref="sld:NamedLayer"/>
<xs:element ref="sld:UserLayer"/>
</xs:choice>
<xs:attribute name="version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>