for raster displays, the width of the display in pixels. </rdfs:comment> </ccpp:attribute> <ccpp:attribute rdf:about='&ns-ccpp-client;pix-y'> <rdfs:label xml:lang="en">pixel display height</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;component'/> <rdfs:range rdf:resource='&ns-ccpp;integer'/> <rdfs:comment xml:lang="en"> for raster displays, the height of the display in pixels. </rdfs:comment> </ccpp:attribute> <ccpp:attribute rdf:about='&ns-ccpp-client;color'> <rdfs:label xml:lang="en">color display capabilities</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;component'/> <rdfs:range rdf:resource='&ns-ccpp;string'/> <rdfs:comment xml:lang="en"> for display or print devices, an indication of the color rendering capabilities: binary - indicates bi-level color (black-and-white, or similar). grey - indicates gray scale capability, capable of sufficient distinct levels for a monochrome photograph. limited - indicates a limited number of distinct colors, but not with sufficient control for displaying a color photograph (e.g. a pen plotter, high-light printer or limited display). mapped - indicates a palettized color display, with enough levels and control for coarse display of color photographs. full - indicates full color display capability. </rdfs:comment> </ccpp:attribute> </rdf:rdf>
附录d：关于创造词汇表的推荐
本附录为读者提供一定的信息。
cc/pp设计的基础是在需要时一个客户属性可以通过引入新的词汇来定义。
相似的，新的词汇项可以引入新的关系，虽然引入工作需要十分小心以保证他们的语义是充分的并且是一致定义的。应用中立的cc/pp处理器应该可以理解和操作cc/pp关系，而不需了解他们所参考的cc/pp属性，这是一个一般原则。
我们推荐rdf schema与辅助支持文档协同使用，来定义任何新的cc/pp词汇表。本节的其余部分假定是使用rdf schema来定义任何新的词汇表。上一个附录是这种途径的一个例子。
新的词汇是通过xml命名空间来引入的。他们与其他cc/pp词汇项的关系可以用新的rdf schema语句(它需要对附录c给出的cc/pp词汇表的核心rdf schema进行加强)来定义。
d.1 所有词汇项的基本格式
cc/pp使用的所有词汇项都是uris与可选择的段标识符，作为rdf参数弧标识符。不应该使用相对uri格式。不同目的的词汇项一般情况下是与不同的xml 命名空间相关联的。定义了一些共同的rdf基类，以便可感知schema的rdf处理器能更好地分析cc/pp设置文件，并将cc/pp设置文件元素同与设置文件出现在同一个rdf图表的任意资源生成的语句相分离。
作为cc/pp属性使用的所有属性都必须是ccpp:attribute的实体，而ccpp:attribute本身是rdf:property的子类。(定义cc/pp属性参数的schema应该把他们定义为ccpp:attribute的实体。这样，可感知schema的处理器就可以区别作为cc/pp设置文件一部分的参数，和可能是属性值的一部分参数。)
每个cc/pp属性与设置文件的一个组件相关联的(如，hardwareplatform，softwareplatform，等等)，并且是作为适当的组件资源的一个实体的参数而使用。所有这样的组件资源类型都是ccpp:component的子类。基于ccpp:component的新的类可以通过新类型的属性词汇而引入，但是在可行的情况下强烈推荐使用已有的ccpp:component类型。
注意：一个简单的cc/pp解释器并不需要schema可感知功能，它的实现也不需要能够了解任何属性或资源的rdf类，也不要求设置文件携带任何rdf类型信息。关羽类和schema可感知处理的讨论是与将来的一般用途rdf处理器的开发相关的，这种一般用途的rdf处理器可以处理可能混合在同一个文档中的cc/pp和其他的rdf词汇和schema。为了使这样的发展到成为可能，在cc/pp的设计中考虑到类和schema问题是十分重要的，即使简单的cc/pp处理器不需要这样的功能。
d.2 xml命名空间的用法
所有的cc/pp属性必须与一个完全可分解的命名空间标识符uri相关联。(相对uris，或需要通过上下文来确定其含义的uri，不应该使用。)
注意：一个cc/pp属性的命名空间uri也可能用于识别与这些属性有关的rdf或其他的schema。然而，这样的用法超出了本规范标准的范围。
举例地来说，新的cc/pp属性将与一个新的命名空间相关联，这个命名空间将用于区别可能的相同属性名称的局部部分的不同。例如，只要前缀a:和b:是与不同的命名空间uri相关联，a:foo和b:foo命名的就是不同的两个属性。
d.3 定义新属性的原则
d.3.1 如果可能，重用现有的词汇
在可能的情况下，重用现有的词汇可以利用先前的工作并且减少用不同的属性名来命名几乎相同的东西的机会。
注意使用不同的命名空间的名称可能被自由地混合在同一个设置文件中，因而需要提供一个另外的特性并不能成为创造一个新的词汇的理由。
d.3.2 属性值类型和解释
属性定义应该指出类型和对关联的值的解释。最终，是由生成和接收应用来协商该如何解释一个特定的属性值。
在可能的情况下，为了简化处理并与其他的构架相兼容，属性值应该是基于4.1节所描述的数据类型之一。
当属性是用于表达有关客户的一个量化指标，这个量的单位应该明确地与属性定义相关联。并没有一个分开的机制可以指明属性值的表达单位。
d.3.3 不依靠于其他属性值的解释
每个属性的意义必须分离于其他的属性而定义：没有属性可能有依赖其他属性值而改变的意义。如，一个称为页宽的属性必须使用相同的单位来表达：对于某些类的设备这个属性使用字符数目为单位，对于另外一些实用毫米为单位，其他的则使用英寸为单位，这是不能接受的。(注意，只有在其它一些属性也有定义的前提下才被解释的属性定义是允许的；这里的重要原则是新增的属性不可以使本来可以从已定义的属性中推断出的信息变成无效。)
属性可以用“层”来定义，所以简单的能力(如处理彩色相片图像的能力)可以用简单的属性来描述，使用额外的属性来提供更详细的或秘密的能力(如精确的颜色匹配能力)。
d.3.4 属性命名协定
属性是rdf参数。rdf模型和语法文档[rdf]的附录c中推荐使用针对rdf参数名称的"intercap"命名风格(以小写字母开头，第二个和所有后来的字的首字母大写，其中不可以有标点)。对于cc/pp属性名我们也推荐使用同样的风格，除了某些地方为了与其他的系统兼容一些其它的格式将被首选(如下面将描述一些与conneg兼容的打印和显示属性)。
使用在cc/pp设置文件中rdf类的名称更适宜以大写字母开头。
d.3.5 属性应该有特定的适用性
如果一个属性定义为有很广泛的适用性，当用户试图对一个设置文件的不同部分应用同一个属性，就可能出现问题。
一个广泛地定义的属性在应用于一个不同的环境中可能会受制于不同的隐私或安全方面的考虑。例如，在移动电话设备上的文本到语音转换的能力或许是一个有用的特性，但是在pc上的类似的特性就可能会成为一种个人残疾的象征。结合本不相关的文本到语音转换能力和pc平台就可能会泄漏一些隐私信息。
d.4 协议的交互
在某些情况下，cc/pp词汇和与其一同使用的特定协议之间可能会有重叠。如， 客户词汇charset和httpaccept-charset:报头。在某种意义上说，cc/pp的协议中立的本意使得这些不可避免，而我们也可以说是因为现有的协议的内容协商辅助机制太有限。
在设计词汇时，应该避免定义可能是特定协议行为一部分的特性；任何用于描述或有关于传送机制而非需要传送的内容的都应该被避免；如，支持对于http连接保持的特性的支持就不应该在cc/pp设置文件中指出，因为(a)它是一个针对协议的特性，并且(b)它并没有真正地帮助源服务器为客户选择适当的内容。
相似的，在为使用cc/pp定义协议绑定时，与已有的协商机制的交互就应该被考虑并且规定。这个问题的详细处理方式超出了本规范标准的范围。
附录e：对可应用的词汇表的评论
本附录为读者提供一定的信息。
这本节将介绍cc/pp属性词汇表所要描述的一些参数的可能来源。这并不是标准的，在这里介绍是为了给出一些概念，那些客户特性可能需要用cc/pp来转换。
e.1 ietf媒体特征注册(conneg)
ietf为媒体特性标签[rfc2506]定义了一个iana注册，并定义了一个语法[rfc2533]以便关系样式表达式使用这些来描述客户和服务器的媒体特征。也定义了一个小型的共同词汇表[rfc2534]，这个词汇表成为了cc/pp客户共用词汇表的基础。 ietf互联网传真工作组也创造了另外的注册来描述传真机的能力[rfc2531]。
rfc 2506[rfc2506]定义了三类媒体特征标签：
- ietf树：为简单名称的已注册的特性标签，这个简单名称是在ietf标准过程支持下而被定义和赋值的。
- 全局树：已注册的特性标签并且简单名称加上前缀'g.'。这些是由非ietf组织而定义的，但是已经在iana注册来保证这些名称的唯一性。
- 未注册：包含'u.'的特征标签，其后后缀着一个相对格式严格的uri。
未注册的特征标签可以去掉开头的'u.'取剩下的uri在cc/pp表达式中使用。
所有的媒体特征标签和值都可用cc/pp表达，但不是所有的cc/pp设置文件都可以表示为媒体特性标签和值。尤其是cc/pp文本值是区分大小写的而一些媒体特征值却不区分大小写。媒体特征值可以使用大小写标准化转换而映射到cc/pp文本值(如转换到小写字母)。
本版本的cc/pp并没有与ietf媒体特征构架匹配的机制，这些机制可以在cc/pp中使用来声明一些能力，如与固定值之间的比较(如'pix-x<=640')，以及复合出现的属性值(如'pix-x=640' and 'pix-y=480' or 'pix-x=800' and 'pix-y=600')。 在将来工作中可能会定义这样的机制。
e.2 wap uaprof
uaprof[uaprof]是一个wap论坛规范标准，它是为允许无线移动电话设备向数据服务器或其他网络组件声明其能力而设计的。
uaprof的设计已经是基于rdf。同样地，它的词汇元素使用的是与cc/pp一样的基本格式。
cc/pp模型沿袭了uaprof，每个用户代理参数是作为几个组件中的一个的附属而定义的，这些组件与用户代理设备的一个方面一一对应；如
- 硬件平台
- 软件平台
- wap特性
- 浏览器用户代理
- 网络特性
虽然cc/pp的rdf schema在类和参数用法上较uaprof更为规范，cc/pp设计还是向下兼容的。其目的是使有效的uaprof设置文件也会是有效的cc/pp设置文件；然而不是所有的cc/pp设置文件都必须是有效的uaprof设置文件。
e.3 tiff
tiff是由adobe系统开发并维护的光栅图象封装文件格式发展[tiff]。它也是互联网传真标准文件格式[rfc2301]的基础。
同有着多种编码和压缩格式的基于像素的图象数据一样，tiff支持不同种类的图象相关信息的选项。这些选项可能就是cc/pp属性的候选。许多与图像处理能力相关的tiff属性都作为互联网传真工作的一部分在conneg空间中定义为了标签[rfc2531]；这些最好是通过基于它们的conneg标签名的uri来参考。
e.4 wave
wave是一个音频数据的封装格式，是由microsoft(微软)开发并维护的[multimedia]。
有这样一个可以作为cc/pp属性使用的wave所支持的音频编解码器的注册[rfc2361]。
ietf声音消息(vpim/ivm)的工作正在进行中，它将可以创建能被cc/pp设置文件使用的ietf媒体特征注册标签，其中的机制与前边的e.1节中所描述的是一样的。
e.5 mpeg-4
mpeg-4一个视频数据封装格式，可能有与音频数据组合，它是由iso mpe工作组开发和维护的[mpeg]。e.6 mpeg-7
mpeg-7是描述与图象、视频、音频和其他的数据相关联的信息的一种元数据格式，现在正由iso mpeg工作组开发中[mpeg-7]。e.7 pwg
打印工作组定义了可应用于打印设备的属性和能力[pwg]。这项工作的一部分已经并入ietf互联网打印协议(ipp)[rfc2566]。e.8 salutation
salutation是针对通讯设备的一个协议和辨认schema，主要是在局域网环境中，是由salutation联盟开发和维护的[salutation]。设备能力辨认机制有可能包含许多可以作为cc/pp属性使用的项。附录f：cc/pp应用
本附录为读者提供一定的信息。
cc/pp是一个格式构架，设计使用在广泛的应用和操作环境的上下文中。本规范标准并没有定义如何在特定的协议或应用中使用cc/pp。
本附录着重指出其他一些应用开发者在设计时必须考虑到的问题。这些问题在用于转换cc/pp设置文件的可应用的协议中也可能会被涉及到。
为了更有效地使用cc/pp构架，对于更广泛环境的操作规则必须规定好：
