(CC/PP)结构和词汇 1.0

http://www.w3c.org.hk/TR/REC-CCPP-struct-vocab-20040115.html.cn
译文	复合能力/偏好设置文件：(CC/PP)结构和词汇 1.0
	(http://www.w3c.org.hk/TR/REC-CCPP-struct-vocab-20040115.html.cn)
原文	Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0
	(http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/)
注意	英文版是唯一的正式版，其URL已列于上面。 本文档为中文翻译版，译者虽力求精准，但其中可能仍有错误和不妥之处，欢迎指正，不胜感激！ 著作权声明：http://www.w3.org/Consortium/Legal/copyright-documents.html
译者	陈珊（Shan CHEN） [chenshan@ust.hk]
时间	初次定稿： 2005  年 1 月 13 日	最后修改： 2005 年 1 月 13 日

复合能力/偏好设置文件：(CC/PP)结构和词汇 1.0

2004年1月15日W3C推荐标准

本版本：

http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/

最新版本：

http://www.w3.org/TR/CCPP-struct-vocab/

前一版本：

http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/

编者：

Graham Klyne, GK@acm.org, Nine by Nine

Franklin Reynolds, franklin.reynolds@nokia.com, Nokia Research Center

Chris Woodrow, woodroc@metaphoria.net, Information Architects

Hidetaka Ohto, ohto@w3.org, W3C (through March 2002) / Panasonic

Johan Hjelm, Johan.hjelm@ericsson.com, Ericsson

Mark H. Butler, mark-h_butler@hp.com, Hewlett-Packard

Luu Tran, luu.tran@sun.com, Sun Microsystems

请参照本文档的勘误表，其中可能包括一些标准的订正。

这个规范的英文版本是唯一的标准版本。同时提供一些非标准的翻译。

Copyright © 2004  W3C^® (MIT, ERCIM, Keio)，版权所有。W3C 责任、商标、文档使用和软件许可规则均适用于本文挡。

---

摘要

本文档描述了CC/PP(复合能力/ 偏好设置文件)结构和词汇。CC/PP设置文件是对设备能力和使用者偏好的描述。这通常被称为设备的递送上下文，可以用来指导调整被送到那个设备的内容。

资源描述构架(RDF)被用来产生描述用户代理的能力和 偏好的设置文件。设置文件的结构将会被详细论述。主题包括：

• 客户能力和 偏好设置文件的结构，及
• 使用RDF类来区别一设置文件的不同元素，使可感知schema的RDF处理器可以处理嵌入在其他的 XML文档类型中的CC/PP设置文件。

CC/PP词汇是被用作表示特定的能力和 偏好的标识符(URI)，包括：

• CC/PP属性可能的值的类型，
• 一个描述该如引入新的词汇的附录，
• 另一个附录，其中给出了一个覆含了打印和显示能力的小客户词汇的例子，和
• 一个提供了对已存在的工作的调查的附录，从这些调查中可以获得新的词汇。

妙喆网

本文档的状态

本节描述了本文档在其出版时的状态。其他的文档可能会取代本文档。一个现有的W3C出版物的列表和本技术报告的最新版本可以http://www.w3.org/TR/ 上的W3C技术报告索引中获得。

本文档是W3C的推荐标准。它已经被W3C成员和其他与此相关的人员研究检查，并由W3C总监签署认可作为一个W3C推荐标准。它是一个稳定的文档，可以被用作其他文档标准参考的参考材料或者引证。

W3C发布推荐标准是为了引起各方面对此规范的注意，以促进其更广泛地配置。这些工作加强了Web的功能性和协同工作能力。连同实现报告一起，还提供一组 测试集。

这个文档是由W3C设备无关工作小组作为W3C交互活动领域中的设备无关活动的一部分创作的。 设备无关工作小组首页上将报告工作的后继状态。(只有成员链接)。

欢迎大家在讨论W3C有关可移动Web访问工作的公众论坛www-mobile@w3.org上，提供意见或向编者报告错误。存档文件可以在http://lists.w3.org/Archives/Public/www-mobile/获得。

与这个规范相关的专利的公告事项可在CC/PP工作小组的专利权公告网页上找到，与W3C政策是一致的。

目录

• 1. 介绍
  • 1.1 范围和标准元素
  • 1.2 本文档的结构
  • 1.3 文档协定
    • 1.3.1 术语
    • 1.3.2 RDF图表记号
• 2. CC/PP体系结构
  • 2.1 CC/PP设置文件结构
    • 2.1.1 设置文件组件
    • 2.1.2 组件属性
    • 2.1.3 默认
  • 2.2 可扩展性和命名空间
• 3. CC/PP结构
  • 3.1 组件
  • 3.2 属性
  • 3.3 默认
  • 3.4 区分设置文件结构与属性
  • 3.5 RDF使用注意事项
  • 3.6 RDF图表成分
• 4. 属性词汇表
  • 4.1 属性数据
    • 4.1.1 简单的CC/PP属性数据
      • 4.1.1.1 字符串
      • 4.1.1.2 整数
      • 4.1.1.3 有理数
    • 4.1.2 复杂的CC/PP属性数据
      • 4.1.2.1 值的集合
      • 4.1.2.2 值的序列
  • 4.2 属性标识符
  • 4.3 RDF词汇schema
• 5. 一致性
  • 5.1 CC/PP文档一致性
  • 5.2 CC/PP生产者一致性
  • 5.3 CC/PP消费者一致性
  • 5.4 一致性声明
    • 5.4.1 有效
    • 5.4.2 良构
• 6. 致谢
• 7. 参考资料
  • 7.1 标准参考
  • 7.2 信息参考
• 附录A：术语和缩写
  • A.1 术语
  • A.2 缩写
• 附录B：RDF结构schema
  • B.1 CC/PP类层次结构摘要
  • B.2 CC/PP参数摘要
    • 参数的结构( ccpp:Property的实例)
  • B.3 RDF Schema
    • CC/PP核心和类结构：
• 附录C：打印和显示的CC/PP属性词汇表
  • 客户属性参数(ccpp:Attribute的实体)
  • 客户词汇Schema
• 附录D：关于创造词汇表的推荐
  • D.1 所有词汇项的基本格式
  • D.2 XML命名空间的用法
  • D.3 定义新属性的原则
    • D.3.1 如果可能的, 重用现有的词汇
    • D.3.2 属性值类型和解释
    • D.3.3 不依赖于其他属性值的解释
    • D.3.4 属性命名协定
    • D.3.5 属性应该有特定的适用性
  • D.4 协议的交互
• 附录E：对可应用词汇表的评论
  • E.1 IETF媒体特征注册(CONNEG)
  • E.2 WAP UAProf
  • E.3 TIFF
  • E.4 WAVE
  • E.5 MPEG-4
  • E.6 MPEG-7
  • E.7 PWG
  • E.8 Salutation
• 附录F：CC/PP应用
  • F.1 HTTP中请求处理过程的概要
  • F.2 代理行为的协议假设
• 附录G：RDF兼容性
  • G.1 暗示的数据类型
  • G.2 显式的数据类型
• 附录W：校订历史

1. 介绍

本文档描述了CC/PP (复合能力/ 偏好设置文件)结构和词汇。一个CC/PP设置文件(profile)是对设备能力和使用者偏好的一种描述，可以用来指导对这个设备的内容适应。 这里profile不是指一个特殊规范的一个子集，如CSS Mobile profile，而是指设备之间交换的用于描述设备的能力的文档。

随着联接到Internet的设备的数量和种类的不断增长，对可以依照不同的设备能力而传送对应内容的需求也有相应的增加。一些有局限的技术，例如HTTP'accept'报头和HTML'alt='属性已经存在。作为内容适应和上下文相关化构架的一部分，一个一般用途的设置文件格式必需可以描述一个使用者代理人的能力和描述它的使用者的 偏好。CC/PP正是被设计作为如此的一个格式。

CC/PP是基于RDF，资源描述构架，由W3C所设计的一种一般用途的元数据描述语言。RDF在构架中提供了工具以实现词汇可扩展性，通过XML命名空间[XMLNAMESPACES]，和交互性。规范标准[RDF]描述了该如何使用XML编码RDF，另一个规范标准[RDFSCHEMA]使用RDF定义了RDF schema描述语言。RDF是被设计用来描述Web的元数据或者Web的机器可理解的 参数。由于用户代理设置文件是意在为用户代理和资源数据提供者之间交流的元数据，因而RDF自然成为了CC/PP构架的选择。关于RDF的介绍，参见[RDFPRIMER]。请留意[RDFPRIMER]文档中所描述的RDF规范标准是这个规范所基于的规范标准的更新版本。

CC/PP设置文件包含许多的CC/PP属性名和相关值，服务器可以使用这些来选择最适合的资源形式并将其传送到客户端。客户可以参考标准的设置文件来和一组用于补充或不同于标准设置文件的特色集来描述其能力，这些标准的设置文件可在起源服务器或其他资源数据发送方获得。一组CC/PP属性名，准许值和相关含义构成了CC/PP词汇表。

一些被包含在设置文件的数据可能是很敏感的，所以需要使用适当的信赖和安全机制来保护使用者的隐私。作为更广泛的应用程序的一部份，CC/PP不能够完全解决这些问题，而是应该协同适当的机制来共同使用。这个问题将在附录F(CC/PP应用)中提及。

一般来说不同的应用会使用不同的词汇表；如果要在CC/PP构架里面体现针对特定应用的参数，使用不同的词汇表将是必然的。要使不同的应用程序一起工作，一些常用的词汇或一种在不同的词汇之间转换的方法，又是十分必要的。(XML命名空间能保证不同的应用的名称之间不发生冲突，但是不能为不同应用程序之间交换数据提供一种通用的基础。)任何与CC/PP设置文件的结构有关的词汇必须遵循本规范标准。附录中介绍了一些可用来完善跨应用程序之间能力数据的交换工作的简单CC/PP属性词汇表，这些部分是基于一些较早的IETF工作。

CC/PP是设计成可以与先前WAP论坛发布的UAProf规范[UAPROF]兼容的。也就是说,我们尽量兼容已有的UAProf设置文件。

CC/PP与IETF媒体特征注册(CONNEG)[RFC2533]是兼容的，所有的媒体特色标签和值都可以用CC/PP表达。然而，不是所有的CC/PP设置文件都能被表示成媒体特色标签和值, CC/PP也不能表达属性之间的关系。

虽然到现在为止所给出的例子都集中于讨论设备能力，其实CC/PP也可以用来传达有关使用者偏好的信息。这些信息可以使Web服务器改善网站的可访问性，但同时在使用这些信息时应该非常谨慎。在Web内容可访问性指导[WAI]中可以找到对于网站可访问性的更详细的讨论。

1.1 范围和标准元素

CC/PP结构和词汇(本文档的其馀部分缩写为CC/PP)定义了一个客户设置文件数据格式，和一个结合应用及操作环境特特性的架构。它没有定义设置文件该如何被传送，它也没有指明一定要被产生或辨认哪些CC/PP属性。CC/PP是被设计为更广泛的应用构架的一部分来使用。同样地，指明哪些CC/PP元元素必须得到支持而哪些则可以忽略，是具体应用的工作。

在CC/PP的设计之中很少有内嵌的协议假定。虽然其本意是要实现最大程度上的协议无关，但是为了便于检索Web资源，协同HTTP使用还是成为了CC/PP设计的一项特殊的考虑。附录F包含了对CC/PP应用的一些进一步的讨论。

本文描述了CC/PP的许多特征。其中的一些特征构成了CC/PP的必要结构的一部份，这些特征的一致性是必需的(参见第5节)。其他特征的使用是推荐的或者可选的。对该如何引入新的词汇的指导也有被讨论，这部分是针对的对象是CC/PP应用设计人员而非CC/PP应用实现人员。

体系结构这一节并没有描述CC/PP的具体特征，而是简述了CC/PP设计的一般原则。它不是标准的，但是确实包含了一些信息，为了正确实现CC/PP必须认真理解这些信息。

CC/PP结构这节包括二个主要的方面：

• CC/PP设置文件组件: 对这些的支持是必需的。
• CC/PP设置文件默认: 对这些的支持是必需的。

CC/PP属性词汇这节描述了一些CC/PP常规的特征属性和他们的值。对这些简单属性值的描述格式的支持是推荐的——任何简单的CC/PP值的真实语法都是由相应的属性规范定义的；这些规范可以参考这里所提供的信息。对上述相关的结构化的CC/PP属性格式的支持是必需的。

虽然并没有要求对任何具体的词汇表都有支持，但是我们强烈建议应用软件设计者尽可能重用已有的词汇表。

虽然没有要求CC/PP应用支持附录中所描述的特征，但是任何的新定义的属性词汇一定要以附录B中的RDF schema所定义的RDF类库和属性为基础(新的CC/PP属性是ccpp:Attribute的实体，新的成份类是ccpp:Component的子类，等等)。

注意： 新的词汇需要以CC/PP schema为基础是为了方便那些可感知schema的应用软件可以将连同其他的RDF数据在内的CC/PP设置文件数据包含于其中。新的词汇术语以CC/PP schema为基础意味着，当多种来源的RDF数据组合使用在同一个CC/PP设置文件的时候，他们可以作为CC/PP设置文件的部份而被明确地区分。这个要求对单机CC/PP设置文件处理器并没有影响，但是这里使用RDF的真正价值在于其长期性，允许来源多样的数据(例如文档及与安全和隐私相关的数据)被更为通用的句柄联合组织在一起并处理。

1.2 本文档的结构

本节的剩余部分将会介绍本文档中将会使用到的术语、协定和记号。

第2节，CC/PP体系结构，概述了CC/PP设置文件的结构和XML命名空间的使用。

第3节，CC/PP结构，描述了CC/PP设置文件的结构，并且介绍了用于生成必要CC/PP元素的RDF元素。

第4节，属性词汇，描述了在一个CC/PP设置文件中该如何使用属性，而且介绍了用来描述特定特征的推荐的CC/PP元素的结构。

附录中包含了额外的支持材料。这些材料对于构造一个有效的CC/PP设置文件并不是必不可少的，但是这些材料为理解CC/PP，其与RDF的关系，或者是为具体的应用定义属性词汇提供了有用的附加背景信息。

1.3 文档协定

1.3.1 术语

参见本文挡附录A中的CC/PP术语和缩写。

“CC/PP属性”在这里用来表示出现在CC/PP设置文件中的客户(或其他的系统)的特定的能力或特性。术语“特征”表示客户能力或特性，这些可以是也可以不是CC/PP属性的基础。“属性名称”用来指一个用于识别CC/PP属性的RDF参数名称。

本文档中的关键字“一定”，“一定不”，“应该”，“不应该”，“可以”，“不可以”，“必需的”，“推荐的”和“可选择的”应该按照RFC2119[RFC2119]中的描述去理解。

1.3.2 RDF图表记号

RDF的潜在结构是一个有向标号图。为了计算机系统之间的交流，RDF使用了XML中的编序来表现这些图表。要人为论述这个XML记号法是相当庞大和困难的，因此这里为描述RDF图表结构使用了一个比较直观的记号法：

图 1-1：RDF图表标记

[Subject-resource] --propertyName--> [Object-resource] 表示图表中的一个标签为' propertyName'的边，这是一条从一个名为'Subject-resource'的RDF资源到另一个名为' Object-resource'的RDF资源的边。 [Subject-resource] --propertyName--> "Property value" 表示图表中的一个标签为' propertyName'的边，这是一条从一个名为'Subject-resource'的RDF资源到含有指示值的字面字符串。 [Subject-resource] --propertyName--> { "Val1", "Val2", ... } 这是一个值为含有指示值的 rdf:Bag资源参数的速记(参见 4.1.2.1节)。 [<Subject-type>] --propertyName--> [<Object-type>] 在方括号中的名称是用来表示一个指示类型的RDF资源(如含有 rdf:Type指示参数值)，而非表示一个资源的具体名称。这在表示通过一个 参数链接在一起的几个RDF类时非常有用。 [Subject-resource] --propertyName--> [Object-resource] | ------------------------------- | +--property1--> (val1) +--property2--> (val2) : (etc.) 参数弧可以使连锁式的，一个主资源可以引出几个弧。

这里是上面所描述的RDF图表结构的一些XML的例子：

图 1-2：RDF图表例子的XML

<?xml version="1.0"?> <!-- Any RDF graph is an RDF element --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.example.com/schema#"> <!-- [Subject-resource] -propertyName-> [Object-resource] --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName> <rdf:Description rdf:about="http://www.example.com/profile#Object-resource" /> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> [Object-resource] - (Alternative format) --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName rdf:resource="http://www.example.com/schema#Object-resource" /> </rdf:Description> <!-- [Subject-resource] -propertyName-> "property value" --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName>property value</propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... } --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName> <rdf:Description> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" /> <rdf:li>Val1</rdf:li> <rdf:li>Val1</rdf:li> <!-- ...etc... --> </rdf:Description> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... } - (Alternative format) --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName> <rdf:Bag> <rdf:li>Val1</rdf:li> <rdf:li>Val1</rdf:li> <!-- ...etc... --> </rdf:Bag> </propertyName> </rdf:Description> <!-- [<Subject-type>] -propertyName-> [<Object-type>] --> <rdf:Description> <rdf:type rdf:resource="http://www.example.com/schema#Subject-type" /> <propertyName> <rdf:Description> <rdf:type rdf:resource="http://www.example.com/schema#Object-type" /> </rdf:Description> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> [Object-resource] - | - +-property1-> (val1) - +-property2-> (val2) - : --> <rdf:Description rdf:about="http://www.example.com/profile#Subject-resource"> <propertyName> <rdf:Description rdf:about="http://www.example.com/profile#Object-resource" > <property1>val1</property1> <property2>val2</property2> <!-- ...etc... --> </rdf:Description> </propertyName> </rdf:Description> </rdf:RDF>

2. CC/PP体系结构

本节不是标准的，只是对CC/PP特性的一个概述。

2.1 CC/PP设置文件结构

通常一个CC/PP设置文件会被建造成一个2层的体系：

• 一个设置文件含有至少一个或多个组件(components)，和
• 每个组件含有至少一个或多个属性(attributes)。

2.1.1 设置文件组件

一个CC/PP设置文件树的最初分支描述了客户的主要组件。举个主要组件的例子：

• 软件赖以执行的硬件平台，
• 所有应用程序以之为基础的软件平台，或
• 一个单独的应用程序，例如浏览器。

一个对CC/PP树的根基的简单、图表化的表达将基于三个组件(TerminalHardware、TerminalSoftware和TerminalBrowser)：

图 2-1a：CC/PP设置文件组件

[example:MyProfile] | +--ccpp:component-->[example:TerminalHardware] +--ccpp:component-->[example:TerminalSoftware] +--ccpp:component-->[example:TerminalBrowser]

相应的XML：

图 2-1b：CC/PP设置文件的XML表述

<?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:example="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/profile#MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware"> <!-- TerminalHardware properties here --> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalSoftware"> <!-- TerminalSoftware properties here --> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalBrowser"> <!-- TerminalBrowser properties here --> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>

2.1.2 组件属性

一个CC/PP设置文件通过每个组件的诸多“CC/PP属性”来描述客户能力和偏好。

对每个组件的描述其实是CC/PP的一个子树，这个子树的分枝是与这个组件相关的能力和偏好。虽然RDF可以模型化广泛的数据结构，甚至包括任意的图表，但是设置文件属性值通常最好还是避免使用复杂的数据模型。通常情况下，几个CC/PP属性就可以描述一种能力，每个属性有一个简单的、原子值。当需要使用更复杂的值的时候，这些可以建造成RDF子图。这种复杂的属性值可以用来表示可选择的值；例如，浏览器可能可以支持多种HTML版本。这里是一个假设的设置文件：

图 2-2a：完整的CC/PP设置文件例子

[ex:MyProfile] | +--ccpp:component-->[ex:TerminalHardware] | | | +--rdf:type----> [ex:HardwarePlatform] | +--ex:displayWidth--> "320" | +--ex:displayHeight--> "200" | +--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:name-----> "Mozilla" +--ex:version--> "5.0" +--ex:vendor---> "Symbian" +--ex:htmlVersionsSupported--> [ ] | ---------------------------- | +--rdf:type---> [rdf:Bag] +--rdf:_1-----> "3.2" +--rdf:_2-----> "4.0"

与之相应的XML：

图 2-2b：完整的CC/PP设置文件XML例子

<?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:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/profile#MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ex:displayWidth>320</ex:displayWidth> <ex:displayHeight>200</ex:displayHeight> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalSoftware"> <rdf:type rdf:resource="http://www.example.com/schema#SoftwarePlatform" /> <ex:name>EPOC</ex:name> <ex:version>2.0</ex:version> <ex:vendor>Symbian</ex:vendor> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalBrowser"> <rdf:type rdf:resource="http://www.example.com/schema#BrowserUA" /> <ex:name>Mozilla</ex:name> <ex:version>5.0</ex:version> <ex:vendor>Symbian</ex:vendor> <ex:htmlVersionsSupported> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </ex:htmlVersionsSupported> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>

2.1.3 默认

组件的属性可以是跟上面的例子一样被直接地包括在组件内，也可以通过参考默认的设置文件来指定。这个默认的设置文件可以独立地存放在某处，通过其URI可以对它进行访问。

使用这样一个全局定义的默认设置文件与动态遗传的想法十分相似。它使一些重要的优化成为可能。作为一个独立的文档，它可以独立地存在于某处，可以被独立地缓冲。这在如蜂窝式网络的无线环境中有独特的作用，因为在这种情况下设置文件可能会相对很大，而客户线路却很慢并且昂贵。使用默认值，只有设置文件的一小部分需要通过无线网络传输。

在一个CC/PP设置文件中组件的默认值是通过组件中的ccpp:defaults弧来给出的，这个弧是从相关的组件到描述了这些默认值的组件。

图 2-3a：使用默认的CC/PP设置文件

[ex:MyProfile] | +--ccpp:component--> [ex:TerminalHardware] | | | +--rdf:type-------> [ex:HardwarePlatform] | +--ccpp:defaults--> [ex:HWDefault] | +--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:HWDefault] | +--rdf:type----> [ex:HardwarePlatform] +--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--> [ ] | +--rdf:type---> [rdf:Bag] +--rdf:_1-----> "3.2" +--rdf:_2-----> "4.0"

