注意:'rdf:bag'构造并不要求其中包含的每一个值都是唯一的。但是一个集合不能含有重复的值，因而用于表现一个集合的'rdf:bag'的每个参数都必须有一个独特的值。
只有单一值的属性，和值为含有零个、一个或多个元素的集合的属性，二者是截然不同的：
[(client-resource)] +--(attributename)--> [<rdf:bag>] --rdf:_1--> (set-member-value) |
可以比较一下：上面值为包含一个元素的集合的属性，与下面则是单一值的属性。
[(client-resource)] +--(attributename)--> (attribute-value) |
4.1.2.2 值的顺序
一个顺序是由零个、一个或多个值组成，在某些方面上这些值的顺序是有意义的。
当客户的特点在某个方面需要排序分级时，顺序值十分有用；如，在某种优先权下排序的偏好列表。这个规范标准没有定义值排序的权。一个定义了cc/pp属性的顺序值的词汇表应该对排序的权也有定义。
一个顺序是由'rdf:seq'来表示的，其中的每个参数对应于集合中的每个成员，'rdf:_1'，'rdf:_2'，等等。这个构造在rdf模型和语法规范标准[rdf]的第3节中有描述。
[(client-resource)]
+--(attributename)--> [<rdf:seq>]
+--rdf:_1--> (sequence-value-1)
+--rdf:_2--> (sequence-value-2)
:
+--rdf:_n--> (sequence-value-n) |
只有单一值的属性，和值为含有零个、一个或多个元素的顺序的属性，二者是截然不同的：
[(client-resource)] +--(attributename)--> [<rdf:seq>] --rdf:_1--> (sequence-value) |
可以比较一下：上面是包含一个元素的顺序属性值，图4-6中是一个单一值。
4.2 属性标识符
cc/pp属性名都是uri的形式。任何cc/pp词汇都与一个xml命名空间相关联，这个命名空间将一个基uri同一个局域xml元素名(或xml属性名)组合到一起来产生一个对应于一个属性名的uri。如，这个命名空间uri：
http://www.w3.org/2002/11/08-ccpp-client#
和核心词汇名称：
type
组合二者生成出属性名uri参考：
http://www.w3.org/2002/11/08-ccpp-client#type
谁都可以定义和发布cc/pp词汇扩展(这里假设对一个xml命名空间的uri可以进行管理性控制或分配)。为了使这样的词汇有用，它必须可以被每个沟通实体同样地解释。因而，在有可能的情况下，鼓励使用已有的扩展词汇；如果这样不可行，则推荐发布含有对新cc/pp属性的详细介绍的新词汇定义。
许多词汇扩展可以从已有的应用和协议中提取；如wap uaprof，ietf媒体特性注册，等等。附录调查了一些可能的额外cc/pp词汇来源。
4.3 rdf词汇schema
属性名是使用rdf schema来定义，并同xml 命名空间关联的。
附录b中包含了需要在cc/pp设置文件使用的rdf schema描述术。附录c中有一个描述cc/pp词汇的schema例子。附录d包含了关于创造新的词汇的推荐事项。
一个cc/pp处理器并不需要具备可以理解和处理rdf schema定义的功能；它只需要可以理解cc/pp设置文件结构和使用到的词汇以便完成其工作。(可感知schema的处理器或许可以以不同的方式来处理cc/pp设置文件，或结合其他的rdf信息，但是这个问题超出了本规范标准的范围。)
5. 一致性
本节将介绍如何作出一个有效的声明，来说明产品符合本规范标准。这样的声明可以由任何个人作出(如，供应商对于他们自己的产品的声明，第三方对于那些产品的声明，新闻记者对于产品的声明，等等)。声明可以在任何地方发布(如在web上或产品文件中)。声明发出方只对他作出的声明负责。如果声明的对象(如软件)在声明发出之后有改变，声明发出方有责任更新声明。如果声明被发现并不是有效的，声明发出方有责任修改或回收这个声明。推荐声明发出方遵循最新的规范标准。
cc/pp产品有三个等级：
- 文档(如web资源)
- 生产者(如web客户)
- 消费者(如web服务器)
5.1 cc/pp文档一致性
文档可以作为通过url可访问的资源存在，也可以作为消息中的数据被传输。当一个文档符合下列各项标准，这个文档就是cc/pp一致文档。
