3.4 区分设置文件结构和属性
cc/pp使用命名空间来区分与结构相关的词汇(如ccpp:component)同与应用相关的词汇(如terminalhardware、显式)。
在这个例子中，我们将使用前坠为"prf:"的命名空间http://www.wapforum.org/profiles/uaprof/ccppschema-20010430#，来描述没有在cc/pp或rdf命名空间定义的参数：
<?xml version="1.0"?>
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
xmlns:prf="http://www.wapforum.org/profiles/uaprof/ccppschema-20010430#">
<rdf:description rdf:about="http://example.com/myprofile">
<ccpp:component>
<rdf:description rdf:about="http://example.com/terminalhardware">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/uaprof/ccppschema-20010430#hardwareplatform" />
<prf:cpu>ppc</prf:cpu>
<prf:screensize>320x200</prf:screensize>
</rdf:description>
</ccpp:component>
<ccpp:component>
<rdf:description rdf:about="http://example.com/terminalsoftware">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/uaprof/ccppschema-20010430#softwareplatform" />
<prf:osname>epoc</prf:osname>
<prf:osvendor>symbian</prf:osvendor>
<prf:osversion>2.0</prf:osversion>
</rdf:description>
</ccpp:component>
<ccpp:component>
<rdf:description rdf:about="http://example.com/browser">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/uaprof/ccppschema-20010430#browserua" />
<prf:browsername>mozilla</prf:browsername>
<prf:browserversion>5.0</prf:browserversion>
<prf:htmlversion>
<rdf:bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:bag>
</prf:htmlversion>
</rdf:description>
</ccpp:component>
</rdf:description>
</rdf:rdf> |
所有涉及到cc/pp总体结构的rdf资源都是定义在ccpp:命名空间里，并且与一些schema参数相关联，这样就可以使用一个可感知schema的处理器来区分这些资源和属性词汇或其他rdf声明。
3.5 rdf使用注意事项
本规范标准在每个例子中都是使用"rdf:about"来指明资源的uri。这是深思熟虑的选择，这可以保证这样的uris是被完全并且无二义性地指定。这个选择也不同于uaprof，他们使用"rdf:about"和"rdf:id"共同来产生作用。
cc/pp允许"rdf:id" 属性或"rdf:about" 属性。然而，"rdf:id"属性的值表现的是相对于文档的基uri的uri[rdffragment]。当文档被移动到web的另一个位置，"rdf:id" 属性值也会随之改变。当rdf是被包含在一个没有基uri的文档中，这个意义就是不明确的了，如被封装在一个消息内。rdf核心工作小组的工作草稿[rdfxml]建议rdf应该支持"xml：base" 属性。如果这个rdf的补充成为了推荐标准，那么就可以使用协同使用"rdf:id" 属性和"xml:base" 属性来取代"rdf:about" 属性。现在我们还是推荐cc/pp设置文件应该使用"rdf:about"，并且明确地指明资源的uri。
在设置文件中组件资源是相应的schema中标示的组件的实例，因而必须是ccpp:component的子类。由于rdf:type参数的值是与schema中的组件类型的名称相对应，通过rdf:type参数，组件资源可以被有效地识别。(有时这个类型标识必须是存在的：参见3.1节，组件。)
3.6 rdf图表成分
用于组成rdf图表的rdf声明不必要非在同一个文档中。对于cc/pp来说，rdf子图索引可以包含于已发送的设置文件中。这些rdf子图可以被单独传输，也可以从指明web资源资源中检索。
如果一个外部的子图表通过这种方式索引的，其效果等价于使用索引文档和被索引的文档来描述rdf三元组集合，也等价于创建一个新的文档来描述这些集合。(注意：实际上并不要求真正创建这样一个文档，可以认为那些rdf声明可以组成一个文档。)
这种组合多个rdf文档的机制假定被索引的文档的内容是可信任的，可以准确地向资源数据发送方表现其所具备的能力。因此，这样的组合只适用于描述由参数索引的资源，这些参数的预定解释中包含了可信任性的说明；即，ccpp:defaults。
4. 属性词汇表
4.1 属性数据
本节描述与cc/pp属性相关的值的基本数据类型和数据结构选项。
所有的cc/pp属性都应该在定义时被赋予一个值，这个值可以被视为后边将会讨论到的简单或者复杂数据类型的一种。支持属性值已被描述过的格式是推荐的；本规则说明并不禁止使用其他的有效的的rdf表单，但是不能保证这样使用可以被正确的解释。(参见1.1节和附录f。)
4.1.1 简单的cc/pp属性数据
所有简单的cc/pp属性值都是用rdf纯字面值来表现的。 在rdf/xml中，这些可能会作为字符序列出现在xml元素或作为xml属性出现。
一个属性的可接受的纯字面值可以被局限于一个与特定的应用数据类型相关的词法空间。本节将会介绍与一些简单cc/pp属性相关的特定数据类型。