相应的XML:

图 2-3b：使用默认的CC/PP设置文件的XML表达

Device profile referencing defaults: <?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:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/profile#MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ccpp:defaults rdf:resource="http://www.example.com/hardwareProfile#HWDefault" /> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalSoftware"> <rdf:type rdf:resource="http://www.example.com/schema#SoftwarePlatform" /> <ccpp:defaults rdf:resource="http://www.example.com/softwareProfile#SWDefault" /> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalBrowser"> <rdf:type rdf:resource="http://www.example.com/schema#BrowserUA" /> <ccpp:defaults rdf:resource="http://www.example.com/terminalProfile#UADefault" /> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF> Defaults for HardwarePlatform: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/hardwareProfile#HWDefault"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ex:displayWidth>320</ex:displayWidth> <ex:displayHeight>200</ex:displayHeight> </rdf:Description> </rdf:RDF> Defaults for SoftwarePlatform: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/softwareProfile#SWDefault"> <rdf:type rdf:resource="http://www.example.com/schema#SoftwarePlatform" /> <ex:name>EPOC</ex:name> <ex:version>2.0</ex:version> <ex:vendor>Symbian</ex:vendor> </rdf:Description> </rdf:RDF> Defaults for BrowserUA: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/terminalProfile#UADefault"> <rdf:type rdf:resource="http://www.example.com/schema#BrowserUA" /> <ex:name>Mozilla</ex:name> <ex:version>5.0</ex:version> <ex:vendor>Symbian</ex:vendor> <ex:htmlVersionsSupported> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </ex:htmlVersionsSupported> </rdf:Description> </rdf:RDF>

