第一个命名空间声明是rdf协定。 第二个声明是为cc/pp核心结构词汇命名，其中包括了"component"，"defaults"和其他cc/pp构架固有的属性。 第三个命名空间是为一个组件的cc/pp参数词汇命名。
注意：注意命名空间前缀是相当任意的：应用程序一定不可以假定前缀
rdf:指的是rdf词汇，或者ccpp:指的是内在的cc/pp词汇，等等。真正的关键是在于一个命名空间前缀所在的uri。
注意：虽然命名空间的名字是由uri引用来区分的，但是并没有要求那个uri所指定的地方存在一个可用的schema。在上面的例子中，uaprof命名空间名称是"
http://www.wapforum.org/uaprof/ccppschema-20000405#"，但是在那个uri上并没有任何schema。虽然在用于标识命名空间的url处有相应的schema是普遍首选的做法，但是这并不是必须的，cc/pp应用程序一定不可以假定那样的schema是存在的。
使用多样的组件参数词汇的是允许和鼓励的。不同的用户群体、不同的应用领域(wap forum，etsi，mexe，ietf conneg，等等)可能会定义他们的自己的 参数词汇表。这是个为了支持这些群体需要的重要机制。
下列各项命名空间是由cc/pp构架引入的：
http://www.w3.org/2002/11/08-ccpp-schema#
定义了cc/pp类声明和核心结构化参数的标准rdf schema(列于附录b.3)。http://www.w3.org/2002/11/08-ccpp-client#
用于描述简单的客户能力的非标准词汇的例子，特别是针对与打印和显示有关的客户(列于附录c)。
注意： 要检索这些schema，需要您的浏览器在发送请求时添加报头
accept:text/xml。没有添加这个接受报头，或使用报头accept:*/*，或者其他形式的报头的浏览器将会收到一个html网页，网页中会声明这个命名空间是为cc/pp schema预留的。
3. cc/pp结构
一个cc/pp客户设置文件的一般结构是一个二层的树结构：组件和属性，并为每个组件规定了一个全局定义的默认属性价的集合以供参考
3.1 组件
一个cc/pp设置文件包含一个或多个组件，每个组件包含一个或多个的属性。每个组件是由类型为ccpp:component(或其中的一些rdf子类)的资源来表现的，通过一个ccpp:component参数与客户设置文件资源关联的。这里，ccpp的命名空间是http：//www.w3.org/2002/11/08-ccpp-schema#。为了与uaprof兼容，用于限定component的命名空间可以是uaprof命名空间。
一个ccpp:component资源的对象可能含有一个指明它所描述的客户组件类型的rdf:type参数(或等同的rdf结构)。在图2-2b中的例子是一个明确指出了组件子类型的设置文件。然而，ccpp处理器必须也可以处理没有指明组件类型的设置文件。只要使用到的cc/pp属性全部具体指明组件类型，处理器就会有足够的信息来正确的解析他们。
如果一个cc/pp设置文件使用了任何可以出现在不同组件类型中的属性，则所有含有这个属性的组件，其类型必须要用用rdf:type参数来表明，或者使用等同的rdf。一个cc/pp处理器必须能够使用这个类型信息来消除使用了这样的属性的应用之间的歧义。
3.2 属性
cc/pp设置文件是用rdf[rdf]来构造的。rdf数据模型把cc/pp属性作为命名了的参数来表现，这个参数把一个主资源同相关的资源或rdf字面值联系起来。
为了描述客户能力和偏好，被描述的客户也是作为一种资源来看待，它的特性是通过从那个资源到相应对象值的标签了的边来描述的。标签了的边的值标明了所描述的客户特征(cc/pp属性)，相应对象值为特征值。
[client component resource] --attributename--> (attribute-value) |
cc/pp属性标签是用xml名字值(per xml规范标准[xml]，2.3节)来表现的，其中可能包括命名空间前缀(一个合乎条件的名字，per xml命名空间[xmlnamespaces]，第3节)。当同相应的命名空间或默认的命名空间声明组合时，每个标签必须映射到一个uri。因而，cc/pp属性名字就是uri，并使用xml命名空间语法来避免一些rdf表达式成为麻烦。
属性值可以是简单的或结构化的数据类型。
简单的数据类型将在4.1.1节中讨论。每个基本数据类型可能会支持一系列的测试，这些测试可以在决定不同资源变量与客户表现能力的适合程度时被使用；如，等同，兼容，小于，大于，等等。
对结构化数据类型的支持是通过使用可以把简单rdf字面值组合起来的特定rdf参数。这样的rdf参数的具体cc/pp语义将在4.1.2.节中讨论。
3.3 默认
客户设置文件的每个组件可能会指明一个独立的资源，这个资源会依次指明全部的从属的默认属性值。这个默认值的集合可以是一个用uri命名的单独的rdf文档，也可能是同客户设置文件在同一个文档中(虽然，在实践中，在同个文档中的默认或许并没有什么意义)。如果在默认值集合里的属性在客户设置文件的主体部分也有出现，这个非默认的值优先。这样做的是因为一个硬件供应商或系统提供商可能会供应与其它许多系统共同的默认值，而这些系统从源服务器可以很容易的访问到，同时这些硬件供应商或系统提供商可以使用客户设置文件来规定与这些共同的设置文件的不同之处。产品的所有者或系统操作员可以增加或改变选项，例如另增的内存，就可以增加新能力或者改变一些原始能力的值。
默认值是通过参数ccpp:defaults来引用的。这名字遵循rdf模型和语法规范标准[rdf]（附录c.1.）的命名格式推荐标准。然而，为了与较早版本的同uaprpf一起使用cc/pp兼容，cc/pp处理器应该可以辨认等同的参数名字ccpp:defaults（字母d大写）。这里，ccpp命名空间是http：//www.w3.org/2002/11/08-ccpp-schema#。为了与uaprof兼容，用于限定defaults或defaults的命名空间可能是uaprof 命名空间。
默认可以被编码为内联形式，或者是通过uri引用的单独的文档。默认不能既编码为内联形式又作为一个独立的文档。任何解释cc/pp的服务器都应该能够联合设置文件和任何外部引用的默认值从而可以正确的解释这个设置文件。一个在本身含有默认的设置文件在逻辑上与含有相同的非默认数据而通过引用外部含有默认值的文档是等同的。这里给出一个使用默认值的简单的设置文件的图表：
[ex:myprofile]
|
+--ccpp:component--> [ex:terminalhardware]
| |
| +--rdf:type-------> [ex:hardwareplatform]
| +--ccpp:defaults--> [ex:hwdefault]
| +--ex:displaywidth--> "640"
| +--ex:displayheight-> "400"
|
+--ccpp:component--> [ex:terminalsoftware]
| |
| +--rdf:type-------> [ex:softwareplatform]
| +--ccpp:defaults--> [ex:swdefault]
|
+--ccpp:component--> [ex:terminalbrowser]
|
------------
|
+--rdf:type-------> [ex:browserua]
+--ccpp:defaults--> [ex:uadefault]
+--ex:htmlversionssupported--> { "2.0", "3.2", "4.0" }
[ex:hwdefault]
|
+--rdf:type----> [ex:hardwareplatform]
+--ex:cpu------> "ppc"
+--ex:displaywidth--> "320"
+--ex:displayheight--> "200"
[ex:swdefault]
|
+--rdf:type----> [ex:softwareplatform]
+--ex:name-----> "epoc"
+--ex:version--> "2.0"
+--ex:vendor---> "symbian"
[ex:uadefault]
|
+--rdf:type----> [ex:browserua]
+--ex:name-----> "mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "symbian"
+--ex:htmlversionssupported--> { "3.2", "4.0" } |
如果被一个设置文件的ccpp:defaults引用的组件含有一个该设置文件组件中没有的属性，那么默认组件中的这个属性值直接应用到设置文件的组件中。例如，在图3-2a的设置文件应该解释为与图3-2b中的有相同的能力。
[ex:myprofile]
|
+--ccpp:component--> [ex:terminalhardware]
| |
| +--rdf:type-------> [ex:hardwareplatform]
| +--ex:displaywidth--> "640"
| +--ex:displayheight-> "400"
| +--ex:cpu------> "ppc"
|
+--ccpp:component--> [ex:terminalsoftware]
| |
| +--rdf:type-------> [ex:softwareplatform]
| +--ex:name-----> "epoc"
| +--ex:version--> "2.0"
| +--ex:vendor---> "symbian"
|
+--ccpp:component--> [ex:terminalbrowser]
|
------------
|
+--rdf:type-------> [ex:browserua]
+--ex:htmlversionssupported--> { "2.0", "3.2", "4.0" }
+--ex:name-----> "mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "symbian" |