如果一个给出的属性值直接被赋值给一个组件资源，但同时也在ccpp:defaults所引用的资源中出现，直接的赋值有优先：

图 2-4a：重载一个默认值

[ex:MyProfile] | +--ccpp:component--> [ex:TerminalHardware] | +--rdf:type--------> [ex:HardwarePlatform] +--ccpp:defaults---> [ex:HWDefault] +--ex:memoryMb-------> "32" [ex:HWDefault] | +--rdf:type----> [ex:HardwarePlatform] +--ex:displayWidth--> "320" +--ex:displayHeight--> "200" +--ex:memoryMb---> "16"

在这个例子中，默认组件指出有16MB的内存，但是这个值被直接赋值给设置文件组件的memoryMb参数重载掉了。因而，在这设置文件中memoryMb属性的值是32。

相应的XML：

图 2-4b：重载一个默认值的XML

Device profile referencing defaults: <?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:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/profile#MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ccpp:defaults rdf:resource="http://www.example.com/hardwareProfile#HWDefault" /> <ex:memoryMb>32</ex:memoryMb> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF> Defaults for HardwarePlatform: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://www.example.com/schema#"> <rdf:Description rdf:about="http://www.example.com/hardwareProfile#HWDefault"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ex:displayWidth>320</ex:displayWidth> <ex:displayHeight>200</ex:displayHeight> <ex:memoryMb>16</ex:memoryMb> </rdf:Description> </rdf:RDF>

一个默认参数所指出的资源可能出现在不同的文档中，所以对默认资源应该给出一个直接URI引用。在这种情况下，可以用默认资源标识符的URI部分(不包括碎片标识符部分)来检索包含默认资源描述的RDF文档。因而，如果一个默认资源被称为http://example.com/DeviceProfile#HardwarePlatform，URI http://example.com/DeviceProfile是用来检索RDF文档，这个文档中局部标识符为#HardwarePlatform的某一资源将被作为默认值使用。(这样的资源可以在目标文档中使用"about='http://example.com/DeviceProfile#HardwarePlatform'"或"ID='HardwarePlatform'"来定义。参见3.5.节)

注意： 个别应用可能允许使用相对URIs，不过这些应用需要明确指明如何能正确地找到相应的RDF文档。

2.2 可扩展性和命名空间

CC/PP主要是通过引入新的属性词汇来得到扩展的。

任何使用CC/PP的应用或操作环境都可能会定义它自己的词汇，但是如果定义的词汇能被更普遍的使用，那么就可以实现更广泛的互用性；例如，成像装置，或语音信息装置，或无线存取装置的标准可扩展词汇，等等。因此，本规范标准对可适用到打印和显示代理的特性定义了的一个小的核心词汇表，在可能的情况下强烈推荐使用这些词汇。这个核心词汇是基于IETF规范RFC2534[RFC2534]，作为一个例子来说明CC/PP属性词汇该被如何定义。另外一个这样的例子是WAP Forum UAPro规范标准[UAPROF]。

任何的CC/PP表达式可以使用不同的词汇表中的术语，因而并没有限定要再使用现有的词汇表中的术语而不能为同样信息定义一个新的名字。每个词汇都与一个XML命名空间对应，用于描写那些潜在的RDF和CC/PP结构的名称也是如此。

为了方便地关联名字表单与任意的URI，XML命名空间[XMLNAMESPACES]定义了相应的符号。虽然RDF图表语法并没有特别指定要使用命名空间，但是RDF图表的XML编序却有这样的指定。在如上所述使用图表符号表现RDF的时候，我们同样使用了命名空间前缀。

CC/PP构架使用XML命名空间机制来为RDF核心元素、CC/PP结构元素和CC/PP属性词汇创造用于识别的URI。考虑一下以下的关于命名空间声明的例子：

图 2-7：命名空间声明的例子

<?xml version="1.0"?> <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协定。 第二个声明是为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属性)，相应对象值为特征值。

图 3-1：描述一个客户属性的RDF语句

[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的服务器都应该能够联合设置文件和任何外部引用的默认值从而可以正确的解释这个设置文件。一个在本身含有默认的设置文件在逻辑上与含有相同的非默认数据而通过引用外部含有默认值的文档是等同的。这里给出一个使用默认值的简单的设置文件的图表：

图 3-2a：使用默认的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中的有相同的能力。

图 3-2b：使用了默认的CC/PP设置文件的解析过程

[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"

这里是相应的XML编序，默认资源描述内联在客户设置文件描述内部。注意这个例子对RDF元素使用了默认的命名空间，但是对RDF属性还是必须使用显式的命名空间前缀。

图 3-2c：使用内联默认的CC/PP设置文件的XML表达

<?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://example.com/Schema#"> <rdf:Description rdf:about="http://example.com/MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://example.com/TerminalHardware"> <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/> <ccpp:defaults> <rdf:Description rdf:about="http://example.com/HWDefault"> <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/> <prf:cpu>PPC</prf:cpu> <prf:displayWidth>320</prf:displayWidth> <prf:displayHeight>200</prf:displayHeight> </rdf:Description> </ccpp:defaults> <prf:displayHeight>640</prf:displayHeight> <prf:displayWidth>400</prf:displayWidth> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://example.com/TerminalSoftware"> <rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" /> <ccpp:defaults> <rdf:Description rdf:about="http://example.com/SWDefault"> <rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/> <prf:name>EPOC</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>2.0</prf:version> </rdf:Description> </ccpp:defaults> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://example.com/Browser"> <rdf:type rdf:resource="http://example.com/Schema#BrowserUA" /> <ccpp:defaults> <rdf:Description rdf:about="http://example.com/UADefault"> <rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/> <prf:name>Mozilla</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>5.0</prf:version> <prf:htmlVersionsSupported> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </prf:htmlVersionsSupported> </rdf:Description> </ccpp:defaults> <prf:htmlVersionsSupported> <rdf:Bag> <rdf:li>2.0</rdf:li> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </prf:htmlVersionsSupported> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>

内联的默认与外部引用的文档中的默认在逻辑上是等同的，外部文档会是提供默认值的一般途径。下面是同一个设置文件的XML编序，不过使用了外部定义的默认引用：

图 3-3：参考外部定义的默认的CC/PP设置文件的XML表达

<?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://example.com/Schema#"> <rdf:Description rdf:about="http://example.com/MyProfile"> <ccpp:component> <rdf:Description rdf:about="http://example.com/TerminalHardware"> <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/> <ccpp:defaults rdf:resource="http://example.com/HWDefault"/> <prf:displayWidth>640</prf:displayWidth> <prf:displayHeight>400</prf:displayHeight> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://example.com/TerminalSoftware"> <rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" /> <ccpp:defaults rdf:resource="http://example.com/SWDefault"/> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="http://example.com/Browser"> <rdf:type rdf:resource="http://example.com/Schema#BrowserUA" /> <ccpp:defaults rdf:resource="http://example.com/UADefault"/> <prf:htmlVersionsSupported> <rdf:Bag> <rdf:li>2.0</rdf:li> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </prf:htmlVersionsSupported> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>

每个外部的默认资源是通过URI定位的一个单独RDF文档。

注意：一个默认文档需使用一个<rdf:Description>元素作为根节点。<rdf:Description>是用一个值为URI的rdf:about来命名的。这个URI必须与相应的参考文档中的<ccpp:defaults>元素的XML属性rdf:resourcerdf：resource的值对应。(当默认组件是作为内联使用时，默认组件是不需要被识别，如上面的第一个例子。)在下面的默认文档的例子中，将使用外部默认值文档的URL。然而默认资源的URI不一定要是公文的URL，只要URI可以被独特地识别，同一个URI可以在源文档和外部默认文档中同时使用。处理软件可以通过其他一些途径来定位和检索含有默认资源的文档。

上个例子中用到的默认文档的例子如下：

图 3-4：外部HardwarePlatform默认值

Document: http://example.com/HWDefault <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:prf="http://example.com/Schema#"> <rdf:Description rdf:about="http://example.com/HWDefault"> <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/> <prf:cpu>PPC</prf:cpu> <prf:displayWidth>320</prf:displayWidth> <prf:displayHeight>200</prf:displayHeight> </rdf:Description> </rdf:RDF>

 

图 3-5：外部SoftwarePlatform默认值

Document: http://example.com/SWDefault <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:prf="http://example.com/Schema#"> <rdf:Description rdf:about="http://example.com/SWDefault"> <rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/> <prf:name>EPOC</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>2.0</prf:version> </rdf:Description> </rdf:RDF>

 

图 3-6：外部BrowseUA默认值

Document: http://example.com/UADefault <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:prf="http://example.com/Schema#"> <rdf:Description rdf:about="http://example.com/UADefault"> <rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/> <prf:name>Mozilla</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>5.0</prf:version> <prf:htmlVersionsSupported> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </prf:htmlVersionsSupported> </rdf:Description> </rdf:RDF>

3.4 区分设置文件结构和属性

CC/PP使用命名空间来区分与结构相关的词汇(如ccpp:component)同与应用相关的词汇(如TerminalHardware、显式)。

在这个例子中，我们将使用前坠为"prf:"的命名空间http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#，来描述没有在CC/PP或RDF命名空间定义的参数：

图 3-7：CC/PP设置文件的XML编序，含有命名空间

<?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属性相关的特定数据类型。

这里定义的基本CC/PP用法将使用到的值的进一步解释留给了处理应用程序。将来的CC/PP版本可能会引入一些额外的结构来实现客户设置文件和其它资源元数据的标准化匹配。为了适应这种发展，并且简化与IETF媒体特性描述的交互工作，推荐任何简单的属性值应该按照下面列出的数据类型来进行定义。

归根结底，所有属性值都是UCS (Unicode)字符序列。可以认为在特定的RDF数据编序中字符编码问题，是通过封装于内部的XML表达来定义的。

注意：属性比较超出了本文档的范围，同样对一个给定的属性值确定其相应的简单类型的详细的机制也是如此。我们假定应用知道如何处理任何需要进行操作的CC/PP属性。

在允许的情况下，正式的语法表达式使用在第6节XML规范[XML]中的符号。

4.1.1.1 字符串

CC/PP属性值的数据类型可以定义为区分大小写的文本字符串。

RDF字面值是局限于XML schema 数据类型"string"所定义的词法空间的[XMLSCHEMA-2]。任何'lang'标签都将被忽略。

通常，可以比较这些值是否相等或者不等。比较文本值时，每个字符都必须匹配才可以认为是相等的。

一些例子：

• 浏览器名："Mozilla"
• 浏览器版本："5.0"

4.1.1.2 整数

CC/PP属性值的数据类型可以定义为整数。

RDF字面值局限于XML schema数据类型"int"所定义的词汇空间内[XMLSCHEMA-2]。任何'lang'标签都将被忽略。

整数可以是正数、零或者负数。他们是由十进制阿拉伯数字组成的一列字符串，可以配上'+'或'-'的前缀。前导的0都将被忽略。数值是作为十进制数来解释。推荐具体的实现可以支持和生成值域为-2147483648到+2147483647，或-(2^31) 到(2^31-1)的整数值；如，绝对值可以表示为31-bit的无符号二进制数的整数。

图 4-2：整数的语法

Signed-integer ::= ( '+' | '-' )? Unsigned-integer Unsigned-integer ::= Digit (Digit)*

一些例子：

• 0
• 1
• +0768
• -256

  注意：推荐的值域选择是基于对广泛地应用在Web上的Java和其他编程语言的支持。

4.1.1.3 有理数

CC/PP属性值数据类型可以定义为有理数。

RDF字面值局限于下面定义的词汇空间内。任何'lang'标签都被忽略。

有理数表示成二个整数的比。这两个整数是由'/'分开，可以加上前缀标记符'+'或'-'。

推荐具体的实现可以支持和生成的有理数的分子(第一个数，在'/'之前)为0到2147483647 (2^31-1)的整数，分母(在'/'之后)的值域为1到 2147483647。

图 4-3：有理数的语法

Rational-number ::= Signed-integer ( '/' Unsigned-integer )?

如果分母被省略，可以认为分母值为'1'；可以作为整数对待。

一些例子：

• 1/2
• 768/1024
• -254/100
• +2000/65536

注意：上面描述的有理数schema在XML-Schema[XMLSCHEMA-0]可以被定义为：

图 4-4：有理数的可能的XML-Schema

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030728/"> <xs:simpleType name="rational"> <xs:annotation> <xs:documentation> The canonical lexical representation of any value will be the form of the value reduced to its lowest common denominator, and with '1' in the denominator if applicable. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="[-+]?[0-9]+(/0*[1-9][0-9]*)?"/> </xs:restriction> </xs:simpleType> </xs:schema>

注意上面模式提供了一个词法上的定义，但并不完善：它不接受任何空白符。并且，上面的简单的类型定义没有定义数的值空间；排序，相等性，和对算术操作的隐含支持也没有如一些这样的类型的用户所期望的被定义——处理器只认为这是字符串。由于这些缺点，使用这里定义的有理数可能会危害到互用性。(将来XML-Schema工作组可能会定义一个可使用的有理数数据类型。)

4.1.2 复杂的CC/PP属性数据

除了上面所描述的简单类型的值，CC/PP属性也可能有复杂类型的值，这种值是通过有着自己RDF参数和相关值资源的形式来表达的。通过这种方式来表现的具体数据类型有：

• 值的集合
• 值的顺序

设置文件中的一个组件中绝对不允许一个属性出现多。需要包含多个值的CC/PP属性应该使用集合或顺序。其他复杂的CC/PP属性值可以使用任意的RDF资源来表示。对于如何解释这样的值定义超出本规范标准的范围。

4.1.2.1 值的集合

集合是由零个、一个或多个不同的值组成的，这些值的顺序无关紧要。

集合值在表现特定类型的设备特征方面十分有用；如一个客户端支持的字体范围，一个浏览器所支持的HTML版本。

一个集合是由一个'rdf:Bag'来表示，集合里面的每一个成员都对应那个资源的一个参数，'rdf:_1'，'rdf:_2'等等。这个构造在RDF模型和语法规范标准[RDF]的第3节中也有描述。

图 4-4：CC/PP集合值的RDF表达

[(Client-resource)] +--(attributeName)--> [<rdf:Bag>] +--rdf:_1--> (set-member-value-1) +--rdf:_2--> (set-member-value-2) : +--rdf:_n--> (set-member-value-n)

注意:'rdf:Bag'构造并不要求其中包含的每一个值都是唯一的。但是一个集合不能含有重复的值，因而用于表现一个集合的'rdf:Bag'的每个参数都必须有一个独特的值。

只有单一值的属性，和值为含有零个、一个或多个元素的集合的属性，二者是截然不同的：

图 4-5：含有一个单一成员的集合值的属性

[(Client-resource)] +--(attributeName)--> [<rdf:Bag>] --rdf:_1--> (set-member-value)

可以比较一下：上面值为包含一个元素的集合的属性，与下面则是单一值的属性。

图 4-6：一个简单值的属性

[(Client-resource)] +--(attributeName)--> (attribute-value)

4.1.2.2 值的顺序

一个顺序是由零个、一个或多个值组成，在某些方面上这些值的顺序是有意义的。

当客户的特点在某个方面需要排序分级时，顺序值十分有用；如，在某种优先权下排序的偏好列表。这个规范标准没有定义值排序的权。一个定义了CC/PP属性的顺序值的词汇表应该对排序的权也有定义。

一个顺序是由'rdf:Seq'来表示的，其中的每个参数对应于集合中的每个成员，'rdf:_1'，'rdf:_2'，等等。这个构造在RDF模型和语法规范标准[RDF]的第3节中有描述。

图 4-7：CC/PP顺序值的RDF表达

[(Client-resource)] +--(attributeName)--> [<rdf:Seq>] +--rdf:_1--> (sequence-value-1) +--rdf:_2--> (sequence-value-2) : +--rdf:_n--> (sequence-value-n)

只有单一值的属性，和值为含有零个、一个或多个元素的顺序的属性，二者是截然不同的：

图 4-8：含有一个单一成员的顺序值的属性

[(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产品有三个等级：

1. 文档(如Web资源)
2. 生产者(如Web客户)
3. 消费者(如Web服务器)

5.1 CC/PP文档一致性

文档可以作为通过URL可访问的资源存在，也可以作为消息中的数据被传输。当一个文档符合下列各项标准，这个文档就是CC/PP一致文档。

1. 文档必须是有效的RDF，并且是基于一个或多个从附录B列出的RDF Schema中派生出的词汇表。参见第1节。
2. 文档必须使用有效的语法来进行命名空间声明。参看2.2节
3. 设置文件的每个组件必须包含一个或多个属性。参见2.1节。
4. 组件名可以是在rdf:about或rdf:ID属性中指明。参见3.1节。
5. 组件必须使用ccpp:componant参数来指明命名空间所在处，这个命名空间表明这个组件使用的是CC/PP命名空间或是UAProf命名空间的。参见3.1节。
6. 一个设置文件中组件名称、组件类型和属性名必须使用完全不同的URI来参考。参见第3节。
7. 如果一个组件类型是通过一个元素名称和一个rdf:type元素给出的，他们必须参考同一个URI。参见3.1节。
8. 默认参考必须是有效的URL。参见3.3节。
9. 默认可以写为ccpp:default或ccpp:Default。参见3.3节。
10. 默认必须使用ccpp:defaults或ccpp:Defaults参数来指明命名空间所在处，这个命名空间表明这个默认使用的是CC/PP命名空间或是UAProf命名空间的。参见3.3节。
11. 组件属性可以包含一个默认值同时又包含一个直接应用值，这个直接应用值优先。参见3.3节。
12. 组件可以包含内联默认。参见3.3节。
13. 组件一定不可以同时包含内联和参考的默认。参见3.3节。
14. 组件可以参考一个没有rdf:type的默认文档。参见3.3节。
15. 属性可以含有集合值(Bags)。参见4.1.2.1节。
16. 属性可以含有顺序值(Seq)。参见4.1.2.2节。
17. 属性可以包含字符串值。参见4.1.1.2节。
18. 属性可以包含整数值。参见4.1.1.3节。
19. 属性可以包含有理数值。参见4.1.1.4节。
20. 组件一定不可以包含有相同名字的多个属性。参见3.2节。
21. 相同名称的属性可以在不同的组件中。参见3.1节。
22. 设置文件可以为属性使用多个命名空间。参见2.2节。

5.2 CC/PP生产者一致性

当一个生产者所生成的任何CC/PP设置文件是CC/PP一致文档，这个生产者就是CC/PP一致生产者。

5.3 CC/PP消费者一致性

当一个消费者可以接受任何CC/PP一致文档，并且提取CC/PP信息，这个消费者就是CC/PP一致消费者。这里并没有要求可感知schema的处理，因此，CC/PP消费者是否支持附录B中的RDF Schema是可选择的(参见4.3节))。

CC/PP消费者一致可以分为两类：

1. 一致：CC/PP消费者可以声明为"CC/PP1.0一致消费者"，如果它可以接受任何有效的CC/PP设置文件并从中提取信息。
2. 确认：CC/PP消费者可声明为"CC/PP1.0一致确认消费者"，如果它是一致消费者并且可以拒绝所有无效的CC/PP设置文件。

注意：消费者可以实现为可配置的，在不同时间可以作为一致消费者或者一致确认消费者。

5.4 一致性声明

5.4.1 有效

如果一个一致声明是良构的，并且对于上面给出的可应用产品类别满足一定的一致性标准，这个一致声明是有效的。

5.4.2 良构

如果一致声明包含下列各项信息，就是良构的：

1. 声明日期
2. 产品类别(文档、生产者，或消费者)
3. 消费者分类(一致或确认一致)，如果适用的话
4. 文档的题目和标明日期的URI
5. 产品名字(ID)，包括版本、日期或其他可以独特地标识产品的标示符

6. 致谢

本文档是W3CCC/PP工作组许多次讨论的结晶，并最终由W3C设备无关工作组进行完善。下面是在本规范标准及前身准备过程工作的某些或者绝大部分阶段的CC/PP工作组成员。

• Mikael Nilsson, Ericsson Infotech
• Ulrich Kauschke, T-Mobil
• Ann Navarro, HTML Writers Guild
• Brad Topol, IBM
• Franklin Reynolds, Nokia
• Graham Klyne, Baltimore Technologies
• Noboru Iwayama, Fujitsu Laboratories LTD
• Takashi Nishigaya, Fujitsu Laboratories LTD
• Lalitha Surayanrayana, SBC Technology Resources
• Hidetaka Ohto, W3C (through March 2002) / Panasonic
• Simon McBride, DSTC Pty Ltd
• Varuni Witana, DSTC Pty Ltd
• Chris Woodrow, Information Architects
• Johan Hjelm, Ericsson
• Barry Briggs, Interleaf
• Gerd Hoelzing, SAP
• Ted Hardie, Equinix
• Serge Rigori, Sun
• Ted Wugofski, Phone.com
• Kynn Bartlett, HTML Writers Guild
• Sandeep Singhal, IBM
• Thorsten Kassing, T-Mobil
• Larry Masinter, Adobe

CC/PP工作组开发本规范标准的过程中，Yuichi Koike、Stuart Williams、Sean Palmer和Toni Penttinen提出了很多有用的修改和澄清的建议。还要对Aaron Swartz对最后草稿的细致有启发性审查工作表示特别的感谢。

在工作转交到设备无关工作组后，还要特别感谢David Ezell (XML Schema工作组)，Brian McBride (RDF核心工作组)，Masayasu Ishikawa (HTML工作组)，和Lynne Rosenthal (QA工作组)，在他们的帮助下规范标准才得以完成。

下面列出的设备无关工作组成员也为完成规范标准提供了协助：Stephane Boyera，Roger Gimson，Kazuhiro Kitagawa，Andreas Schade。

7. 参考资料

7.1. 标准参考

[XML]

Extensible Markup Language (XML) 1.0 (Second Edition); Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler; World Wide Web Consortium Recommendation 6 October 2000: http://www.w3.org/TR/2000/REC-xml-20001006 As amended by: XML 1.0 Second Edition Specification Errata; http://www.w3.org/XML/xml-V10-2e-errata, specifically http://www.w3.org/XML/xml-V10-2e-errata#E26.

[XMLNAMESPACES]

Namespaces in XML; Tim Bray, Dave Hollander, Andrew Layman; World Wide Web Consortium Recommendation 14 January 1999: http://www.w3.org/TR/1999/REC-xml-names-19990114/

[RDF]

Resource Description Framework (RDF) Model and Syntax Specification; Ora Lassila, Ralph Swick; World Wide Web Consortium Recommendation 22 February 1999: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/

[RDFSCHEMA]

Resource Description Framework (RDF) Schema Specification; Dan Brickley, R. V. Guha; World Wide Web Consortium Candidate Recommendation 27 March 2000: http://www.w3.org/TR/2000/CR-rdf-schema-20000327/

[RDFXML]

RDF/XML Syntax Specification; Dave Beckett; World Wide Web Consortium Working Draft: http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/

7.2. 信息参考

[RFC2506]

RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A. Mutz, T. Hardie; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2506.txt

[RFC2533]

RFC 2533: A Syntax for Describing Media Feature Sets; G. Klyne; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2533.txt

[CONNEGMATCH]

A revised media feature set matching algorithm; G. Klyne; Internet-Draft, work in progress: draft-klyne-conneg-feature-match-02.txt

[RFC2534]

RFC 2534: Media Features for Display, Print, and Fax; L. Masinter, D. Wing, A. Mutz, K. Holtman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2534.txt

[UAPROF]

WAP-174: UAProf User Agent Profiling Specification (1999) as amended by WAP-174_100 User Agent Profiling Specification Information Note (2001) Wireless Application Protocol Forum available at http://www.wapforum.org/what/technical_1_2.htm

Also see WAP-248-UAProf Version 20-Oct-2001 available at http://www.wapforum.org/what/technical.htm

[DATASTRUCTURE]

Notes on Data Structuring; C. A. R. Hoare; in Structured Programming, Academic Press, 1972. ISBN 0-12-2000556-2.

[XMLSCHEMA-0]

XML Schema. Part 0: Primer; David C. Fallside; World Wide Web Consortium Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

[XMLSCHEMA-1]

XML Schema. Part 1: Structures; Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn; World Wide Web Consortium Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

[XMLSCHEMA-2]

XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; World Wide Web Consortium Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

[SEMANTICTOOLBOX]

The Semantic Toolbox: Building Semantics on top of XML-RDF; Tim Berners-Lee; http://www.w3.org/DesignIssues/Toolbox.html

[RFC2531]

RFC 2531: Content Feature Schema for Internet Fax; G. Klyne, L. McIntyre; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2531.txt

[TIFF]

TIFF (Tagged Image File Format) 6.0 Specification; Adobe Systems Inc.; http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf

[RFC2301]

RFC 2301: File Format for Internet Fax; L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2301.txt

[MULTIMEDIA]

Multimedia Programming Interface and Data Specifications 1.0 (contains WAVE file format); IBM Corporation and Microsoft Corporation; <riffspec.txt>

[RFC2361]

RFC 2361: WAVE and AVI Codec Registries; E. Fleischman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2361.txt

[MPEG]

MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11 N3444 Rob Koenen Overview of the MPEG-4 Standard:

[PWG]

Printer Working Group; http://www.pwg.org

[RFC2566]

RFC 2566: Internet Printing Protocol/1.0: Model and Semantics; R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2566.txt

[SALUTATION]

Salutation Consortium Specification; http://www.salutation.org/

[RFC2119]

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels; S. Bradner; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2119.txt.

[MPEG-7]

MPEG-7 Overview (version 8.0), ISO/IEC JTC1/SC29/WG11 N3445 Jos矍. Mart쭥z (UPM-GTI, ES) Overview of the MPEG-7 Standard: http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm

[RFC2277]

RFC 2277: IETF Policy on Character Sets and Languages; H. Alvestrand; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2277.txt

[RFC2396]

RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax; T. Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2396.txt

[RFC2278]

RFC 2278: IANA Charset Registration Procedures; N. Freed, J. Postel; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2278.txt

[CCPPARCH]

Composite Capabilities/Preference Profiles: Requirements and Architecture; Mikael Nilsson, Johan Hjelm, Hidetaka Ohto; World Wide Web Consortium Working Draft 21 July 2000: http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/

[RFC2616]

RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1; R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2616.txt

[CONCEPTUAL]

Conceptual Structures: Information Processing in Mind and Machine; John F. Sowa; Addison Wesley, Reading MA, 1984.

[KNOWLEDGE]

Knowledge Representation; John F. Sowa; Brooks/Cole, 2000. ISBN: 0-534-94965-7

[RDFFRAGMENT]

Re: How to address RDF fragment; Ralph R Swick; Message to World Wide Web Consortium RDF-comments mailing list: http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html.

[CCPPEX]

CC/PP exchange protocol;Hidetaka Ohto, Johan Hjelm; World Wide Web Consortium Note 24 June 1999: http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624

[WAI]

Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason White, Gregg Vanderheiden; World Wide Web Consortium Working Draft 22 August 2002: http://www.w3.org/TR/2002/WD-WCAG20-20020822/

[RDFPRIMER]

RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium Working Draft 23 January 2003: http://www.w3.org/TR/2003/WD-rdf-primer-20030123/

附录A：术语和缩写

A.1 术语

本附录为读者提供一些必要信息。

属性，或CC/PP属性

CC/PP属性指的是用于描述设置文件数据元素，它作为一个RDF参数来表现的。每个CC/PP属性或是与一个或一列值相关联，或就是RDF资源。 注意： 这是不同于XML属性的；除了从上下文可以明显地看出其含义的地方，一般使用术语“CC/PP属性”来强调这个用法。

CC/PP处理器

CC/PP处理器把CC/PP文档从RDF格式转换到一些其他的格式。CC/PP处理器可以理解CC/PP语法和结构，包括"defults"(默认)，但它不能理解与CC/PP组件的属性相关的应用语义。

CC/PP资料档案库

一个用于持久存储用户代理设置文件或设置文件段的服务器，其中的数据可以被引用也可并入一个设置文件。CC/PP资料档案库一般情况下就是一个Web服务器，响应HTTP请求来提供CC/PP设置文件或设置文件段。

可缓冲

如果一个数据资源含有一个参数，可以允许服务器来决定缓冲的资源与一个类似资源的请求相匹配，那么这个数据资源就可以称作是“可缓冲的”

缓冲区

一个服务器或者代理用来存储为响应请求而检索或生成的数据资源的一个存储区域。收到一个对“已缓冲”数据资源的新请求后，这个服务器或代理就可以用已缓冲的内容而不需要再次检索或生成一个新的拷贝。

能力

发送方或接收方(通常是接收方)的一个属性，用来指明生成或处理一个特定类型的信息内容的能力。同时参看“CC/PP属性”。

客户

CC/PP设置文件的初始组合实体。

机密性

防止消息的内容非法泄露。

内容产生

在本规范标准中，“内容产生”是指生成与请求中的用户代理设置文件相应的内容，这是通过用户代理设置文件作为一个动态内容生成引擎的输入而实现的。文档的XSL和样式表按照请求的用户代理设置文件来调整该文档。

内容协商

在服务请求时，可以选择适当的表达方式的机制。任何响应(包括错误响应)中实体的表达方式是可协商的。

内容选择

在本规范标准中，“内容选择”是指通过匹配文档设置文件与请求中的用户设置文件，从一个选项或变量列表中选择一个适当的文档。

内容提供方

一个响应请求发出内容的服务器。

数据资源

一个通过网络传输的数据对象。数据资源可以存在于多样的表达形式中(如，多样的语言、数据格式、大小、分辨率)或在其他方面有所不同。

文档

在此规范标准中，“文档”是指为响应请求而给出的内容。使用这个定义，一个“文档”可以是较小的文档的汇集；反过来，这些小文档是较大文档的一部分。

文档设置文件

文档设置文件给出了一个方法来刻画适合给出的用户代理类别的特征。例如，一个设置文件可能包含对样式表、矢量图形和脚本的支持，而另外一个设置文件可能只适用于HTML 3.2中的标签。服务器可以使用文档设置文件在由不同的用户代理类别开发的文档变体中选择。当这样的变体没办法直接得到时，可以用文档设置文件来决定使用哪种转化形式。内容开发商可以通过使用文档设置文件来保证他们的网站可以按原意图被显示。

动态内容

响应请求而生成的内容。适用于受变化的环境因素影响的内容，如受时间影响的股票行情，或受地点影响的最近加油站点位置，等等。

特征

一个设备或实体的功能参数。

网关

可以跨界不同的网络协议的软件。本规范标准中，“网关”指的是跨接协议这样的功能。此功能可以存在于独立网关，或同时也存在于代理或源服务器中。

提示

对一个特定选择的建议或偏好。当这个选择是坚强推荐的，其使用也不是必需的。

机器可以理解的

用与数据意义相关的标签描述的数据(如，"author"标签描述了文档的作者)，这样可以允许数据被搜寻或组合而不只是显示。

命名空间

附加到XML标签以到保证其在XML元素中的唯一性的限定语。

协商内容

内容协商选定的消息内容。

协商元数据

通过内容协商在消息的发送方和接收方之间互换的信息，用来决定应该被传送的变量。

无差异内容

指的是一个被发送的内容的形式/格式不依赖于的接收方的能力和/或偏好。

源服务器

可以通过发送适当的内容或报错消息来响应一个请求的软件。源服务器可以通过WSP或HTTP来接受请求。源服务器上执行的应用程序发送按照获得的设置文件调整的与CC/PP一致的内容。本推荐标准中“源服务器”指的是内容生成能力，这可以存在于独立Web服务器，或者同时也存在于代理或网关。

偏好

发送方或接收方(通常是接收方)的一个属性，用于表示一个特定类型的消息内容的产生或处理优先于另外的消息内容的首选项。

隐私

防止个人信息的不经意或非法泄露。这样的信息可能是包含在一个消息内部，但是可能也是通信的模式中推测出；如，在通信时，已访问的资源类型，通信的对象，等等。

设置文件

描述一个具体设备或网络的能力的schema的实例。一个设置文件并不一定要有词汇表/schema中标明的所有属性。

代理

可以接收HTTP请求并使用HTTP将其转发给源服务器(有可能经由向上游代理)的软件。代理收到源服务器的响应并转发给发出请求的客户端。在它的转发功能中，代理可能会更改请求或响应或供应其他增值功能。在本规范标准中，“代理”指的是请求/响应转发这个功能，其可能存在于独立HTTP代理或同时也存在于网关或源服务器。

RDF资源

由RDF表达式描述的一个对象就是一种资源。RDF资源通常是由一个URI来识别。

接收方

一个接受消息的系统组件(设备或程序)。

Schema，RDF Schema

RDF Schema表示了组成一个不变更的RDF词汇表的那些资源。它是用来提供有关解释RDF数据模型中的语句的信息(例如组织和关系)。它不包括价与属性相关的值。

安全

描述了应用于数据通信的一组程序，以保障所传送的信息正是发送方和接受方想要的，而没有其他的方法。安全一般细分为完整性、授权、机密性和隐私。

发送方

一个发送消息的系统组件(设备或程序)。

用户

作为一个单一实体的个人或个人组织。用户可以进一步限定为使用设备发出请求并从服务器获得内容和/或资源。

用户代理

A为用户服务，在设备上运行的程序，例如浏览器。在不同时间用户可以使用不同的用户代理。

用户代理设置文件

适合设备能力、操作和网络环境和用户个人偏好的能力和偏好信息，可用于接收内容和/或资源。

变体

一个数据资源的几个可能的表达方式中的一个。

差异内容

指的是一个被发送的内容的形式/格式依赖于的接收方的能力和/或偏好。

词汇表

充分地描述CC/PP的属性的汇集。词汇表是于一个schema相关联的。

A.2 缩写

CC/PP	复合能力/偏好设置文件(Composite Capabilities/Preferences Profile)
CC/PPex	CC/PP交换协议(CC/PP Exchange Protocol)
CONNEG	IETF内容协商工作组(Content Negotiation Working Group in the IETF)
ER	实体关系(Entity-Relationship)
HTML	超文本标记语言(HyperText Markup Language)
HTTP	超文本传输协议(HyperText Transfer Protocol)
HTTPex	HTTP扩展框架(HTTP Extension Framework)
IANA	互联网地址分配委员会(Internet Assigned Numbers Authority)
IETF	Internet工程任务组(Internet Engineering Task Force)
IOTP	Internet开放贸易协议(Internet Open Trading Protocol)
LDAP	简易目录访问协议(Lightweight Directory Access Protocol)
OTA	Over The Air，如无线电网络
RDF	资源描述构架(Resource Description Framework)
RFC	征求意见，Internet标准(草案) (Request For Comments)
TBD	待定(To Be Determined)
TCP/IP	传输控制协议/网际协议(Transmission Control Protocol/Internet Protocol)
UAProf	WAP用户代理设置文件(WAP User Agent Profile)
W3C	万维网联盟(World Wide Web Consortium)
WAP	无线应用协议(Wireless Application Protocol)
WBXML	WAP二进制XML(WAP Binary XML)
WML	无线标记语言(Wireless Markup Language)
WSP	无线会话协议(Wireless Session Protocol)
XHTML	可扩展超文本标记语言(Extensible HyperText Markup Language)
XSL	可扩展样式表语言(Extensible Stylesheet Language)
XML	可扩展标记语言(Extensible Markup Language)

附录B：结构的RDF schema

本附录是标准的，但是CC/PP处理器的对此支持却是可选择的。

B.1 CC/PP类层次结构摘要

图 B-1：CC/PP类层次

rdfs:Resource ccpp:Profile {Profile deliverable to origin server} ccpp:Component rdfs:Literal ccpp:string {A text value of a CC/PP attribute} ccpp:integer {An integer value of a CC/PP attribute} ccpp:rational {A rational number CC/PP attribute value} rdf:Bag {A set value for a CC/PP attribute} rdf:Seq {A sequence value for a CC/PP attribute} rdf:Property ccpp:Property {A property applied to a CCPP:Resource} ccpp:Structure {A structural property in a CC/PP profile} ccpp:Attribute {A property denoting a CC/PP attribute}

B.2 CC/PP参数摘要

结构的参数(ccpp:Structure的实体)

图 B-2：CC/PP结构化参数

ccpp:component Domain=ccpp:Profile, Range=ccpp:Component ccpp:defaults Domain=ccpp:Component, Range=ccpp:Component

B.3 RDF Schema

CC/PP核心和类结构：

(Schema URI: http://www.w3.org/2002/11/08-ccpp-schema)

图 B-3：CC/PP类和核心参数的RDF schema

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp-schema#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;'> <!-- CC/PP class definitions --> <rdfs:Class rdf:about='&ns-ccpp;Profile'> <rdfs:label xml:lang="en">CC/PP Profile</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/> <rdfs:comment xml:lang="en"> This class is any complete profile that can be delivered to an origin server or other system that generates content for a client. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;Component'> <rdfs:label xml:lang="en">CC/PP profile component</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/> <rdfs:comment xml:lang="en"> A base class for any collection of CC/PP attribute values. A CC/PP client profile consists of one or more components, typically using a derived class that indicates the use of the component (e.g. prf:HardwarePlatform, prf:SoftwarePlatform). </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;string'> <rdfs:label xml:lang="en">Text value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment xml:lang="en"> This is the class of RDF Literals that represent CC/PP attribute string values. </rdfs:comment> <rdfs:seeAlso rdf:resource= 'http://www.w3.org/TR/xmlschema-2/#string'/> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;integer'> <rdfs:label xml:lang="en">Integer value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment xml:lang="en"> This is the class of RDF Literals that represent CC/PP attribute integer number values. </rdfs:comment> <rdfs:seeAlso rdf:resource= 'http://www.w3.org/TR/xmlschema-2/#integer'/> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;rational'> <rdfs:label xml:lang="en">Rational value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment xml:lang="en"> This is the class of RDF Literals that represent CC/PP attribute rational number values. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;Property'> <rdfs:label xml:lang="en">CC/PP Property</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdf;Property'/> <rdfs:comment xml:lang="en"> ccpp:Property is the super-class for ccpp:Structure and ccpp:Attribute. Therefore all property arcs that are not part of the core RDF namespace and constitute parts of a CC/PP profile are defined as subclasses of ccpp:Property. This allows schema-validating environments with language mixing to isolate the CC/PP elements of an RDF graph rooted in some given resource from other attributes of that resource. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;Structure'> <rdfs:label xml:lang="en">CC/PP structural property</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/> <rdfs:comment xml:lang="en"> All properties that are structural elements of a CC/PP profile are defined as instances of ccpp:Structure. This allows structural combining elements of a profile to be distinguished from attributes in a schema-aware environment. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:about='&ns-ccpp;Attribute'> <rdfs:label xml:lang="en">CC/PP Attribute</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/> <rdfs:comment xml:lang="en"> All properties that describe client capabilities or preferences in a CC/PP profile should be defined as instances of ccpp:Attribute. This allows structural combining elements of a profile to be distinguished from client features in a schema-validating environment. </rdfs:comment> </rdfs:Class> <!-- CC/PP structural property definitions --> <!-- Basic client profile description --> <ccpp:Structure rdf:about='&ns-ccpp;component'> <rdfs:label xml:lang="en">CC/PP component property</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Client-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment xml:lang="en"> Indicates a component of a top-level client profile. </rdfs:comment> </ccpp:Structure> <ccpp:Structure rdf:about='&ns-ccpp;defaults'> <rdfs:label xml:lang="en">CC/PP default properties</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment xml:lang="en"> This property indicates a Component that contains default properties for some other component. That is, any attributes that are not found in the subject resource but are present in the object resource may be incorporated from the object into the resulting CC/PP profile. </rdfs:comment> </ccpp:Structure> <ccpp:Structure rdf:about='&ns-ccpp;Defaults'> <rdfs:label xml:lang="en">CC/PP default properties</rdfs:label> <rdfs:subPropertyOf rdf:resource='&ns-ccpp;defaults'/> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment xml:lang="en"> Same as 'defaults'. Defined as sub-property for backwards compatibility with UAProf Use of this is deprecated: use 'defaults' instead. </rdfs:comment> </ccpp:Structure> </rdf:RDF>

附录C：打印和显示CC/PP属性词汇表

本附录是可选的，为读者提供一些信息。

对那些需要用到这样的特征的CC/PP应用的设计者，我们推荐使用本词汇表，而非定义新的术语。本词汇表是部分基于IETF媒体特征注册(CONNEG)工作组所做的工作[RFC2534]。

下面定义的客户属性名可能被用于识别与打印或显示可视化信息的客户设备相关的一些共同的特性，如文本或图表。他们是使用XML 命名空间局部部分描述的，并在在XML 命名空间标识符http://www.w3.org/2002/11/08-ccpp-client中有进一步限制。(这些属性可应用于客户的呈现能力，而非客户系统的具体内部组件或方面)

deviceIdentifier:

(值数据类型：字符串) 一个用来标识客户设备或用户代理类型的URI。

type:

(值数据类型：字符串集) 一个客户可接受的并可表现的MIME内容类型。理论上与HTTP 'accept：'包头相似，但是只指明一个单一的MIME内容类型，没有与内容类型参数联合。可以用一组内容类型字符串值来描述的多重接受的内容类型。当需要时，内容类型参数可以用另外的CC/PP属性表达。

schema:

(值数据类型：字符串集) 一个用来标识那识别客户可识别的schema的URI。这个schema可以是XML DTD [XML]，XML Schema [XMLSCHEMA-1]，RDF Schema [RDFSCHEMA] 或任何其他可由URI识别的适当文档结构。一个 Schema值对任何由Type属性标识的可接受的文档类型进行改进，但是其意义不能依赖于 Type的值。代表性地来说，这将被用于指明文档类型为 text/xml或 application/xml的特殊XML DTDs或schema。

charWidth:

(值数据类型：整数) 对于一个文本显示设备(type="text/*")，其字符显示宽度。对于差异比例字体显示，其显示单元数目。对于以东亚为代表的差异比例字体显示，一半宽度的显示单元数目(象形文字和其他全副字符占用两个显示单元)。对于同比例字符显示，N字数目表示的显示宽度(N字是排字的单位，相当于一个短破折号或字母'n'的宽度)。

charHeight:

(值数据类型：整数) 对于文本显示设备( type="text/*")，可显示的文本行数(如以字符来衡量的显示高度)。

charset:

(值数据类型：字符串集，per [RFC2278]) 对于文本处理设备，可处理的字符编码(内容类型为 "text/*"的每个MIME 'charset'参数值)。 注意：术语"charset" 是历史性的不当用词，并没有必要指出可以显示的字符清单，而只需要编码。虽然在某些情况下，编码可能暗指一个清单。

pix-x:

(值数据类型：整数) 对于图像显示设备( type="image/*")，其可显示的水平像素的个数。

pix-y:

(值数据类型：整数) 对于图像显示设备( type="image/*")，其可显示的垂直像素的个数。

color:

(值数据类型：字符串，per [RFC2534]) 对于文本和图像显示设备，指明其颜色能力(RFC 2534 [RFC2534]，可能的值为" binary"，" grey"，" limited"，" mapped"和" full")。 注意： color属性只是对颜色能力的一个很粗糙的表示，对一系列简单的应用已经足够，可以通过额外的可以更细节地描述能力的属性来完善。

客户属性参数(ccpp:Attribute的实体)

图 C-1：CC/PP客户词汇参数

ccpp-client:deviceIdentifier Domain=ccpp:Component, Range=ccpp:string ccpp-client:type Domain=ccpp:Component, Range=rdf:Bag ccpp-client:schema Domain=ccpp:Component, Range=ccpp:string ccpp-client:charWidth Domain=ccpp:Component, Range=ccpp:integer ccpp-client:charHeight Domain=ccpp:Component, Range=ccpp:integer ccpp-client:charset Domain=ccpp:Component, Range=rdf:Bag ccpp-client:pix-x Domain=ccpp:Component, Range=ccpp:integer ccpp-client:pix-y Domain=ccpp:Component, Range=ccpp:integer ccpp-client:color Domain=ccpp:Component, Range=ccpp:string

客户词汇Schema

(Schema URI: http://www.w3.org/2002/11/08-ccpp-client)

图 C-2：客户词汇的RDF schema

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp-schema#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-ccpp-client#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;' xmlns:ccpp-client = '&ns-ccpp-client;'> <!-- CC/PP attribute property definitions --> <!-- These properties represent some common vocabulary that is --> <!-- available for use by applications that need to indicate --> <!-- the common features indicated by these attributes. They --> <!-- serve as an example of how a new attribute vocabulary can --> <!-- be defined for use in a CC/PP profile. --> <ccpp:Attribute rdf:about='&ns-ccpp-client;deviceIdentifier'> <rdfs:label xml:lang="en">Client device identifier</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;string'/> <rdfs:comment xml:lang="en"> A URI that identifies the type of client device or user agent. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;type'> <rdfs:label xml:lang="en">MIME content type</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-rdf;Bag'/> <rdfs:comment xml:lang="en"> A string containing a MIME content-type, or a set of such strings, indicating the MIME content-types that can be handled. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;schema'> <rdfs:label xml:lang="en">Schema identifier</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;string'/> <rdfs:comment xml:lang="en"> A URI that identifies a language or DTD that is recognized by the client, or a set of such URIs. Specific values of this attribute may be applicable to certain MIME content types. For example, a URI that is associated with a resource containing an XML DTD will generally be applicable only with text/xml or application/xml content types. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;charWidth'> <rdfs:label xml:lang="en">Character display width</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;integer'/> <rdfs:comment xml:lang="en"> For character displays, the number of characters that can be rendered across the display. For displays using a proportional font, this is the display width in typographical 'em's. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;charHeight'> <rdfs:label xml:lang="en">Character display height</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;integer'/> <rdfs:comment xml:lang="en"> For character displays, the number of rows of characters that can be displayed. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;charset'> <rdfs:label xml:lang="en">Character set encoding</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-rdf;Bag'/> <rdfs:comment xml:lang="en"> For character displays, the MIME 'charset' values that can be handled. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:about='&ns-ccpp-client;pix-x'> <rdfs:label xml:lang="en">Pixel display width</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 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。

现在有一个为IANA注册创建命名空间的方案。就是创建一个机制以允许IANA注册特征标签直接作为URI在CC/PP表达式中使用。

未注册的特征标签可以去掉开头的'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构架，对于更广泛环境的操作规则必须规定好：

• 能力交换协议
• 信任模型
• 词汇表
• 安全机制
• 允许的属性值类型限制
• 属性值处理和/或匹配规则
• 代理词汇表和处理
• 请求设置文件识别的规则
• 任何被传输的资源数所需要包含的额外信息
• 用于识别参考的设置文件文档的URI表单(如默认)
• 用于定位和检索参考设置文件文档的机制
• 在主机协议已有的任何协商机制的交互作用

有少许协议假设嵌入了CC/PP的设计之中。虽然本意是要实现广泛意义上的协议无关，对于利用HTTP来检索Web资源的CC/PP使用还是被给予了一些特别关注。

F.1 HTTP中的请求处理过程概要

CC/PP协同HTTP使用应该按照以下的方式。

(这并不是一个协议规范，而只是对假想的信息流的暗示。定义转化CC/PP信息的协议是另外一项工作[CCPPEX])。

图 F-1：HTTP请求处理

+------+ (5) (4) +-------+ +------+ |Client| <==response== | Proxy | <==response== |Origin| <====> (Resource) | UA | ===request==> | | ===request==> |server| (3) ( data ) +------+ (1) | +-------+ (2) | +------+ | | v v (Client ) <--- (Client profile) <----- (Request profile) (defaults) + local values | v (Proxy ) <--- (Proxy profile) (defaults) + local values

1. 客户发送一个HTTP请求，其中附随一个CC/PP客户设置文件。客户设置文件中可以包含对默认设置文件的参考，默认设置文件描述了相关客户的一系列的共同能力(如特定的计算机/操作系统/浏览器组合，或移动设备的特定型号)，和不同于默认设置文件的值。
2. HTTP请求可能需要穿过，这些防火墙/代理(a)对访问内容有所限制，或(b)能按照请求客户的能力而采用不同形式的内容。这个代理扩充了含有关于这些限制和适应性的CC/PP设置文件，并将其与HTTP请求其一起发送到源服务器。请求可能需要经过几个这样的代理。
3. 源服务器收到请求并解释CC/PP设置文件。它选出和/或生成与设置文件中描述的复合的代理和客户能力相匹配的内容。并作为HTTP响应发送到请求链中最近的代理。
4. 如果需要，代理可以采用任何的内容适应，和任何的其他它需要履行的功能。最后，结果响应和内容传回发出请求的客户。
5. 客户收到HTTP响应并表现其中的内容。

注意：CC/PP和多种的HTTP accept-*报头之间有一点重叠。协同使用CC/PP和HTTP的协议规范必须指明HTTP 'accept-*'可以如何使用，它们将如何与CC/PP设置文件交互。

F.2 代理的行为的协议假设

描述代理行为的构架对用于转化CC/PP设置文件的协议做出了一些假设：

• CC/PP设置文件被转化成一个或多个部分，每个部分包含一个图表段，这些图标段组合在一起构成一个RDF图表。
• 除了RDF图表，协议必须分别地命名与当前的请求设置文件的根段对应的RDF资源。
• 当前的操作模型是这样的，所有的CC/PP设置文件的解释工作是由源服务器来完成，而非代理。这可能需要协议允许起源服务器在其响应中供应信息，以便允许代理来决定是否进行它们可以提供的转化；如是否需要进行XHTML到WML的转换，或者客户本身就有XHTML能力？

注意：: 上面所提到的“当前的操作模型”并没有禁止代理来解释CC/PP设置文件。更恰当地来说，这意味着描述代理行为的构架并不要求代理必须理解CC/PP设置文件。

Appendix G: RDF兼容性

本附录为读者提供一定的信息。

本CC/PP规范标准是基于资源描述构架(RDF)模型和语法规范[RDF]，一个W3C推荐标准。那个版本的RDF并没有显式的字面数据类型。在本规范标准编写过程中RDF规范标准也在进行修订。修订中的RDF (RDF/XML语法规范标准(修订))，在本文编写时还没有成为推荐标准，其中介绍对字面值的XML Schema数据类型的支持。本附录概述了对实现者的暗示，以便他们完成他们的与这个RDF补充建议相兼容的CC/PP实现。希望将来版本的CC/PP规范标准可以提出显式的数据类型在定义CC/PP设置文件时该如何使用。

G.1 暗示的数据类型

在本规范标准中，包含在CC/PP设置文件中的CC/PP属性值是，在RDF (修订)[RDFPRIMER]术语中，一个RDF普通文字。CC/PP词汇schema(如附录C中的例子)，是用在CC/PPschema(附录B)中介绍的简单类型来定义的，对于这些属性它可以供应额外的类型信息。CC/PP设置文件消费者应用程序可以使用词汇schema(或直接解释schema数据，或对于已知的词汇在应用程序中嵌入等同的信息)来检查设置文件中的数据的有效性，并且把这些数据映射到编程语言的数据类型。

G.2 显式的数据类型

修订的RDF工作草稿支持显式的XSD(XML Schema数据类型(XML Schema Datatypes))数据类型。如果显式的数据类型被采用，可以修订CC/PP规范标准来允许CC/PP设置文件中的属性值表示为RDF打字文字。在RDF打字文字的XML编序中，字面值的类型被规定为含有这个字面值的元素的一个属性。在这种情况下，CC/PP设置文件消费者应用程序可以使用这个类型信息来解释CC/PP属性值，而不需要访问另外的词汇schema信息。

为了向下兼容，将来CC/PP设置文件消费者应该能处理CC/PP属性，不论它是使用暗示的或显式的数据类型。

附录W：修订历史

(略)

---