Lisez-moi S.V.P. 
W3C

Les profils composites de capacités/préférences (CC/PP) : structure et vocabulaires 1.0

Recommandation du W3C du 15 janvier 2004

Cette version :
http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
Dernière version :
http://www.w3.org/TR/CCPP-struct-vocab/
Version précédente :
http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/
Rédacteurs :
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 (jusqu'en mars 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

Veuillez consulter l'errata de ce document qui peut contenir des corrections normative.

La version en anglais de cette spécification est la seule normative. Des traductions non normatives peuvent éventuellement exister.


Résumé

Ce document décrit la structure et les vocabulaires CC/PP (Composite Capabilities/Preference Profiles). Un profil CC/PP est une description des capacités de l'appareil et des préférences d'un utilisateur. Cette description, que l'on désigne souvent par contexte de remise d'un appareil, peut servir à guider l'adaptation du contenu présenté à l'appareil en question.

Le cadre de description des ressources (RDF) est utilisé afin de créer des profils décrivant les capacités et les préférences d'un agent utilisateur. La structure d'un profil sera expliquée dans le document. Les sujets abordés couvrent :

Le vocabulaire CC/PP consiste en identificateurs (des adresses URI) qui désignent des capacités et préférences particulières ; il contient :

Statut de ce document

Cette section décrit le statut du document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C situé à http://www.w3.org/TR/.

Ce document est une recommandation du W3C. Il a été examiné par les membres du W3C et d'autres tiers intéressés et le Directeur l'a approuvé en tant que recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme référence normative à partir d'un autre document.

Le rôle du W3C en produisant cette recommandation consiste à attirer l'attention sur la spécification et à en promouvoir le large déploiement. Cela améliore la fonctionnalité et l'interopérabilité du Web. Une ensemble de tests a été développée en ce sens, accompagnée d'un rapport de mise en œuvre.

Ce document a été élaboré par le groupe de travail Indépendance par rapport aux appareils (DIWG) du W3C, partie de l'Activité Indépendance par rapport aux appareils au sein du Domaine Interaction du W3C. L'état d'avancement des travaux est donné en permanence sur la page d'accueil du groupe de travail Indépendance par rapport aux appareils (lien réservé aux membres).

Le public est invité à faire part de ses remarques ou à signaler les erreurs aux rédacteurs sur www-mobile@w3.org, le forum de discussions sur le travail du W3C pour l'accès au Web par les appareils portables. Une archive est disponible à http://lists.w3.org/Archives/Public/www-mobile/.

On peut consulter les divulgations de brevets concernant cette spécification sur la page de divulgation de brevets du groupe de travail CC/PP conformément à la politique du W3C.

Table des matières

1. Introduction

Ce document décrit la structure et les vocabulaires CC/PP (Composite Capabilities/Preference Profiles). Un profil CC/PP est une description des capacités d'un appareil et des préférences de l'utilisateur, qui peut s'utiliser pour guider l'adaptation d'un contenu présenté à cet appareil. Dans le contexte de ce document, un profil ne se rapporte pas à un sous-ensemble d'une spécification donnée, par exemple le profil CSS Mobile, mais désigne le ou les documents, échangés par des appareils, qui décrivent les capacités d'un appareil.

L'augmentation du nombre et de la diversité des appareils connectés à l'internet s'accompagne d'un besoin correspondant croissant de remettre un contenu qui soit adapté aux capacités des différents appareils. Certaines techniques limitées existent déjà, telles que les en-têtes Accept de HTTP et les attributs alt de HTML . Dans le cadre de l'adaptation et de la contextualisation d'un contenu, un format de profil universel est nécessaire pour décrire les capacités d'un agent utilisateur et les préférences de son utilisateur. Le format CC/PP répond à cette attente.

CC/PP s'appuie sur RDF, le cadre de description des ressources, conçu par le W3C comme un langage universel de description de métadonnées. RDF fournit un cadre et les outils de base à la fois pour l'extensibilité du vocabulaire, par le biais des espaces de nommage XML [XMLNAMESPACES], et pour l'interopérabilité. Une spécification décrit la manière de coder RDF avec XML [RDF], une autre définit un langage de description de schéma RDF avec RDF [RDFSCHEMA]. RDF a été conçu afin de décrire des métadonnées ou des propriétés lisibles par les machines sur le Web. RDF représente un choix naturel pour le cadre de CC/PP, car les profils des agents utilisateurs sont des métadonnées destinées principalement aux échanges entre les agents utilisateurs et les fournisseurs de données de ressource. Pour une introduction à RDF, voir [RDFPRIMER]. Remarquez que le document [RDFPRIMER] décrit une version de RDF plus récente que celle sur laquelle se base cette spécification.

Un profil CC/PP contient un certain nombre de noms d'attributs CC/PP et de valeurs associées, lesquels sont utilisés par un serveur afin de déterminer la forme la plus appropriée de la ressource à remettre à un client. Ce profil est structuré pour permettre à un client de décrire ses capacités en rapport avec un profil normalisé, accessible au serveur origine ou à un autre émetteur de données de ressource, et avec un ensemble restreint de caractéristiques qui s'ajoutent au profil normalisé ou s'en distinguent . L'ensemble représenté par des noms d'attributs CC/PP, des valeurs admises et des significations associées constitue un vocabulaire CC/PP.

Certaines informations contenues dans un profil peuvent être sensibles, et il faut donc déployer des mécanismes de confiance et de sécurité adéquats afin de protéger la vie privée des utilisateurs. Faisant partie d'une application globale, CC/PP ne peut couvrir entièrement de telles questions mais son utilisation conjointe avec des mécanismes appropriés est prévue. Ce sujet est abordé dans l'Annexe F, (applications CC/PP).

Il est prévisible que des applications différentes utiliseront des vocabulaires différents ; c'est nécessaire, en effet, si l'on doit représenter les propriétés spécifiques d'une application dans le cadre CC/PP. Mais, pour que des applications différentes puissent fonctionner ensemble, on a besoin d'un vocabulaire commun ou d'une méthode de conversion entre des vocabulaires différents. (Les espaces de nommage XML peuvent garantir l'absence de conflit entre les noms d'applications différentes, mais ils ne fournissent pas de base commune pour l'échange d'informations entre des applications différentes.) Tout vocabulaire qui se rapporte à la structure d'un profil CC/PP doit suivre cette spécification. Les annexes introduisent un vocabulaire d'attributs CC/PP simple, issu pour partie de travaux antérieurs de l'IETF, qui peut s'utiliser pour améliorer l'échange d'informations de capacité entre les applications.

CC/PP est conçu pour une large compatibilité avec la spécification plus ancienne UAProf [UAPROF] du WAP Forum. C'est-à-dire que nous avons essayé d'accomoder des profils UAProf existants.

CC/PP est compatible avec les ensembles de caractéristiques de média de l'IETF (CONNEG) [RFC2533], au sens où toutes les étiquettes et valeurs de caractéristiques de média peuvent s'exprimer dans CC/PP. Au contraire, on ne peut pas exprimer tous les profils CC/PP sous forme d'étiquettes et valeurs de caractéristiques de média, et CC/PP n'essaye pas d'établir de relations entre les attributs.

Bien que les exemples et les usages à ce jour se soient concentrés sur les capacités des appareils, CC/PP peut aussi véhiculer des informations sur les préférences de l'utilisateur qui, utilisées à bon escient, devraient permettre aux serveurs Web d'améliorer l'accessibilité des sites Web. On trouvera une discussion plus complète sur l'accessibilité des sites Web dans Les directives pour l'accessibilité du contenu Web [WAI].

1.1 La portée et les éléments normatifs

La recommandation CC/PP : structure et vocabulaires (abrégée en CC/PP dans la suite du document) définit un format des données d'un profil client et un cadre pour l'incorporation des caractéristiques particulières d'une application ou d'un environnement d'exploitation. Elle ne définit pas comment le profil est transmis ni quels attributs CC/PP doivent être générés ou reconnus. CC/PP est conçu pour une utilisation au sein d'un cadre applicatif global. Ainsi, la spécification des éléments CC/PP qui doivent être pris en charge et de ceux qui peuvent être omis est du ressort particulier d'une application.

Peu de principes de protocole entrent dans la conception de CC/PP. Bien que destiné à être largement indépendant d'un protocole, CC/PP a fait l'objet d'une attention particulière en ce qui concerne son utilisation avec le protocole HTTP pour la recherche de ressources Web. L'Annexe F contient des explications supplémentaires à propos des applications CC/PP.

Ce document décrit un certain nombre de fonctionnalités de CC/PP. Certaines fonctionnalités forment une partie de la structure essentielle de CC/PP, pour laquelle la conformité est OBLIGATOIRE (voir le chapitre 5). L'emploi des autres fonctionnalités est RECOMMENDÉ ou OPTIONNEL. Une partie explique également la façon dont les nouveaux vocabulaires devraient être introduits, elle s'adresse aux concepteurs d'applications CC/PP plutôt qu'aux personnes chargées de la mise en œuvre.

Le chapitre sur l'architecture ne décrit pas de fonctionnalités spécifiques mais donne les principes généraux sous-tendant la conception de CC/PP. Ce chapitre non normatif contient cependant des informations qui devraient être comprises pour la bonne mise en œuvre de CC/PP.

Le chapitre sur la structure CC/PP recouvre deux domaines principaux :

Le chapitre sur les vocabulaires d'attributs CC/PP décrit quelques fonctionnalités générales des attributs CC/PP et de leurs valeurs. La gestion des formats décrits pour les valeurs d'attribut simples est RECOMMENDÉE (la syntaxe réelle de chaque valeur CC/PP simple est définie par la spécification d'attribut correspondante) ; ces spécifications peuvent citer les informations fournies dans ce chapitre. La gestion des formats décrits pour les attributs CC/PP structurés est OBLIGATOIRE, si pertinent.

La prise en charge n'est pas nécessaire pour n'importe quel vocabulaire particulier, mais les concepteurs d'applications sont fortement encouragés à réutiliser les vocabulaires existants quand c'est possible.

Les applications CC/PP ne doivent pas obligatoirement prendre en charge les fonctionnalités décrites en annexes, cependant chaque nouveau vocabulaire d'attributs DOIT se baser sur les classes et les propriétés RDF définies par le schéma RDF dans l'Annexe B (les nouveaux attributs CC/PP sont des instances de ccpp:Attribute, les nouvelles classes de composants sont des sous-classes de ccpp:Component, etc.).

REMARQUE : La raison de l'obligation faite aux nouveaux vocabulaires de se baser sur le schéma CC/PP, c'est que les applications qui prennent en compte les schémas peuvent inclure des données de profil CC/PP avec d'autres données RDF. Avoir des nouveaux termes de vocabulaire basés sur le schéma CC/PP identifie clairement ceux-ci comme faisant partie d'un profil CC/PP lors de la combinaison de données RDF issues de multiples sources. Cette obligation n'affecte pas les processeurs de profil CC/PP autonomes, mais le bénéfice réel de cet utilisation ici de RDF apparaîtra dans le long terme, en permettant à des gestionnaires plus généraux de combiner et traiter des données provenant de sources multiples (par exemple, du document, des informations relatives à la sécurité et à la vie privée).

1.2 La structure de ce document

Le reste du chapitre couvre la terminologie, les conventions et les notations employées dans ce document.

Le chapitre 2, L'architecture CC/PP, présente une vue d'ensemble de la structure du profil CC/TP et de l'utilisation des espaces de nommage XML.

Le chapitre 3, La structure CC/PP, décrit la structure d'un profil CC/PP et introduit les éléments RDF utilisés pour créer les éléments CC/PP essentiels.

Le chapitre 4, Les vocabulaires d'attributs, présente l'utilisation des attributs dans un profil CC/PP et présente la structure recommandée des éléments CC/PP employés pour décrire des caractéristiques particulières.

Les annexes contiennent d'autres documents d'accompagnement, qui ne sont pas essentiels à la construction d'un profil CC/PP valide, mais qui fournissent des informations documentaires utiles à la compréhension de CC/PP, ses relations avec RDF, ou à la définition de vocabulaires d'attributs pour des applications particulières.

1.3 Les conventions du document

1.3.1 La terminologie

Voir La terminologie et les abréviations de CC/PP dans l'Annexe A de ce document.

Le terme attribut CC/PP s'emploie ici pour désigner une capacité ou une caractéristique particulières d'un client (ou d'un autre système) qui apparaît dans un profil CC/PP. Le terme caractéristique se rapporte à la capacité ou à la caractéristique d'un client qui peut être à l'origine d'un attribut CC/PP ou pas. Le terme nom d'attribut s'emploie pour indiquer le nom d'une propriété RDF utilisée pour identifier un attribut CC/PP.

Les mots-clés DOI(VEN)T, NE DOI(VEN)T PAS, DEVRAI(EN)T, NE DEVRAI(EN)T PAS, PEU(VEN)T, NE PEU(VEN)T PAS, OBLIGATOIRE, RECOMMANDÉ et OPTIONNEL, dans ce document, doivent s'interpréter comme décrit dans le document RFC 2119 [RFC2119].

1.3.2 La notation de graphe RDF

La structure sous-jacente de RDF est un graphe étiqueté orienté. RDF emploie une sérialisation XML pour représenter ces graphes dans les échanges entre systèmes informatiques. Cette notation XML est plutôt volumineuse et difficile pour le discours humain, de sorte qu'ici on emploie une notation plus visuelle pour décrire les structures des graphes RDF :

Figure 1-1 : Notation d'un graphe RDF
[Ressource-sujet] --nomDePropriété--> [Ressource-objet]
Désigne une arête de graphe étiquetée 'nomDePropriété' depuis une ressource RDF nommée 'Ressource-sujet' vers une autre ressource RDF nommée 'Ressource-objet'.
[Ressource-sujet] --nomDePropriété--> "Valeur de propriété"
Désigne une arête de graphe étiquetée 'nomDePropriété' depuis une ressource RDF nommée 'Ressource-sujet' vers une chaîne littérale contenant la valeur indiquée.
[Ressource-sujet] --nomDePropriété--> { "Valeur1", "Valeur2", ... }
Ceci est un raccourci pour une propriété dont la valeur est une ressource rdf:Bag contenant les valeurs indiquées (voir le chapitre 4.1.2.1).
[<Type-du-sujet>] --nomDePropriété--> [<Type-de-l-objet>]
Les noms entre crochets représentent une ressource RDF du type indiqué (c'est-à-dire ayant la valeur de propriété indiquée pour rdf:Type, sans indication d'un nom particulier pour la ressource. C'est utile pour montrer les classes RDF qui peuvent être reliées par une propriété.
[Ressource-sujet] --nomDePropriété--> [Ressource-objet]
                                      |
       -------------------------------
      |
      +--propriété1--> (valeur1)
      +--propriété2--> (valeur2)
      :
     (etc.)
Les arcs de propriété peuvent s'enchaîner et plusieurs arcs peuvent partir d'une ressource sujet.

Voici quelques exemples XML des structures de graphe RDF décrites ci-dessus :

Figure 1-2 : Exemple de graphe RDF en XML
<?xml version="1.0"?>
<!-- Tout graphe RDF est un élément RDF
  -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns="http://www.example.com/schema#">

  <!--  [Ressource-sujet] -nomDePropriété-> [Ressource-objet]
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété>
      <rdf:Description
          rdf:about="http://www.example.com/profil#Ressource-objet" />
    </nomDePropriété>
  </rdf:Description>

  <!--  [Ressource-sujet] -nomDePropriété-> [Ressource-objet]
     -  (Format de remplacement)
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété
        rdf:resource="http://www.example.com/schema#Ressource-objet" />
  </rdf:Description>

  <!--  [Ressource-sujet] -nomDePropriété-> "valeur de propriété"
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété>valeur de propriété</nomDePropriété>
  </rdf:Description>

  <!--  [Ressource-sujet] -nomDePropriété-> { "Valeur1", "Valeur2", ... }
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété>
      <rdf:Description>
        <rdf:type
            rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
        <rdf:li>Valeur1</rdf:li>
        <rdf:li>Valeur1</rdf:li>

        <!-- ...etc... -->

      </rdf:Description>
    </nomDePropriété>
  </rdf:Description>

  <!--  [Ressource-sujet] -nomDePropriété-> { "Valeur1", "Valeur2", ... }
     -  (Format de remplacement)
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété>
      <rdf:Bag>
        <rdf:li>Valeur1</rdf:li>
        <rdf:li>Valeur1</rdf:li>

        <!-- ...etc... -->

      </rdf:Bag>
    </nomDePropriété>
  </rdf:Description>

  <!--  [<Type-du-sujet>] -nomDePropriété-> [<Type-de-l-objet>]
    -->
  <rdf:Description>
    <rdf:type
        rdf:resource="http://www.example.com/schema#Type-du-sujet" />
    <nomDePropriété>
      <rdf:Description>
        <rdf:type
            rdf:resource="http://www.example.com/schema#Type-de-l-objet" />
      </rdf:Description>
    </nomDePropriété>
  </rdf:Description>
  <!--  [Ressource-sujet] -nomDePropriété-> [Ressource-objet]
     -                                      |
     -                                      +-propriété1-> (valeur1)
     -                                      +-propriété2-> (valeur2)
     -                                      :
    -->
  <rdf:Description
      rdf:about="http://www.example.com/profil#Ressource-sujet">
    <nomDePropriété>
      <rdf:Description
          rdf:about="http://www.example.com/profil#Ressource-objet" >
      <propriété1>valeur1</propriété1>
      <propriété2>valeur2</propriété2>

      <!-- ...etc... -->

      </rdf:Description>
    </nomDePropriété>
  </rdf:Description>

</rdf:RDF>

2. L'architecture CC/PP

Ce chapitre non normatif fournit une vue d'ensemble des fonctionnalités de CC/PP.

2.1 La structure d'un profil CC/PP

De façon générale, un profil CC/PP est construit selon une hiérarchie à deux niveaux :

2.1.1 Les composants des profil

Les branches initiales de l'arbre du profil CC/PP décrivent les composants principaux du client. Comme exemples de composants principaux :

Une représentation graphique simple du bas d'un arbre CC/PP construit à partir de trois composants (MaterielFinal, LogicielFinal et NavigateurFinal) pourrait être :

Figure 2-1a : Les composants d'un profil CC/PP
[exemple:LeProfil]
 |
 +--ccpp:component-->[exemple:MaterielFinal]
 +--ccpp:component-->[exemple:LogicielFinal]
 +--ccpp:component-->[exemple:NavigateurFinal]

Le code XML correspondant pourrait ressembler à ceci :

Figure 2-1b : Les composants d'un profil CC/PP en 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:exemple="http://www.example.com/schema#">

  <rdf:Description rdf:about="http://www.example.com/profil#LeProfil">

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#MaterielFinal">
        <!--  Les propriétés de MaterielFinal ici  -->
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#LogicielFinal">
        <!--  Les propriétés de LogicielFinal ici  -->
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#NavigateurFinal">
        <!--  Les propriétés de NavigateurFinal ici  -->
      </rdf:Description>
    </ccpp:component>

  </rdf:Description>
</rdf:RDF>

2.1.2 Les attributs des composants

Un profil CC/PP décrit les capacités et préférences d'un client au moyen d'un certain nombre d'attributs CC/PP pour chaque composant.

La description de chaque composant est un sous-arbre dont les branches représentent les capacités ou préférences associées au composant en question. Bien que RDF rende possible la modélisation d'une grande variétés de structures de données, y compris des graphes arbitraires, on préfère généralement éviter les modèles de données complexes pour les valeurs d'attribut d'un profil. On peut souvent décrire une capacité à l'aide d'un petit nombre d'attributs CC/PP, chacun ayant une valeur atomique simple. Quand des valeurs plus complexes sont nécessaires, on peut les construire comme des sous-graphes RDF. L'emploi de valeurs d'attribut complexes peut se révéler utile pour représenter des valeurs de remplacement, par exemple, un navigateur pouvant gérer plusieurs version de HTML. Un profil hypothétique pourrait ressembler à ceci :

Figure 2-2a : Exemple de profil CC/PP complet
[ex:LeProfil]
 |
 +--ccpp:component-->[ex:MaterielFinal]
 |                    |
 |                    +--rdf:type----> [ex:PlateformeMateriel]
 |                    +--ex:displayWidth--> "320"
 |                    +--ex:displayHeight--> "200"
 |
 +--ccpp:component-->[ex:LogicielFinal]
 |                    |
 |                    +--rdf:type----> [ex:PlateformeLogiciel]
 |                    +--ex:name-----> "EPOC"
 |                    +--ex:version--> "2.0"
 |                    +--ex:vendor---> "Symbian"
 |
 +--ccpp:component-->[ex:NavigateurFinal]
                      |
                      +--rdf:type----> [ex:AgentUtilNavigateur]
                      +--ex:name-----> "Mozilla"
                      +--ex:version--> "5.0"
                      +--ex:vendor---> "Symbian"
                      +--ex:htmlVersionsSupported--> [ ]
                                                      |
                          ----------------------------
                         |
                         +--rdf:type---> [rdf:Bag]
                         +--rdf:_1-----> "3.2"
                         +--rdf:_2-----> "4.0"

Le code XML correspondant pourrait ressembler à ceci :

Figure 2-2b : Exemple de profil CC/PP complet en 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/profil#LeProfil">

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#MaterielFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#PlateformeMateriel" />
        <ex:displayWidth>320</ex:displayWidth>
        <ex:displayHeight>200</ex:displayHeight>
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#LogicielFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#PlateformeLogiciel" />
        <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/profil#NavigateurFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#AgentUtilNavigateur" />
        <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 Les valeurs par défaut

Les attributs d'un composant peuvent être incorporés, comme dans l'exemple précédent, ou être déclarés par référence à un profil par defaut, lequel peut être stocké séparément et qu'on accède au travers de l'adresse URI qu'il contient.

Cette utilisation d'un profil par défaut défini ailleurs est en quelque sorte similaire au concept d'héritage dynamique. Elle rend possible certaines optimisations importantes. En tant que document distinct, le profil peut résider à un emplacement différent et peut être mis en cache séparément. Ceci est particulièrement appréciable dans les environnements en liaison sans fil, tels que les réseaux cellulaires, où les profils peuvent être volumineux et la liaison du client lente et coûteuse. Avec des valeurs par défaut, seule une petite partie du profil total est transmise par le réseau sans fil.

Les valeurs par défaut d'un composant de profil CC/PP sont signalés par un arc ccpp:defaults depuis le composant concerné vers un composant qui définit les valeurs par défaut.

Figure 2-3a : Un profil CC/PP utilisant des valeurs par défaut
[ex:LeProfil]

 |
 +--ccpp:component--> [ex:MaterielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeMateriel]
 |                     +--ccpp:defaults--> [ex:MaterielDefaut]
 |
 +--ccpp:component--> [ex:LogicielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeLogiciel]
 |                     +--ccpp:defaults--> [ex:LogicielDefaut]
 |
 +--ccpp:component--> [ex:NavigateurFinal]
                       |
                       +--rdf:type-------> [ex:AgentUtilNavigateur]
                       +--ccpp:defaults--> [ex:AgentUtilDefaut]

[ex:MaterielDefaut]
 |
 +--rdf:type----> [ex:PlateformeMateriel]
 +--ex:displayWidth--> "320"
 +--ex:displayHeight--> "200"

[ex:LogicielDefaut]
 |
 +--rdf:type----> [ex:PlateformeLogiciel]
 +--ex:name-----> "EPOC"
 +--ex:version--> "2.0"
 +--ex:vendor---> "Symbian"

[ex:AgentUtilDefaut]
 |
 +--rdf:type----> [ex:AgentUtilNavigateur]
 +--ex:name-----> "Mozilla"
 +--ex:version--> "5.0"
 +--ex:vendor---> "Symbian"
 +--ex:htmlVersionsSupported--> [ ]
                                 |
                                 +--rdf:type---> [rdf:Bag]
                                 +--rdf:_1-----> "3.2"
                                 +--rdf:_2-----> "4.0"

Le code XML correspondant pourrait ressembler à ceci :

Figure 2-3b : Un profil CC/PP utilisant des valeurs par défaut en XML
Le profil de l'appareil appelant les valeurs par défaut :
<?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/profil#LeProfil">

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#MaterielFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#PlateformeMateriel" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/profilMateriel#MaterielDefaut" />
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#LogicielFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#PlateformeLogiciel" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/profilLogiciel#LogicielDefaut" />
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#NavigateurFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#AgentUtilNavigateur" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/profilTerminal#AgentUtilDefaut" />
      </rdf:Description>
    </ccpp:component>

  </rdf:Description>
</rdf:RDF>
Les valeurs par défaut de PlateformeMateriel :
<?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/profilMateriel#MaterielDefaut">
    <rdf:type
        rdf:resource="http://www.example.com/schema#PlateformeMateriel" />
    <ex:displayWidth>320</ex:displayWidth>
    <ex:displayHeight>200</ex:displayHeight>
  </rdf:Description>
</rdf:RDF>
Les valeurs par défaut de PlateformeLogiciel :
<?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/profilLogiciel#LogicielDefaut">
    <rdf:type
        rdf:resource="http://www.example.com/schema#PlateformeLogiciel" />
    <ex:name>EPOC</ex:name>
    <ex:version>2.0</ex:version>
    <ex:vendor>Symbian</ex:vendor>
  </rdf:Description>
</rdf:RDF>
Les valeurs par défaut de AgentUtilNavigateur :
<?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/profilTerminal#AgentUtilDefaut">
    <rdf:type
        rdf:resource="http://www.example.com/schema#AgentUtilNavigateur" />
    <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>

Si une valeur d'attribut donnée est appliquée directement à une ressource composant et si elle apparaît aussi dans une ressource appelée par la propriété ccpp:defaults, alors c'est la valeur appliquée directement qui a préséance :

Figure 2-4a : L'écrasement d'une valeur par défaut
[ex:LeProfil]
 |
 +--ccpp:component--> [ex:MaterielFinal]
                       |
                       +--rdf:type--------> [ex:PlateformeMateriel]
                       +--ccpp:defaults---> [ex:MaterielDefaut]
                       +--ex:memoryMb-------> "32"

[ex:MaterielDefaut]
 |
 +--rdf:type----> [ex:PlateformeMateriel]
 +--ex:displayWidth--> "320"
 +--ex:displayHeight--> "200"
 +--ex:memoryMb---> "16"

Dans cet exemple, le composant par défaut indique une capacité mémoire de 16Mb, mais cette valeur est écrasée par la propriété memoryMb appliquée directement au composant profil. De ce fait, dans ce profil, l'attribut memoryMb a une valeur de 32.

Le code XML correspondant pourrait ressembler à ceci :

Figure 2-4b : L'écrasement d'une valeur par défaut en XML
Le profil de l'appareil appelant les valeurs par défaut :
<?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/profil#LeProfil">

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profil#MaterielFinal">
        <rdf:type
            rdf:resource="http://www.example.com/schema#PlateformeMateriel" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/profilMateriel#MaterielDefaut" />
        <ex:memoryMb>32</ex:memoryMb>
      </rdf:Description>
    </ccpp:component>

  </rdf:Description>
</rdf:RDF>
Les valeurs par défaut de PlateformeMateriel:
<?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/profilMateriel#MaterielDefaut">
    <rdf:type
        rdf:resource="http://www.example.com/schema#PlateformeMateriel" />
    <ex:displayWidth>320</ex:displayWidth>
    <ex:displayHeight>200</ex:displayHeight>
    <ex:memoryMb>16</ex:memoryMb>
  </rdf:Description>
</rdf:RDF>

Une ressource indiquée par une propriété par défaut peut apparaître dans un document séparé, auquel cas on devrait fournir un appel d'adresse URI absolu pour la ressource par défaut. Dans ce cas, la partie adresse URI de l'identificateur de ressource par défaut (c'est-à-dire, en excluant la partie identificateur de fragment) est utilisée pour rechercher un document RDF contenant la description de la ressource par défaut. Par exemple, si la ressource par défaut se nomme http://example.com/profilMateriel#PlateformeMateriel, alors l'adresse URI http://example.com/profilMateriel sera utilisée pour rechercher un document RDF et, au sein de ce document, la ressource ayant pour identificateur local #PlateformeMateriel sera retenue comme ressource par défaut. (On pourrait définir une telle ressource au sein du document cible par about='http://example.com/profilMateriel#PlateformeMateriel' ou ID='PlateformeMateriel'. Voir également le chapitre 3.5.).

REMARQUE : Les applications individuelles peuvent accepter l'utilisation d'appels d'adresse URI relatifs. Le cas échéant, elles devraient préciser exactement la façon de localiser le document RDF correspondant.

2.2 L'extensibilité et les espaces de nommage

L'extension de CC/PP se fait principalement au travers de l'introduction de nouveaux vocabulaires d'attributs.

Une application ou un environnement d'exploitation qui utilisent CC/PP peuvent définir leur propre vocabulaire, mais on améliore l'interopérabilité globale si on définit des vocabulaires avec une vocation plus générale. Par exemple, un vocabulaire d'extension normalisé pour les appareils d'imagerie, ou les appareils de messagerie vocale, ou les appareils d'accès sans fil, etc. En conséquence, cette spécification définit un vocabulaire de base réduit de fonctionnalités, applicable à une gamme d'agents pour l'impression ou l'affichage, dont l'utilisation est fortement recommandée lorsque appropriée. Ce vocabulaire de base, inspiré de la spécification RFC 2534 de l'IETF [RFC2534], sert d'exemple sur la façon de définir un vocabulaire d'attributs CC/PP. La spécification UAProf du WAP Forum [UAPROF] en est un autre exemple.

Toute expression CC/PP peut faire appel à des termes issus d'un nombre arbitraire de vocabulaires différents, car il n'y a aucune restriction à réutiliser les termes d'un vocabulaire existant, au lieu de définir de nouveaux noms pour identifier les mêmes informations. Chaque vocabulaire est associé à un espace de nommage XML, tout comme les noms qui décrivent les structures RDF et CC/PP sous-jacentes.

Les espaces de nommage XML [XMLNAMESPACES] définissent une notation afin d'associer des formes nominales pratiques à des adresses URI arbitraires. La syntaxe de graphe RDF n'emploie pas spécifiquement d'espace de nommage, au contraire des sérialisations XML d'un graphe RDF. Nous employons également des préfixes d'espace de nommage lorsque nous présentons RDF dans la notation de graphe décrite ci-dessous.

Le cadre CC/PP utilise le mécanisme des espaces de nommage XML pour créer des adresses URI d'identification pour les éléments de base RDF, pour des éléments structuraux CC/PP et pour des vocabulaires d'attributs CC/PP. Examinons l'exemple de déclarations d'espace de nommage suivant :

Figure 2-7 : Exemple de déclarations d'espace de nommage
<?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#">

La première déclaration d'espace de nommage concerne un usage RDF. La deuxième déclaration nomme le vocabulaire structurel de base CC/PP, lequel comprend component, defaults et d'autres propriétés intrinsèques du cadre CC/PP. La troisième déclaration nomme le vocabulaire de propriétés CC/PP d'un composant.

REMARQUE : Retenez que les préfixes d'espace de nommage sont arbitraires : les applications NE DOIVENT PAS supposer que le préfixe rdf: se rapporte au vocabulaire RDF, ou que ccpp: se rapporte au vocabulaire CC/PP intrinsèque, etc. C'est l'adresse URI à laquelle est lié un préfixe d'espace de nommage significatif.

REMARQUE : Bien que les espaces de nommage soient identifiés par des appels d'adresse URI, il n'y aucune certitude quant à la disponibilité d'un schéma à cette adresse URI. Dans l'exemple ci-dessus, le nom d'espace de nommage pour UAProf est http://www.wapforum.org/UAPROF/ccppschema-20000405# et pourtant il n'y a aucun schéma à cette adresse URI. En pratique, on préfère généralement qu'un schéma correspondant existe à l'adresse URL utilisée pour identifier un espace de nommage, mais ce n'est pas une obligation et les applications CC/PP NE DOIVENT PAS en présupposer l'existence.

L'utilisation de plusieurs vocabulaires de propriétés de composant est admis et encouragé. Différentes communautés d'utilisateurs et différents domaines d'application (WAP Forum, ETSI, MExE, IETF CONNEG, etc.) peuvent définir leurs propres vocabulaires. C'est un mécanisme essentiel pour répondre aux besoins de ces communautés.

Les espaces de nommages suivants sont introduits dans le cadre CC/PP :

http://www.w3.org/2002/11/08-ccpp-schema#

Le Schéma RDF normatif qui définit les déclarations de classe pour CC/PP et les propriété de structure (listées dans l'Annexe B.3).
http://www.w3.org/2002/11/08-ccpp-client#
Exemple de vocabulaire non normatif pour décrire des capacités de client simples, concernant tout particulièrement les clients dotés de capacités d'impression ou d'affichage (listées dans l'Annexe C).

REMARQUE : Pour rechercher ces schémas, votre navigateur doit nécessairement comporter une en-tête Accept:text/xml dans la requête. Les navigateurs, qui n'ajoutent pas cette en-tête ou qui utilisent l'en-tête Accept:*/*, ou des variantes de celle-ci, recevront une page HTML faisant remarquer que ces espaces de nommage sont réservés aux schémas CC/PP.

3. La structure CC/PP

La structure générale d'un profil client CC/PP prend la forme d'un arbre à deux niveaux : les composants et les attributs, chaque composant ayant la possibilité d'appeler un ensemble de valeurs par défaut défini ailleurs.

3.1 Les composants

Un profil CC/PP contient un ou plusieurs composants, qui contiennent à leur tour un ou plusieurs attributs. Chaque composant est représenté par une ressource de type ccpp:Component (ou par certaines sous-classes RDF de celle-ci) et relié à la ressource du profil client par une propriété ccpp:component. Ici, l'espace de nommage ccpp est http://www.w3.org/2002/11/08-ccpp-schema#. Pour compatibilité avec UAProf, l'espace de nommage utilisé pour qualifier component PEUT être un espace de nommage UAProf.

L'objet d'une ressource ccpp:Component PEUT avoir un propriété rdf:type (ou une structure RDF équivalente) indiquant quelle sorte de composant client celle-ci décrit. L'exemple de la figure 2-2b est celui d'un profil ayant une indication explicite du sous-type du composant. Néanmoins, les processeurs CC/PP DOIVENT être capables de prendre en charge les profils qui ne contiennent pas d'indicateurs de type de composant. Tant que les attributs CC/PP utilisés sont tous spécifiques d'un type de composant donné, le processeur disposera de suffisamment d'informations pour les interpréter correctement. Une instance de type de composant, au plus, devrait être présente pour une ressource de profil donnée.

Si un profil CC/PP utilise un quelconque attribut pouvant apparaître sur des types de composant différents, alors le type d'un quelconque composant sur lequel un tel attribut apparaît DOIT être indiqué par une propriété rdf:type, ou RDF équivalente. Un processeur CC/PP DOIT être capable d'exploiter ce type d'information pour lever toute ambiguïté d'application d'un attribut utilisé.

3.2 Les attributs

Les profils CC/PP sont établis en utilisant RDF [RDF]. Le modèle de données RDF représente les attributs CC/PP par des propriétés nommées, reliant une ressource sujet à une ressource objet associée ou une valeur littérale RDF.

Afin de décrire les capacités et les préférences du client, le client en question est une ressource dont les caractéristiques sont décrites par des arêtes de graphe étiquetées, depuis celui-ci vers des valeurs objets correspondantes. Les étiquettes d'arête de graphe identifient la caractéristique du client (l'attribut CC/PP) en cours de description et les valeurs objets correspondantes sont les valeurs des caractéristiques.

Figure 3-1 : Une déclaration RDF décrivant un attribut du client
[Ressource composant du client] --nomAttribut--> (valeur-attribut)

Les étiquettes d'attribut CC/PP sont représentées par des valeurs de nom XML (selon la spécification [XML], chapitre 2.3), qui peuvent comprendre un préfixe d'espace de nommage (c'est-à-dire un nom qualifié, selon les espaces de nommage [XMLNAMESPACES], chapitre 3). Combinée à l'espace de nommage correspondant ou à la déclaration d'espace de nommage par défaut, chaque étiquette DOIT être appliquée à une adresse URI. Les noms d'attribut CC/PP sont ainsi des adresses URI, avec une syntaxe d'espace de nommage XML pour éviter que certaines expressions RDF ne deviennent trop encombrantes.

Le type de donnée des valeurs d'attribut peut être simple ou structuré.

Les types de données simples sont abordés à au chapitre 4.1.1. Chaque type de donnée de base peut faire l'objet d'une gamme de tests permettant de déterminer si différentes variantes de ressource conviennent pour une présentation par un client, par exemple, l'égalité, la compatibilité, l'infériorité à, la supériorité à, etc.

Les types de données structurées sont pris en charge au moyen de propriétés RDF spécifiques qui assemblent des valeurs littérales simples en valeurs composites. La sémantique CC/PP spécifique des propriétés RDF utilisées de cette façon est abordée au chapitre 4.1.2.

3.3 Les valeurs par défaut

Chaque composant d'un profil client peut indiquer une seule ressource distincte qui, à son tour, indique une collection subordonnée de valeurs d'attribut par défaut. Cet collection de valeurs par défaut peut être un document RDF distinct nommé via une adresse URI, ou peut se tenir dans le même document que le profil client (bien que, en pratique, avoir des valeurs par défaut dans le même document soit probablement de peu d'intérêt). Si un attribut de la collection de valeurs par défaut est aussi présent dans la partie principale du profil client, alors c'est la valeur issue de ce dernier profil qui a préséance. L'objectif est que le vendeur de matériel ou le fournisseur de système puissent fournir des valeurs par défaut qui soient communes à un certain nombre de systèmes, dans un endroit facilement accessible pour un serveur origine, puis utiliser le profil client pour spécifier les variations par rapport au profil commun. Le propriétaire de l'opérateur du produit ou du système doit pouvoir ajouter ou changer des options, telle que de la mémoire supplémentaire, qui apportent de nouvelles capacités ou modifient les valeurs de certaines capacités originales.

Les valeurs par défaut sont appelées par la propriété ccpp:defaults. Ce nom est conforme aux recommandations de format de nom de la spécification du modèle et de la syntaxe de RDF [RDF], Annexe C.1. Cependant, pour des raisons de compatibilité avec des versions antérieures de CC/PP utilisées avec UAProf, les processeurs CC/PP DEVRAIENT reconnaître le nom de propriété ccpp:Defaults (avec un D majuscule) comme équivalent. Ici, l'espace de nommage de ccpp est http://www.w3.org/2002/11/08-ccpp-schema#. Pour compatibilité avec UAProf, l'espace de nommage utilisé pour qualifier defaults, ou Defaults, PEUT être un espace de nommage UAProf.

Les valeurs par défaut peuvent être codées directement ou comme documents distincts. Il est du ressort d'un serveur interprétant un profil CC/PP de combiner les profils avec les éventuelles valeurs par défaut référencées ailleurs, de manière à pouvoir interpréter correctement le profil. Un profil avec des valeurs par défaut dans le même document équivaut logiquement à un profil où les valeurs par défaut, absentes du document, se trouveraient dans un ou plusieur documents externes appelés. Voici le graphe d'un profil simple utilisant des valeurs par défaut :

Figure 3-2a : Un profil CC/PP utilisant des valeurs par défaut
[ex:LeProfil]
 |
 +--ccpp:component--> [ex:MaterielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeMateriel]
 |                     +--ccpp:defaults--> [ex:MaterielDefaut]
 |                     +--ex:displayWidth--> "640"
 |                     +--ex:displayHeight-> "400"
 |
 +--ccpp:component--> [ex:LogicielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeLogiciel]
 |                     +--ccpp:defaults--> [ex:LogicielDefaut]
 |
 +--ccpp:component--> [ex:NavigateurFinal]
                       |
           ------------
          |
          +--rdf:type-------> [ex:AgentUtilNavigateur]
          +--ccpp:defaults--> [ex:AgentUtilDefaut]
          +--ex:htmlVersionsSupported--> { "2.0", "3.2", "4.0" }

[ex:MaterielDefaut]
 |
 +--rdf:type----> [ex:PlateformeMateriel]
 +--ex:cpu------> "PPC"
 +--ex:displayWidth--> "320"
 +--ex:displayHeight--> "200"

[ex:LogicielDefaut]
 |
 +--rdf:type----> [ex:PlateformeLogiciel]
 +--ex:name-----> "EPOC"
 +--ex:version--> "2.0"
 +--ex:vendor---> "Symbian"

[ex:AgentUtilDefaut]
 |
 +--rdf:type----> [ex:AgentUtilNavigateur]
 +--ex:name-----> "Mozilla"
 +--ex:version--> "5.0"
 +--ex:vendor---> "Symbian"
 +--ex:htmlVersionsSupported--> { "3.2", "4.0" }

Si un composant appelé par ccpp:defaults contient un attribut absent du composant de profil appelant, alors l'effet est comme si la valeur d'attribut dans le composant par défaut était appliquée directement au composant de profil. Par exemple, le profil de la figure 3-2a devraient s'interpréter comme décrivant les mêmes capacités présentées dans la figure 3-2b.

Figure 3-2b : La résolution d'un profil CC/PP utilisant des valeurs par défaut
[ex:LeProfil]
 |
 +--ccpp:component--> [ex:MaterielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeMateriel]
 |                     +--ex:displayWidth--> "640"
 |                     +--ex:displayHeight-> "400"
 |                     +--ex:cpu------> "PPC"
 |
 +--ccpp:component--> [ex:LogicielFinal]
 |                     |
 |                     +--rdf:type-------> [ex:PlateformeLogiciel]
 |                     +--ex:name-----> "EPOC"
 |                     +--ex:version--> "2.0"
 |                     +--ex:vendor---> "Symbian"
 |
 +--ccpp:component--> [ex:NavigateurFinal]
                       |
           ------------
          |
          +--rdf:type-------> [ex:AgentUtilNavigateur]
          +--ex:htmlVersionsSupported--> { "2.0", "3.2", "4.0" }
          +--ex:name-----> "Mozilla"
          +--ex:version--> "5.0"
          +--ex:vendor---> "Symbian"

Et voici la sérialisation XML correspondante, avec les descriptions de ressource par défaut incorporées à la description du profil client. Remarquez que cet exemple fait appel à un espace de nommage par défaut pour les éléments RDF mais doit toujours utiliser des préfixes d'espace de nommage explicites pour les attributs RDF.

Figure 3-2c : Un profil CC/PP utilisant des valeurs par défaut incorporées en 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/LeProfil">
    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/MaterielFinal">
        <rdf:type rdf:resource="http://example.com/Schema#PlateformeMateriel"/>
        <ccpp:defaults>
          <rdf:Description rdf:about="http://example.com/MaterielDefaut">
            <rdf:type rdf:resource="http://example.com/Schema#PlateformeMateriel"/>
            <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/LogicielFinal">
        <rdf:type rdf:resource="http://example.com/Schema#PlateformeLogiciel" />
        <ccpp:defaults>
          <rdf:Description rdf:about="http://example.com/LogicielDefaut">
            <rdf:type rdf:resource="http://example.com/Schema#PlateformeLogiciel"/>
            <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#AgentUtilNavigateur" />
        <ccpp:defaults>
          <rdf:Description rdf:about="http://example.com/AgentUtilDefaut">
            <rdf:type rdf:resource="http://example.com/Schema#AgentUtilNavigateur"/>
            <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>

Les valeurs par défaut incorporées équivalent logiquement à celles contenues dans un document externe appelé, ce qui constituerait une façon normale de fournir des valeurs par défaut. L'exemple suivant est la sérialisation XML du même profil avec des références vers des valeurs par défaut externes :

Figure 3-3 : Un profil CC/PP référençant des valeurs par défaut externes en 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/LeProfil">
    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/MaterielFinal">
        <rdf:type rdf:resource="http://example.com/Schema#PlateformeMateriel"/>
        <ccpp:defaults rdf:resource="http://example.com/MaterielDefaut"/>
        <prf:displayWidth>640</prf:displayWidth>
        <prf:displayHeight>400</prf:displayHeight>
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/LogicielFinal">
        <rdf:type rdf:resource="http://example.com/Schema#PlateformeLogiciel" />
        <ccpp:defaults rdf:resource="http://example.com/LogicielDefaut"/>
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/Navigateur">
        <rdf:type rdf:resource="http://example.com/Schema#AgentUtilNavigateur" />
        <ccpp:defaults rdf:resource="http://example.com/AgentUtilDefaut"/>
        <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>

Chaque ressource par défaut externe est un document RDF distinct appelé via une adresse URI.

REMARQUE : Un document par défaut utilise un élément rdf:Description pour nœud racine. L'instance rdf:Description est nommée à l'aide d'un attribut rdf:about dont la valeur est une adresse URI. Celui-ci DOIT correspondre à la valeur de l'attribut XML rdf:resource de l'élément ccpp:defaults dans le document appelant. (Le composant par défaut n'a pas besoin d'être identifié quand il est incorporé, comme dans l'exemple ci-dessus). Dans les exemples de documents par défaut suivants, on utilisera les URL des documents de valeurs par défaut externes. Cependant, l'adresse URI de la ressource par défaut n'est pas nécessairement l'adresse URL du document, tant que l'adresse URI est identifiée de manière unique, que la même adresse URI est utilisée dans le document source et le document de valeurs par défaut externe et que le logiciel traitant peut localiser et récupérer le document contenant la ressource par défaut.

Voici les exemples de documents par défaut appelés précédemment :

Figure 3-4 : Les valeurs par défaut externes de PlateformeMateriel
Document : http://example.com/MaterielDefaut
<?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/MaterielDefaut">
     <rdf:type rdf:resource="http://example.com/Schema#PlateformeMateriel"/>
     <prf:cpu>PPC</prf:cpu>
     <prf:displayWidth>320</prf:displayWidth>
     <prf:displayHeight>200</prf:displayHeight>
   </rdf:Description>
</rdf:RDF>

 

Figure 3-5 : Les valeurs par défaut externes de PlateformeLogiciel
Document : http://example.com/LogicielDefaut
<?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/LogicielDefaut">
     <rdf:type rdf:resource="http://example.com/Schema#PlateformeLogiciel"/>
     <prf:name>EPOC</prf:name>
     <prf:vendor>Symbian</prf:vendor>
     <prf:version>2.0</prf:version>
   </rdf:Description>
</rdf:RDF>

 

Figure 3-6 : Les valeurs par défaut externes de AgentUtilNavigateur
Document : http://example.com/AgentUtilDefaut
<?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/AgentUtilDefaut">
    <rdf:type rdf:resource="http://example.com/Schema#AgentUtilNavigateur"/>
    <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 Distinguer la structure du profil et les attributs

CC/PP emploie des espaces de nommage pour distinguer le vocabulaire associé à la structure (par exemple, ccpp:component) des vocabulaires associés aux applications (par exemple, l'affichage par le matériel final).

Dans cet exemple, nous utilisons l'espace de nommage http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#, associé au préfixe prf:, pour décrire des propriétés non définies dans les espaces de nommage CC/PP ou RDF :

Figure 3-7 : La sérialisation XML d'un profil CC/PP avec des espaces de nommage
<?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/LeProfil">
    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/MaterielFinal">
        <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/LogicielFinal">
        <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/Navigateur">
        <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>

Toutes les ressources RDF qui se rapportent à la structure d'ensemble de CC/PP sont définies dans l'espace de nommage ccpp: et ont des propriétés de schéma associées qui permettent, à un processeur capable d'interpréter un schéma, de les distinguer d'un vocabulaire d'attributs ou d'autres déclarations RDF.

3.5 Remarques sur l'utilisation de RDF

Cette spécification utilise l'attribut rdf:about pour spécifier les adresses URI des ressources dans les exemples. C'est un choix délibéré afin de s'assurer que de telles adresses URI soient spécifiées de manière absolue et sans ambiguïté. C'est aussi une différence avec UAProf, qui utilise les deux attributs rdf:about et rdf:ID.

CC/PP admet les attributs rdf:ID ou rdf:about. Par contre, les valeurs des attributs rdf:ID représentent des adresses URI relatives à l'adresse URI de base du fragment RDF du document [RDFFRAGMENT]. Lorsqu'un document est déplacé ailleurs sur le Web, la signification de la valeur d'un attribut rdf:ID change. Elle n'est pas définie quand le fragment RDF est contenu dans un document sans adresse URI de base, par exemple, quand celui-ci est encapsulé dans un message. Le groupe de travail RDF Core propose, dans un brouillon [RDFXML], que RDF prenne en charge les attributs xml:base. Si cette extension de RDF atteint le statut de recommandation, alors il faudrait utiliser les attributs rdf:ID en conjonction avec un attribut xml:base au lieu de rdf:about. Pour l'instant, notre recommandation est que les profils CC/PP DEVRAIENT utiliser rdf:about et les adresse URI des ressources être spécifiées complètement.

Les ressources composants dans un profil sont des instances de composants, identifiés dans le schéma correspondant, qui à leur tour DOIVENT être des sous-classes d'éléments ccpp:Component. On peut les identifier utilement comme telles au moyen de la propriété rdf:type dont la valeur correspond au nom du type de composant dans le schéma. (Parfois, cette indication de type DOIT être présente : voir le chapitre 3.1, Les composants).

3.6 La composition du graphe RDF

Les déclarations RDF qui constituent un graphe RDF n'apparaissent pas nécessairement dans un seul document. Pour CC/PP, le profil remis peut contenir des références vers des sous-graphes RDF transmis séparément ou ramenés des ressources Web indiquées.

Lorsque un sous-graphe externe est référencé ainsi, l'effet équivaut à prendre les ensembles de triplets de déclaration RDF, décrits par le document appelant et le document appelé, et à construire un nouveau document décrivant l'union de ces ensembles. (REMARQUE : Les mises en œuvre ne sont pas obligées de construire réellement un tel document, juste pour interpréter les déclarations RDF comme elles l'auraient fait à partir d'un seul document).

Cette composition de plusieurs documents RDF suppose, vis-à-vis du contenu des documents appelés, une confiance en leur précision à représenter les capacités présentées à l'émetteur de certaines données de ressource. Par conséquent, une telle composition se restreint aux documents qui décrivent des ressources référencées par des propriétés dont l'interprétation attendue renferme une telle notion de confiance, à savoir ccpp:defaults.

4. Les vocabulaires d'attributs

4.1 Les données d'attribut

Ce chapitre décrit les types de données et options structurantes des données de base admissibles pour les valeurs associées à un attribut CC/PP.

Tous les attributs CC/PP devraient être conçus avec des valeurs pouvant être traitées comme l'un des types de données, simple ou complexe, expliqué plus loin. La gestion des formats décrits pour les valeurs d'attribut est RECOMMANDÉE ; cette spécification n'interdit pas l'utilisation d'autres formes RDF valides mais elle n'en donne pas l'interprétation. (Voir également le chapitre 1.1 et l'Annexe F).

4.1.1 Les données d'attribut CC/PP simples

Toutes les valeurs d'attribut CC/PP simples sont représentées par des valeurs littérales simples RDF. Dans RDF/XML, elles peuvent apparaître sous forme de séquences de caractères soit dans des éléments XML, soit comme attributs XML.

Les valeurs littérales en clair acceptables pour un attribut peuvent être contraintes dans l'espace lexical associé au type de donnée d'une application particulière. Ce chapitre introduit quelques types de données spécifiques qui peuvent être associés aux attributs CC/PP simples.

L'utilisation CC/PP de base définie ici laisse l'éventuelle interprétation postérieure des valeurs employées à l'application de traitement. Les futures version de CC/PP pourront introduire des structures supplémentaires apportant une correspondance normalisée des profils clients avec d'autres ressources de métadonnées. Afin de permettre de tels développements et afin de faciliter l'interopérabilité avec les descriptions de caractéristiques de média de l'IETF, il est RECOMMANDÉ de définir toutes les valeurs d'attribut simples en fonction de l'un des types de données décrits ci-dessous.

Toutes les valeurs d'attribut sont en définitive des séquences de caractères UCS (Unicode). On suppose que les questions de codage de caractères dans les sérialisations particulières des données RDF seront définies par la représentation XML englobante.

REMARQUE : Ce document n'a pas vocation à comparer les attributs ni à fournir de mécanismes particuliers pour déterminer le type simple correspondant à une valeur d'attribut donnée. Les applications sont censées savoir quoi faire des attributs CC/PP qu'elles manipulent.

Où signalé, les expressions syntaxiques formelles emploient la notation présentée dans le chapitre 6 de la spécification XML [XML].

4.1.1.1 Les chaînes de caractères

Une valeur d'attribut CC/PP peut être définie comme étant du type chaîne textuelle sensible à la casse.

La valeur littérale RDF est contrainte dans l'espace lexical défini par le type de donnée string du schéma XML [XMLSCHEMA-2]. Un éventuel attribut 'lang' sera ignoré.

En général, on peut comparer ces valeurs par égalité ou inégalité. Lorsque l'on compare des valeurs de texte, chaque caractère doit correspondre exactement pour prétendre à l'égalité.

Quelques exemples :

4.1.1.2 Les nombres entiers

Une valeur d'attribut CC/PP peut être définie comme étant du type nombre entier.

La valeur littérale RDF est contrainte dans l'espace lexical défini par le type de donnée int du schéma XML [XMLSCHEMA-2]. Un éventuel attribut 'lang' sera ignoré.

Les nombres entiers peuvent être positifs, nuls ou négatifs. Ils sont représentés par une chaîne de caractères contenant une séquence de chiffres décimaux, précédés en option par un signe + ou -. Les zéros à gauche sont admis et ignorés. La valeur du nombre est toujours interprétée comme un nombre décimal (base 10). Il est RECOMMANDÉ aux implémentations de générer et prendre en charge les valeurs entières dans l'intervalle de -2147483648 à +2147483647, ou -(2^31) à (2^31-1), c'est-à-dire les entiers dont la valeur absolue peut s'exprimer comme un nombre binaire non signé de 31 bit.

Figure 4-2 : La syntaxe des nombres entiers
Signed-integer ::= ( '+' | '-' )? Unsigned-integer


Unsigned-integer ::= Digit (Digit)*

Quelques exemples :

4.1.1.3 Les nombres rationnels

Une valeur d'attribut CC/PP peut être définie comme étant du type nombre rationnel.

En d'autres termes, la valeur littérale RDF est contrainte dans l'espace lexical défini ci-dessous. Un éventuel attribut 'lang' sera ignoré.

Un nombre rationnel s'exprime comme un rapport de deux nombres entiers : deux entiers positifs, séparés par un caractère / et précédés en option par un signe + ou -.

Il est RECOMMANDÉ aux implémentations de générer et prendre en charge le numérateur d'un nombre rationnel (le premier nombre, avant le caractère /) dans l'intervalle de 0 à 2147483647 (2^31-1), le dénominateur (après le caractère /) dans l'intervalle de 1 à 2147483647.

Figure 4-3 : La syntaxe des nombres rationnels
Rational-number ::= Signed-integer ( '/' Unsigned-integer )?

Si le dénominateur est absent, on suppose une valeur de 1, c'est-à-dire on traite la valeur comme un nombre entier.

Quelques exemples :

REMARQUE : Le schéma de nombre rationnel décrit ci-dessus peut se définir dans le schéma XML [XMLSCHEMA-0] comme suit :

Figure 4-4 : Un schéma XML possible pour les nombres rationnels
<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>
          La représentation lexicale canonique de toute valeur 
          sera la forme de la valeur réduite à son plus petit
          dénominateur commun, avec '1' en dénominateur,
          le cas échéant.
        </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>

Alors que la forme ci-dessus donne une définition lexicale, remarquez qu'elle est imparfaite : elle interdit strictement les blancs. En outre, cette définition de type simple ne définit pas d'espace de valeurs numériques. L'ordre, l'égalité et la gestion implicite des opérations arithmétiques ne sont pas définis comme certains utilisateurs du type pourraient s'y attendre : les processeurs ont seulement besoin de reconnaître la définition d'une chaîne de caractères. En raison de ces déficiences, l'utilisation de nombres rationnels tels que définis ici peut nuire à l'interopérabilité. (Le groupe de travail XML-Schema pourra définir un type de donnée rationnel fonctionnel dans le futur).

4.1.2 Les données d'attributs CC/PP complexes

En plus des valeurs simples décrites ci-dessus, un attribut CC/PP peut avoir une valeur complexe exprimée sous la forme d'une ressource avec sa propre collection de propriétés RDF et leurs valeurs associées. Comme types de données particuliers représentés de cette façon sont :

Un profil NE DOIT PAS avoir plusieurs occurrences d'un seul attribut dans un seul composant. Les attributs CC/PP qui ont besoin d'avoir plusieurs valeurs devraient utiliser des ensembles ou des séquences. D'autres valeurs d'attribut CC/PP complexes peuvent être représentées par des ressources RDF arbitraires. Cette spécification n'a pas vocation à définir l'interprétation de telles valeurs.

4.1.2.1 L'ensemble de valeurs

Un ensemble contenant zéro, une ou plusieurs valeurs, toutes différentes, dont l'ordre est indifférent.

Les valeurs d'ensemble sont utiles pour représenter certains types de caractéristique d'appareil, par exemple, la gamme des polices qui peuvent être prises en charge par un client, ou les versions HTML gérées par un navigateur.

Un ensemble est représenté par un élément rdf:Bag, chaque membre de l'ensemble correspondant à une propriété de cette ressource nommée rdf:_1, rdf:_2, etc. Cette construction est décrite dans le chapitre 3 de la spécification du modèle et de la syntaxe RDF [RDF].

Figure 4-4 : Une représentation RDF de valeurs d'ensemble dans CC/PP
[(Ressource-client)]
  +--(nomAttribut)--> [<rdf:Bag>]
                          +--rdf:_1--> (valeur-membre-d-ensemble-1)
                          +--rdf:_2--> (valeur-membre-d-ensemble-2)
                          :
                          +--rdf:_n--> (valeur-membre-d-ensemble-n)

REMARQUE : La structure rdf:Bag n'exige pas que chaque valeur contenue soit unique. Un ensemble ne pouvant pas contenir de valeurs en double, chaque propriété d'une structure rdf:Bag utilisée pour représenter un ensemble doit donc avoir une valeur distincte.

Il y a une distinction claire entre un attribut avec une seule valeur et un autre dont la valeur est un ensemble de zéro, un ou plusieurs éléments :

Figure 4-5 : Un attribut avec un ensemble de valeurs contenant un seul membre
[(Ressource-client)]
  +--(nomAttribut)--> [<rdf:Bag>] --rdf:_1--> (valeur-membre-d-ensemble)

Comparez la valeur d'attribut ci-dessus, un ensemble d'un seul élément, avec la suivante qui est une valeur simple :

Figure 4-6 : Un attribut avec une valeur simple
[(Ressource-client)]
  +--(nomAttribut)--> (valeur-attribut)
4.1.2.2 La séquence de valeurs

Une séquence comporte zéro, une ou plusieurs valeurs, dont l'ordre est d'une certaine façon significatif.

Les valeurs de séquence trouvent leur utilité pour une variété de caractéristiques de client qui peuvent être ordonnées ou rangées d'une certaine façon, par exemple, une liste de préférences dans un certain ordre. Cette spécification ne définit pas la signification de l'ordonnancement des valeurs. Un vocabulaire, qui définit la valeur d'un attribut CC/PP comme une séquence de valeurs, devrait également définir la signification de leur ordonnancement au sein de la séquence.

Une séquence est représentée par une structure rdf:Seq, chaque membre de la séquence correspondant à une propriété de cette ressource nommée rdf:_1, rdf:_2, etc. Cette structure est décrite dans le chapitre 3 de la spécification du modèle et de la syntaxe de RDF [RDF].

Figure 4-7 : Une représentation RDF de valeurs de séquence dans CC/PP
[(Ressource-client)]
  +--(nomAttribut)--> [<rdf:Seq>]
                          +--rdf:_1--> (valeur-sequence-1)
                          +--rdf:_2--> (valeur-sequence-2)
                          :
                          +--rdf:_n--> (valeur-sequence-n)

Il y a une distinction claire entre un attribut avec une seule valeur et un autre dont la valeur est une séquence de zéro, un ou plusieurs éléments :

Figure 4-8 : Un attribut avec une séquence de valeurs contenant un seul membre
[(Ressource-client)]
  +--(nomAttribut)--> [<rdf:Seq>] --rdf:_1--> (valeur-sequence)

Comparez l'attribut ci-dessus, qui est une séquence contenant un seul élément, et la valeur simple montrée dans la figure 4-6 ci-dessus.

4.2 Les identificateurs d'attribut

Les noms d'attribut CC/PP prennent la forme d'une adresse URI. Tout vocabulaire CC/PP est associé à un espace de nommage XML, lequel combine une adresse URI de base à un nom d'élément (ou un nom d'attribut) XML local afin de produire une adresse URI correspondant à un nom d'attribut. Par exemple, l'adresse URI de l'espace de nommage :

http://www.w3.org/2002/11/08-ccpp-client#

... et le nom du vocabulaire de base :

type

... sont combinés pour donner l'appel d'adresse URI du nom d'attribut :

http://www.w3.org/2002/11/08-ccpp-client#type

Tout le monde peut définir et publier une extension de vocabulaire CC/PP (en supposant le contrôle administratif ou l'allocation d'une adresse URI d'espace de nommage XML). Pour être utile, un tel vocabulaire doit être interprété de la même manière par les entités communicantes. On encourage donc, quand c'est possible, d'utiliser une extension d'un vocabulaire existant et, à défaut, à publier une nouvelle définition de vocabulaire contenant les descriptions détaillées des nouveaux attributs CC/PP.

De nombreux vocabulaires d'extension seront dérivés d'applications et de protocoles existants, par exemple, WAP UAProf, les enregistrements des caractéristiques de média IETF, etc. L'Annexe E étudie quelques sources possibles pour d'autres vocabulaires CC/PP.

4.3 Le schéma du vocabulaire RDF

Les noms d'attribut sont définis et associés à un espace de nommage XML au moyen d'un schéma RDF.

L'Annexe B de ce document contient un schéma RDF qui décrit les termes à employer dans les profils CC/PP. L'Annexe C contient un exemple de schéma décrivant un vocabulaire CC/PP. L'Annexe D contient des recommandations pour la création d'un nouveau vocabulaire.

Un processeur CC/PP n'est pas tenu de comprendre et de traiter les définitions du schéma RDF. Il a simplement besoin de comprendre suffisamment la structure et le vocabulaire du profil CC/PP employé pour pouvoir faire son travail. (Un processeur capable de lire un schéma doit pouvoir gérer les profils CC/PP de diverses manières, ou en combinaison avec d'autres informations RDF, mais ce comportement n'est pas décrit par cette spécification).

5. La conformité

Ce chapitre explique comment faire une revendication de validité selon laquelle un produit est conforme à cette spécification. Tout le monde peut faire une revendication (par exemple, des vendeurs pour leurs propres produits, des tierces parties pour ces mêmes produits, des journalistes, etc.). Les revendications peuvent être publiées partout (par exemple, sur le Web ou dans la documentation d'un produit). Les prétendants sont seuls responsables de leurs revendications. Si le sujet de la revendication (par exemple, le logiciel) change après la date où celle-ci est intervenue, le prétendant est responsable de la mise à jour de la revendication. Les prétendants sont censés modifier ou rétracter une revendication si on peut démontrer que celle-ci n'est pas valide. On encourage les prétendants à se conformer à la spécification disponible la plus récente.

Il existe trois classes de produits CC/PP :

  1. les documents (par exemple, une ressource Web)
  2. les producteurs (par exemple, un client Web)
  3. les consommateurs (par exemple, un serveur Web)

5.1 La conformité du document CC/PP

Les documents peuvent exister comme ressources accessibles via un URL ou peuvent être transmis comme données dans un message. Un document est conforme à CC/PP quand il satisfait aux critères suivants :

  1. Le document DOIT être valide en RDF et sérialisé en XML, et se baser sur un ou plusieurs vocabulaires dérivés du schéma RDF dans l'Annexe B. Voir le chapitre 1.
  2. Le document DOIT employer une syntaxe valide pour les déclarations d'espace de nommage. Voir le chapitre 2.2.
  3. L'élément profil DOIT contenir un ou plusieurs composants. Voir le chapitre 2.1.
  4. Chaque composant dans le profil DOIT contenir un ou plusieurs attributs. Voir le chapitre 2.1.
  5. Les noms de composant PEUVENT se trouver dans les attributs rdf:about ou rdf:ID. Voir le chapitre 3.1.
  6. Les composants DOIVENT être indiqués à l'aide d'une propriété ccpp:component, dans lequel l'espace de nommage utilisé pour qualifier le composant se trouve dans l'espace de nommage CC/PP ou UAProf. Voir le chapitre 3.1.
  7. Les noms de composant, les types de composant et les noms d'attribut doivent tous se rapporter aux différentes adresses URI au sein d'un profil. Voir le chapitre 3.
  8. Si on donne un type de composant comme nom d'un élément et comme élément rdf:type, ceux-ci doivent se rapporter à la même adresse URI. Voir le chapitre 3.1.
  9. Les références des composants par défaut DOIVENT être des URL valides. Voir le chapitre 3.3.
  10. Les composants par défaut PEUVENT s'écrire ccpp:defaults ou ccpp:Defaults. Voir le chapitre 3.3.
  11. Les composants par défaut DOIVENT être indiqués à l'aide des propriétés ccpp:defaults ou ccpp:Defaults, pour lesquelles l'espace de nommage utilisé pour qualifier defaults ou Defaults est l'espace de nommage CC/PP ou UAProf. Voir le chapitre 3.3.
  12. Les attributs d'un composant PEUVENT contenir à la fois une valeur par défaut et une valeur appliquée, cette dernière valeur ayant préséance. Voir le chapitre 3.3.
  13. Les composants PEUVENT contenir des valeurs par défaut incorporées. Voir le chapitre 3.3.
  14. Les composants NE DOIVENT PAS contenir à la fois des valeurs par défaut incorporées et des valeurs par défaut référencées. Voir le chapitre 3.3.
  15. Les composants PEUVENT référencer un document par défaut qui n'a pas d'attribut rdf:type. Voir le chapitre 3.3.
  16. Les attributs PEUVENT avoir des ensembles de valeurs (Bag). Voir le chapitre 4.1.2.1.
  17. Les attributs PEUVENT avoir des séquences de valeurs (Seq). Voir le chapitre 4.1.2.2.
  18. Les attributs PEUVENT avoir des valeurs chaîne de caractères. Voir le chapitre 4.1.1.2.
  19. Les attributs PEUVENT avoir des valeurs entières. Voir le chapitre 4.1.1.3.
  20. Les attributs PEUVENT avoir des valeurs rationnelles. Voir le chapitre 4.1.1.4.
  21. Un composant NE DOIT PAS contenir plusieurs attributs avec le même nom. Voir le chapitre 3.2.
  22. Des attributs ayant le même nom PEUVENT se trouver dans des composants différents. Voir le chapitre 3.1.
  23. Les profils PEUVENT utiliser plusieurs espaces de nommage pour les attributs. Voir le chapitre 2.2.

5.2 La conformité du producteur CC/PP

Un producteur est conforme à CC/PP quand tout document de profil CC/PP généré par lui est un document conforme à CC/PP.

5.3 La conformité du consommateur CC/PP

Un consommateur est conforme à CC/PP quand il accepte tout document conforme à CC/PP et en extrait les informations CC/PP. Le traitement à partir d'un schéma n'est pas obligatoire et, par conséquent, la prise en compte du schéma RDF dans l'Annexe B, par les consommateurs CC/PP, est OPTIONNELLE (voir le chapitre 4.3).

Les consommateurs CC/PP se rangent dans deux catégories de conformité :

  1. Conforme : un consommateur CC/PP peut revendiquer être un consommateur conforme à CC/PP 1.0 s'il accepte n'importe quel profil CC/PP valide et en extrait les informations.
  2. Validant : un consommateur CC/PP peut revendiquer être un consommateur validant conforme à CC/PP 1.0 s'il est conforme et s'il rejette tous les profils CC/PP invalides.

REMARQUE : La mise en œuvre d'un consommateur peut être configurable et se comporter soit comme un consommateur conforme, soit comme un consommateur validant conforme, à des moments différents.

5.4 Les revendications de conformité

5.4.1 La validité

Une revendication de conformité est valide si elle est bien formée et satisfait aux critères de conformité nécessaires pour la classe de produit concernée comme indiquée ci-dessus.

5.4.2 Bien formé

Une revendication de conformité est bien formée si elle comprend les informations suivantes :

  1. la date de la revendication
  2. la classe de produit (document, producteur ou consommateur)
  3. la catégorie de consommateur (conforme ou conforme validant), le cas échéant
  4. le titre et l'adresse URI datés de ce document
  5. le nom du produit (identité), y compris une version, une date ou un autre identificateur qui identifient le produit de manière unique

6. Remerciements

Ce document est un condensé de nombreux débats au sein du groupe de travail CC/PP du W3C, avec des amendements finaux introduits par le groupe de travail Indépendance par rapport aux appareils du W3C. Les personnes suivantes ont été membres du groupe de travail CC/PP à un moment donné ou pour la plupart de la période de préparation de cette spécification et ses prédécesseurs :

Pendant la période où le groupe de travail CC/PP développait la spécification, des corrections et des éclaircissements utiles ont été suggérés par Yuichi Koike, Stuart Williams, Sean Palmer et Toni Penttinen. Merci particulièrement à Aaron Swartz pour une très complète et éclairante relecture du premier brouillon en dernier appel.

Suite au passage des travaux au groupe de travail Indépendance par rapport aux appareils, remerciements particuliers également à David Ezell (groupe de travail XML Schema), Brian McBride (groupe de travail RDF Core), Masayasu Ishikawa (groupe de travail HTML) et Lynne Rosenthal (groupe de travail Assurance qualité) pour leur aide dans la finalisation de la spécification.

Les membres suivants du groupe de travail Indépendance par rapport aux appareils ont aussi apporté leur assistance pour terminer la spécification : Stephane Boyera, Roger Gimson, Kazuhiro Kitagawa, Andreas Schade.

7. Références

7.1. Les références normatives

[XML]
Le langage de balisage extensible (XML) 1.0 (deuxième édition); Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler; recommandation du W3C du 6 octobre 2000: http://www.w3.org/TR/2000/REC-xml-20001006 Tel qu'amendé par : Errata de la deuxième édition de la spécification XML 1.0; http://www.w3.org/XML/xml-V10-2e-errata, notamment http://www.w3.org/XML/xml-V10-2e-errata#E26.
[XMLNAMESPACES]
Les espaces de nommage dans XML; Tim Bray, Dave Hollander, Andrew Layman; recommandation du W3C du 14 janvier 1999: http://www.w3.org/TR/1999/REC-xml-names-19990114/
[RDF]
Spécification du modèle et de la syntaxe du cadre de description de ressource (RDF); Ora Lassila, Ralph Swick; recommandation du 22 février 1999: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[RDFSCHEMA]
Spécification du schéma du cadre de description de ressource (RDF); Dan Brickley, R. V. Guha; recommandation candidate du 27 mars 2000: http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
[RDFXML]
Spécification de la syntaxe RDF/XML; Dave Beckett; brouillon fonctionnel du W3C: http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/

7.2. Les références informatives

[RFC2506]
RFC 2506: Procédure d'enregistrement des étiquettes de caractéristique de média; K. Holtman, A. Mutz, T. Hardie; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2506.txt
[RFC2533]
RFC 2533: Une syntaxe pour décrire les ensembles de caractéristiques de média; G. Klyne; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2533.txt
[CONNEGMATCH]
Un algorithme révisé pour la recherche de forme dans les ensembles de caractéristiques de média; G. Klyne; Internet-Draft, travail en cours: draft-klyne-conneg-feature-match-02.txt
[RFC2534]
RFC 2534: Les caractéristiques de média pour l'affichage, l'impression et la télécopie; L. Masinter, D. Wing, A. Mutz, K. Holtman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2534.txt
[UAPROF]
WAP-174: Spécification du profilage des agents utilisateurs UAProf (1999) telle qu'amendée par la note d'information sur la spécification du profilage des agents utilisateurs WAP-174_100 (2001), Wireless Application Protocol Forum, disponible à http://www.wapforum.org/what/technical_1_2.htm

Voir aussi WAP-248-UAProf Version 20-Oct-2001, disponible à 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. Partie 0 : Introduction; David C. Fallside; recommandation du W3C du 2 mai 2001: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/
[XMLSCHEMA-1]
XML Schema. Partie 1 : Structures; Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn; recommandation du W3C du 2 mai 2001: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
[XMLSCHEMA-2]
XML Schema. Partie 2 : Types de données; Paul V. Biron, Ashok Malhotra; recommandation du W3C du 2 mai 2001: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[SEMANTICTOOLBOX]
La boîte à outils sémantique : construire une sémantique par dessus XML-RDF; Tim Berners-Lee; http://www.w3.org/DesignIssues/Toolbox.html
[RFC2531]
RFC 2531: Schéma de caractéristiques du contenu pour la télécopie sur internet; 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: Format de fichier pour la télécopie sur internet; 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: Registres des codec WAVE et AVI; 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: Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation; 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: Politique de l'IETF en ce qui concerne les jeux de caractères et les langues; H. Alvestrand; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2277.txt
[RFC2396]
RFC 2396: Identifiants de ressource uniformes (URI) : syntaxe générique; T. Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2396.txt
[RFC2278]
RFC 2278: Procédures d'enregistrement des jeux de caractères de l'IANA; N. Freed, J. Postel; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2278.txt
[CCPPARCH]
Les profils de capacités/préférences composites : prérequis et architecture; Mikael Nilsson, Johan Hjelm, Hidetaka Ohto; brouillon fonctionnel du W3C du 21 juillet 2000: http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/
[RFC2616]
RFC 2616: Protocole de transfert hypertexte -- 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 de la liste de diffusion RDF-comments du W3C: http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html.
[CCPPEX]
Le protocole d'échange CC/PP;Hidetaka Ohto, Johan Hjelm; note du W3C du 24 juin 1999: http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624
[WAI]
Les directives pour l'accessibilité du contenu Web 2.0; Wendy Chisholm, Jason White, Gregg Vanderheiden; brouillon fonctionnel du W3C du 22 août 2002: http://www.w3.org/TR/2002/WD-WCAG20-20020822/
[RDFPRIMER]
Introduction à RDF; Frank Manola, Eric Miller; brouillon fonctionnel du W3C du 23 janvier 2003: http://www.w3.org/TR/2003/WD-rdf-primer-20030123/

Annexe A : Terminologie et abréviations

A.1 La terminologie

Cette annexe est INFORMATIVE.

Agent utilisateur
Un logiciel, tel un navigateur, en exécution sur l'appareil, qui agit au nom de l'utilisateur. Les utilisateurs peuvent employer des agents utilisateur différents à divers moments.
Attribut ou attribut CC/PP
Un attribut CC/PP se rapporte aux éléments de données décrivant le profil et se dénote comme une propriété RDF. Chaque attribut CC/PP est associé à une valeur, ou une liste de valeurs, ou une ressource RDF.

REMARQUE : Il se distingue beaucoup d'un attribut XML ; le terme attribut CC/PP est utilisé généralement pour renforcer cet emploi, sauf quand la signification est évidente selon le contexte.

Cache
Une zone de stockage utilisée par un serveur ou un serveur mandataire pour stocker des ressources de données qui ont été ramenées ou crées en réponse à une requête. Lorsqu'il reçoit une nouvelle requête pour une ressource de données mise en cache, le serveur, ou le serveur mandataire, peut y répondre avec la version mise en cache au lieu de rechercher ou de créer une nouvelle copie.
Capacité
Un attribut d'un émetteur ou d'un récepteur (souvent le récepteur) qui indique une aptitude à générer ou traiter un type particulier de contenu de message. Voir également Attributs CC/PP.
Caractéristique
Une propriété fonctionnelle d'un appareil ou d'une entité.
Client
Une entité qui est le compositeur original d'un profil CC/PP.
Confidentialité
Le fait de protéger le contenu d'un message contre une divulgation non autorisée.
Contenu négocié
Le contenu d'un message sélectionné par négociation de contenu.
Contenu dynamique
Un contenu généré en réponse à une requête. Cela peut être employé pour un contenu qui dépend de facteurs environnementaux fluctuants, tels que l'heure (par exemple, des valeurs boursières) ou l'endroit (par exemple, des stations proches)
Contenu invariable
Quand la forme ou le format du contenu envoyé ne dépend pas des capacités et/ou préférences du récepteur.
Contenu variable
Lorsque la forme ou le format du contenu envoyé dépendent des capacités et/ou des préférences du récepteur.
Document
Pour les besoins de cette spécification, le terme document se rapporte au contenu fourni en réponse à une requête. En utilisant cette définition, un document peut être une collection de petits documents qui, à son tour, fait partie d'un document plus grand.
Émetteur
Un composant de système (un appareil ou un logiciel) qui envoie un message.
Espace de nommage
Un qualificatif ajouté à une balise XML afin de garantir une unicité parmi des éléments XML.
Fournisseur de contenu
Un serveur qui crée du contenu en réponse à une requête.
Génération de contenu
Pour les besoins de cette spécification, le terme génération de contenu se rapporte à la génération d'un contenu approprié au profil de l'agent utilisateur à l'origine de la requête, en utilisant le profil de l'agent utilisateur comme entrée pour un moteur de génération de contenu dynamique. Les feuilles de style XSL ou autres du document sont utilisées afin d'adapter le document au profil de l'agent utilisateur à l'origine de la requête.
Indication
Une suggestion ou une préférence pour une option particulière. Alors que cette option est fortement recommandée, son utilisation n'est pas obligatoire.
Lisible par une machine
Des données décrites à l'aide de balises qui leur associent une signification (c'est-à-dire, une balise auteur servirait à décrire l'auteur du document), ce qui permet de rechercher ou combiner des données, au-delà de leur simple affichage.
Métadonnées de négociation
Des informations échangées entre l'émetteur et le récepteur d'un message par négociation de contenu afin de déterminer la variante qui devrait être transférée.
Négociation de contenu
Le mécanisme pour sélectionner la représentation adéquate lors de l'exécution d'une requête. La représentations des entités dans toute réponse peut se négocier (y compris les réponses d'erreur).
Passerelle
Un logiciel capable de raccorder des protocoles de réseau disparates. Par exemple, pour les besoins de cette spécification, le terme passerelle se rapporte à une fonctionnalité de raccordement de protocole, qui peut exister dans une passerelle autonome ou accompagner un serveur mandataire ou un serveur origine.
Préférence
Un attribut d'un émetteur ou d'un récepteur (souvent le récepteur) qui signale une préférence pour générer ou traiter un type particulier de contenu de message vis-à-vis d'une autre préférence, même si les deux sont possibles.
Processeur CC/PP
Un processeur CC/PP transforme un document CC/PP, de son format RDF en un autre format. Un processeur CC/PP reconnaît la syntaxe et la structure CC/PP, y compris les composants defaults, mais pas la sémantique de l'application associée aux attributs CC/PP des composants CC/PP.
Profil
Une instance du schéma qui décrit les capacités d'un appareil et d'un réseau particuliers. Un profil ne contient pas nécessairement tous les attributs identifiés dans le vocabulaire/schéma.
Profil d'agent utilisateur
Des informations de capacité et de préférence relatives aux possibilités de l'appareil, à l'environnement d'exploitation et de réseau, et aux préférences personnelles des utilisateurs en rapport avec la réception d'un contenu et/ou d'une ressource.
Profil de document
Les profils de document offrent le moyen de caractériser les fonctionnalités appropriées pour des catégories données d'agents utilisateurs. Par exemple, un profil pourrait inclure une prise en charge des feuilles de style, des graphiques vectoriels et des scripts, tandis qu'un autre pourrait se restreindre aux balises en HTML 3.2. Les serveurs peuvent utiliser les profils de document pour effectuer une sélection entre les variantes d'un document développées pour différentes catégories d'agents utilisateurs. Ils peuvent être utilisés pour déterminer quelles transformations appliquer lorsque de telles variantes ne sont pas disponibles. Les développeurs de contenu peuvent utiliser des profils de document pour s'assurer que leurs sites Web seront restitués comme voulu.
Récepteur
Un composant de système (un appareil ou un logiciel) qui reçoit un message.
Référentiel CC/PP
Un serveur qui stocke le profil ou les segments de profil de l'agent utilisateur de manière pérenne dans une forme qui peut être référencée par un profil ou incorporée dans un profil. Un référentiel CC/PP est typiquement un serveur Web qui fournit des profils ou des segments de profil en réponse à des requêtes HTTP.
Ressource de données
Un objet de données qui peut être transféré à travers un réseau. Les ressources de données peuvent être disponibles en plusieurs représentations (par exemple, en plusieurs langues, formats de données, tailles, résolutions, etc.) ou varier de diverses façons.
Ressource RDF
Un objet, ou un élément, décrit par des expressions RDF, est une ressource. Une ressource RDF est typiquement identifiée par une adresse URI.
Schéma, schéma RDF
Un schéma RDF dénote les ressources qui constituent les versions invariables particulières d'un vocabulaire RDF à tout instant. On l'utilise pour fournir des informations (comme l'organisation et les relations) concernant l'interprétation des déclarations dans un modèle de données RDF. Il ne comprend pas les valeurs associées aux attributs.
Sécurité
La description d'un ensemble de procédures appliquées aux échanges de données afin de garantir que les informations soient transférées exactement comme l'émetteur et le récepteur l'entendent, et pas autrement. La sécurité rassemble généralement les notions d'intégrité, d'authentification, de confidentialité et de vie privée.
Sélection de contenu
Pour les besoins de cette spécification, le terme sélection de contenu se rapporte à la sélection d'un document approprié à partir d'une liste de choix possibles ou de variantes, en comparant le profil du document avec le profil de l'agent utilisateur à l'origine de la requête.
Serveur mandataire
Un logiciel qui reçoit des requêtes HTTP et retransmet celles-ci au serveur origine (éventuellement par le biais d'un serveur mandataire ascendant) en utilisant le protocole HTTP. Le serveur mandataire reçoit la réponse du serveur origine et la retransmet au client initiateur de la requête. Outre ses fonctions de retransmission, le serveur mandataire peut modifier les requêtes comme les réponses ou offrir d'autres fonctions à valeur ajoutée. Pour les besoins de cette spécifications, le terme serveur mandataire se rapporte à la fonctionnalité de retransmission des requêtes/réponses, qui peut exister dans un serveur mandataire HTTP autonome ou accompagner une passerelle ou un serveur origine.
Serveur origine
Un logiciel qui peut répondre à des requêtes en remettant un contenu approprié ou des messages d'erreur. Le serveur origine peut recevoir des requêtes via les protocoles WSP ou bien HTTP. Les logiciels d'application qui s'exécutent sur le serveur origine remettent un contenu fait sur mesure conformément aux instructions CC/PP qui se trouvent dans le profil fourni. Pour les besoins de cette spécification, le terme serveur origine se rapporte aux capacités de génération de contenu qui peuvent exister physiquement dans un serveur Web autonome ou accompagner un serveur mandataire ou une passerelle.
Stockable en cache
Une ressource de données est dite stockable en cache si elle contient une propriété qui permet au serveur de déterminer si la ressource mise en cache correspond à une requête pour une ressource similaire.
Utilisateur
Un individu ou groupe d'individus agissant comme une seule entité. L'utilisateur est en outre qualifié d'entité qui actionne un appareil pour demander un contenu et/ou une ressource à un serveur.
Variante
L'une parmi plusieurs représentations possibles d'une ressource de données.
Vie privée
La prévention de la divulgation inattendue ou non autorisée d'informations concernant une personne. Ces informations peuvent être contenues dans un message mais aussi être déduites à partir de la forme des échanges, par exemple, le moment où se produisent les échanges, les types de ressource consultées, les parties intervenant dans l'échange, etc.
Vie privée
Une collection d'attributs qui décrivent de manière adéquate le profil CC/PP. Le vocabulaire est associé à un schéma.

A.2 Abréviations

CC/PP Composite Capabilities/Preferences Profile
CC/PPex CC/PP Exchange Protocol
CONNEG Content Negotiation Working Group, au sein de l'IETF
ER Entity-Relationship
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPex HTTP Extension Framework
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IOTP Internet Open Trading Protocol
LDAP Lightweight Directory Access Protocol
OTA Over The Air, c.-à-d. dans le réseau hertzien
RDF Resource Description Framework
RFC Request For Comments
TBD To Be Determined (N.D.T. À déterminer)
TCP/IP Transmission Control Protocol/Internet Protocol
UAProf WAP User Agent Profile
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WBXML WAP Binary XML
WML Wireless Markup Language
WSP Wireless Session Protocol
XHTML Extensible HyperText Markup Language
XSL Extensible Stylesheet Language
XML Extensible Markup Language

Annexe B : Schéma RDF de structure

Cette annexe est NORMATIVE, mais sa mise en œuvre par les processeurs CC/PP est OPTIONNELLE.

B.1 Sommaire de la hiérarchie de classes CC/PP

Figure B-1 : La hiérarchie de classes CC/PP
rdfs:Resource
    ccpp:Profile            {Profil livrable au serveur origine}
    ccpp:Component

rdfs:Literal
  ccpp:string               {Une valeur textuelle d'un attribut CC/PP}
  ccpp:integer              {Une valeur entière d'un attribut CC/PP}
  ccpp:rational             {Une valeur rationnelle d'un attribut CC/PP}

rdf:Bag                     {Un ensemble de valeurs pour un attribut CC/PP}
rdf:Seq                     {Une séquence de valeurs pour un attribut CC/PP}
   
rdf:Property
  ccpp:Property             {Une propriété appliquée à une instance ccpp:Resource}
    ccpp:Structure          {Une propriété structurelle dans un profil CC/PP}
    ccpp:Attribute          {Une propriété dénotant un attribut CC/PP}

B.2 Sommaire des propriétés CC/PP

Les propriétés de structure (instances de ccpp:Structure)

Figure B-2 : Les propriétés de structure CC/PP
ccpp:component      Domain=ccpp:Profile,         Range=ccpp:Component
ccpp:defaults       Domain=ccpp:Component,       Range=ccpp:Component

B.3 Le schéma RDF

Le noyau CC/PP et la structure des classes :

(adresse URI du schéma : http://www.w3.org/2002/11/08-ccpp-schema)

Figure B-3 : Le schéma RDF pour les classes et les propriétés de base CC/PP
<?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;'>

<!--  Définitions des classes CC/PP  -->

  <rdfs:Class rdf:about='&ns-ccpp;Profile'>
    <rdfs:label xml:lang="fr">Profil CC/PP</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
    <rdfs:comment xml:lang="fr">
      Cette classe représente tout profil complet qui peut être livré
      à un serveur origine ou à un autre système qui génère un contenu pour un client.
    </rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:about='&ns-ccpp;Component'>
    <rdfs:label xml:lang="fr">Composant de profil CC/PP</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
    <rdfs:comment xml:lang="fr">
      Une classe de base pour toute collection de valeur d'attribut CC/PP.
      Un profil de client CC/PP consiste en un ou plusieurs composants,
      utilisant en général une classe dérivée qui indique la destination
      du composant (par exemple, prf:HardwarePlatform, prf:SoftwarePlatform).
    </rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:about='&ns-ccpp;string'>
    <rdfs:label xml:lang="fr">Valeur textuelle</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
    <rdfs:comment xml:lang="fr">
      C'est la classe des valeurs littérales RDF qui représente les
      valeurs chaîne de caractères des attributs CC/PP.
    </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="fr">Valeur entière</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
    <rdfs:comment xml:lang="fr">
      C'est la classe des valeurs littérales RDF qui représente les
      valeurs entières des attributs CC/PP.
    </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="fr">Valeur rationnelle</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
    <rdfs:comment xml:lang="fr">
      C'est la classe des valeurs littérales RDF qui représente les
      valeurs rationnelles des attributs CC/PP.
    </rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:about='&ns-ccpp;Property'>
    <rdfs:label xml:lang="fr">Propriété CC/PP</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-rdf;Property'/>
    <rdfs:comment xml:lang="fr">
      ccpp:Property est la super-classe de ccpp:Structure et
      ccpp:Attribute. De ce fait, tous les arcs de propriété, qui
      ne font pas partie de l'espace de nommage du noyau RDF et
      appartiennent à un profil CC/PP, sont définis comme des
      sous-classes de ccpp:Property. Ceci permet aux environnements
      de validation de schéma avec un mélange de langages d'isoler
      les éléments CC/PP d'un graphe RDF enraciné dans une
      ressource donnée des autres attributs de cette ressource.
    </rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:about='&ns-ccpp;Structure'>
    <rdfs:label xml:lang="fr">Propriété de structure CC/PP</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
    <rdfs:comment xml:lang="fr">
      Toutes les propriétés qui sont des éléments structuraux d'un
      profil CC/PP sont définies comme instances de ccpp:Structure.
      Ceci permet de distinguer les éléments combinants de structure
      des attributs dans un environnement obéissant à un schéma.
    </rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:about='&ns-ccpp;Attribute'>
    <rdfs:label xml:lang="fr">Attribut CC/PP</rdfs:label>
    <rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
    <rdfs:comment xml:lang="fr">
      Toutes les propriétés qui décrivent les capacités ou préférences
      d'un client dans un profil CC/PP devraient être définies comme
      instances de ccpp:Attribute. Ceci permet de distinguer les éléments
      combinants de structure d'un profil des caractéristiques du client
      dans un environnement obéissant à une validation par schéma.
    </rdfs:comment>
  </rdfs:Class>


<!--  Définitions des propriétés de structure CC/PP -->
<!--  Description du profil client de base  -->

  <ccpp:Structure rdf:about='&ns-ccpp;component'>
    <rdfs:label xml:lang="fr">Propriété de composant CC/PP</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Client-profile'/>
    <rdfs:range  rdf:resource='&ns-ccpp;Component'/>
    <rdfs:comment xml:lang="fr">
      Indique un composant de profil client de niveau supérieur.
    </rdfs:comment>
  </ccpp:Structure>

  <ccpp:Structure rdf:about='&ns-ccpp;defaults'>
    <rdfs:label xml:lang="fr">Propriétés CC/PP par défaut</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;Component'/>
    <rdfs:comment xml:lang="fr">
      Cette propriété désigne un objet Component qui contient des
      propriétés par défaut pour un autre composant. C.-à-d.,
      tous les attributs absents de la ressource sujet, mais
      présents dans la ressource objet, peuvent être incorporés
      depuis l'objet dans le profil CC/PP résultant.
    </rdfs:comment>
  </ccpp:Structure>

  <ccpp:Structure rdf:about='&ns-ccpp;Defaults'>
    <rdfs:label xml:lang="fr">Propriétés CC/PP par défaut</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="fr">
      Même chose que 'defaults'.
      Défini comme sous-propriété pour rétrocompatibilité avec UAProf.

      Son usage est déconseillé : utiliser plutôt 'defaults'.
    </rdfs:comment>
  </ccpp:Structure>
</rdf:RDF>

Annexe C : Vocabulaire d'attributs CC/PP pour l'impression et l'affichage

Cette annexe est OPTIONNELLE et INFORMATIVE.

Les concepteurs d'applications CC/PP, qui auraient besoin de décrire de telles caractéristiques, sont encouragés à employer ce vocabulaire plutôt que de définir de nouveaux termes. Ce vocabulaire s'inspire en partie des travaux du groupe de travail sur l'enregistrement des caractéristiques de média de l'IETF (CONNEG) [RFC2534].

Les noms d'attribut de client définis ci-dessous peuvent être utilisés pour identifier certaines caractéristiques communes associées aux appareils clients qui impriment ou affichent des informations visuelles, comme du texte ou des images. Elles sont décrites à l'aide de parties locales d'un espace de nommage XML, qui sont en outre qualifiées par l'identificateur d'espace de nommage XML http://www.w3.org/2002/11/08-ccpp-client. (Ces attributs s'appliquent aux capacités présentées du client plutôt qu'à un composant ou un aspect internes particulier d'un système client).

deviceIdentifier :
(Type de donnée de la valeur : valeur de type string) Une adresse URI qui sert d'identificateur du type de l'appareil client ou de l'agent utilisateur.
type :
(Type de donnée de la valeur : ensemble de valeurs de type string) Un type de contenu MIME pouvant être accepté et présenté par un client. Il est similaire en principe à l'en-tête Accept: HTTP, mais ne spécifie qu'un seul type de contenu MIME sans les paramètres content-type associés. Plusieurs content-type acceptés peuvent être décrits par une valeur prenant la forme d'un ensemble de valeurs de chaînes content-type. Au besoin, les paramètres content-type peuvent être exprimés par d'autres attributs CC/PP.
schema :
(Type de donnée de la valeur : ensemble de valeurs de type string) Une adresse URI qui identifie un schéma reconnu par le client. Le schéma peut être une définition de type de document (DTD) XML [XML], un schema XML [XMLSCHEMA-1], un schéma RDF [RDFSCHEMA] ou toute autre structure de document pouvant s'appliquer et être identifiée par une adresse URI. Une valeur schema précise tout type de document acceptable indiqué par l'attribut Type, mais sa signification ne doit pas dépendre de la valeur de Type. Ce sera typiquement utilisé pour indiquer des DTD XML ou des schémas particuliers reconnus à l'intérieur de documents de type text/xml ou application/xml.
charWidth :
(Type de donnée de la valeur : valeur de type integer) Pour un appareil affichant du texte (type='text/*'), la largeur de l'affichage du caractère. Pour les affichages avec police non proportionnelle, le nombre de cellules d'affichage. Pour les affichages avec police non proportionnelle employés typiquement en Asie orientale, le nombre de cellules d'affichage demi-chasse (les caractères idéographiques et d'autres caractères pleine chasse occupent généralement deux cellules d'affichage). Pour les affichages avec police proportionnelle, la largeur de l'affichage en en (un en est une unité typographique qui a la largeur d'un tiret ou de la lettre n).
charHeight :
(Type de donnée de la valeur : valeur de type integer) Pour un appareil affichant du texte (type='text/*'), le nombre de lignes de texte pouvant être affiché (c.-à-d. la hauteur d'affichage en caractères).
charset :
(Type de donnée de la valeur : ensemble de valeurs de type string, selon [RFC2278]) Pour un appareil prenant en charge du texte, un codage de caractères pouvant être traité (valeurs selon le paramètre MIME charset sur content-type type='image/*'). REMARQUE : le terme charset est historiquement mal nommé et n'indique pas forcément un répertoire de caractères pouvant être affichés mais simplement un codage. Dans certains cas, le codage peut néanmoins impliquer un répertoire.
pix-x :
(Type de donnée de la valeur : valeur de type integer) Pour un appareil affichant des images (type='image/*'), le nombre de pixels horizontaux pouvant être affichés.
pix-y :
(Type de donnée de la valeur : valeur de type integer) Pour un appareil affichant des images (type='image/*'), le nombre de pixels verticaux pouvant être affichés.
color :
(Type de donnée de la valeur : valeur de type string, selon [RFC2534]) Pour les appareils affichant du texte et des images, une indication des capacités de couleurs (selon RFC 2534 [RFC2534], les valeurs possibles sont "binary", "grey", "limited", "mapped" et "full"). REMARQUE : L'attribut color fournit une indication très succinte des capacités de couleurs, qui sont suffisantes pour une gamme d'applications simples et qui peuvent être raffinées par d'autres attributs lorsqu'on doit décrire plus précisément les capacités.

Les propriétés des attributs du client (instances de ccpp:Attribute)

Figure C-1 : Les propriétés du vocabulaire du client 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

Le schéma pour le vocabulaire du client

(adresse URI du schéma : http://www.w3.org/2002/11/08-ccpp-client)

Figure C-2 : Le schéma RDF pour le vocabulaire du client
<?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;'>

<!--  Définitions des propriétés d'attribut CC/PP  -->

  <!-- Ces propriétés représentent un vocabulaire commun          -->
  <!-- disponible aux applications qui ont besoin d'indiquer      -->
  <!-- les caractéristiques communes indiquées par ces attributs. -->
  <!-- Elles servent d'exemple pour la manière de définir un      -->
  <!-- nouveau vocabulaire d'attributs dans un profil CC/PP.      -->

  <ccpp:Attribute rdf:about='&ns-ccpp-client;deviceIdentifier'>
    <rdfs:label xml:lang="fr">Identificateur d'appareil client</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;string'/>
    <rdfs:comment xml:lang="fr">
      Une adresse URI identifiant le type d'appareil client ou d'agent utilisateur.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;type'>
    <rdfs:label xml:lang="fr">Type de contenu MIME</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-rdf;Bag'/>
    <rdfs:comment xml:lang="fr">
      Une chaîne représentant un type de contenu MIME, ou un ensemble
      de telles chaînes, indiquant les types de contenu MIME reconnus.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;schema'>
    <rdfs:label xml:lang="fr">Identificateur de schéma</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;string'/>
    <rdfs:comment xml:lang="fr">
      Une adresse URI identifiant un langage ou un DTD reconnus
      par le client, ou un ensemble de telles adresses URI.

      Des valeurs particulières de cet attribut peuvent s'appliquer
      à certains types de contenu MIME. Par exemple, une adresse URI
      associé à une ressource contenant un DTD XML ne s'appliquera
      en général qu'aux types de contenu 'text/xml' ou 'application/xml'.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;charWidth'>
    <rdfs:label xml:lang="fr">Largeur d'affichage du caractère</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;integer'/>
    <rdfs:comment xml:lang="fr">
      Pour les affichages de caractères, le nombre de caractères
      pouvant être restitués à travers l'écran. Pour les affichages
      avec une police proportionnelle, c'est la largeur d'affichage
      en unité typographique 'em'.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;charHeight'>
    <rdfs:label xml:lang="fr">Hauteur d'affichage du caractère</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;integer'/>
    <rdfs:comment xml:lang="fr">
      Pour les affichages de caractères, le nombre de rangées de
      caractères affichables.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;charset'>
    <rdfs:label xml:lang="fr">Codage du jeu de caractères</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-rdf;Bag'/>
    <rdfs:comment xml:lang="fr">
      Pour les affichages de caractères, les valeurs MIME 'charset'
      qui sont reconnues.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;pix-x'>
    <rdfs:label xml:lang="fr">Largeur d'affichage en pixels</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;integer'/>
    <rdfs:comment xml:lang="fr">
      Pour les affichages matriciels, la largeur de l'affichage en pixels.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;pix-y'>
    <rdfs:label xml:lang="fr">Hauteur d'affichage en pixels</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;integer'/>
    <rdfs:comment xml:lang="fr">
       Pour les affichages matriciels, la hauteur de l'affichage en pixels.
    </rdfs:comment>
  </ccpp:Attribute>

  <ccpp:Attribute rdf:about='&ns-ccpp-client;color'>
    <rdfs:label xml:lang="fr">Capacités de couleurs de l'affichage</rdfs:label>
    <rdfs:domain rdf:resource='&ns-ccpp;Component'/>
    <rdfs:range  rdf:resource='&ns-ccpp;string'/>
    <rdfs:comment xml:lang="fr">
      Pour les appareils d'affichage ou d'impression, une indication
      des capacités de restitution des couleurs :
      binary  - indique une couleur binaire (noir et blanc, ou similaire).
      grey    - indique une capacité d'échelle de gris, qui suffit à distinguer
                les niveaux d'une photographie monochrome.
      limited - indique un nombre limité de couleurs distinctes, mais qui
                ne suffit pas pour l'affichage d'une photographie
                en couleur (par exemple, un traceur à plume, une imprimante
                en hautes lumières ou un écran limité).
      mapped  - indique un affichage à partir d'une palette de couleurs,
                avec suffisamment de niveaux et de contrôle pour
                l'affichage grossier d'une photographie en couleur.
      full    - indique une capacité d'affichage des couleurs complète.
    </rdfs:comment>
  </ccpp:Attribute>

</rdf:RDF>

Annexe D : Conseils pour la création d'un vocabulaire

Cette annexe est INFORMATIVE.

L'idée fondamentale dans la conception de CC/PP, c'est de pouvoir définir des nouveaux attributs de client, au besoin, par l'introduction de nouveaux vocabulaires.

De la même façon, on peut introduire de nouvelles relations au travers de nouveaux éléments de vocabulaire, bien que l'introduction de ceux-ci nécessite beaucoup de soins pour assurer leur définition sémantique adéquate et cohérente. Le principe général est que des processeurs CC/PP, indépendamment de l'application, puissent reconnaître et manipuler les relations CC/PP sans pour autant reconnaître obligatoirement les attributs CC/PP auxquels elles se rapportent.

On recommande l'utilisation d'un schéma RDF, avec des documents d'accompagnement, pour définir un éventuel nouveau vocabulaire. L'annexe précédente est un exemple de cette approche.

Les nouveaux vocabulaires sont introduits au travers d'espaces de nommage XML. Leurs relations avec les autres éléments de vocabulaire CC/PP peuvent être définies par de nouvelles déclarations de schéma RDF (qui doivent nécessairement augmenter le schéma RDF de base pour le vocabulaire CC/PP donné en Annexe C de ce document).

D.1 Le format de base pour tous les éléments de vocabulaire

Tous les éléments de vocabulaire utilisés par CC/PP sont des adresses URI et des identificateurs de fragment optionnels, employés comme identificateurs d'arc de propriété RDF. On ne devrait pas utiliser d'adresses URI relatives. Les élements de vocabulaire utilisés pour des buts différents sont généralement associés à des espaces de nommage XML distincts. Certaines classes de base RDF sont définies de telle sorte qu'un processeur reconnaissant les schémas puisse approfondir l'analyse d'un profil CC/PP et séparer les éléments de profil CC/PP des éventuelles autres déclarations de ressource, apparaissant en tant que profil CC/PP dans le même graphe RDF.

Toutes les propriétés utilisées comme attributs CC/PP doivent être des instances de la classe ccpp:Attribute, elle-même une sous-classe de rdf:Property. (C'est-à-dire que le schéma définissant les propriétés d'attribut CC/PP devrait les définir comme instances de ccpp:Attribute. Un processeur reconnaissant les schémas pourra alors distinguer les propriétés faisant partie d'un profil CC/PP de celles qui peuvent faire partie d'une valeur d'attribut).

Chaque attribut CC/PP est associé à un composant de profil (par exemple, HardwarePlatform, SoftwarePlatform, etc.) et employé comme propriété d'une instance de la ressource de composant appropriée. Tous les types de ressource de composant de ce genre sont des sous-classes de ccpp:Component. On peut introduire de nouvelles classes basées sur ccpp:Component pour de nouveaux types de vocabulaire d'attributs, mais on recommande fortement d'utiliser un type ccpp:Component existant, le cas échéant.

REMARQUE : Un processeur CC/PP simple n'est pas tenu de reconnaître les schémas et sa mise en œuvre n'a pas besoin de connaître la classe RDF d'un attribut ou d'une ressource, le profil n'est pas obligé non plus de transporter des informations de type RDF. Les discussions portant sur les classes et les traitements à partir de schémas sont liées aux possibles développements futurs de processeurs RDF génériques capables de gérer CC/PP et d'autres vocabulaires et schémas RDF, éventuellement mélangés dans le même document. Pour que de tels développements soient envisageables, il est important de prendre en compte les questions de classe et de schéma dans la conception de CC/PP, même si les processeurs CC/PP simples n'ont pas besoin de prendre en compte tout cela.

D.2 L'utilisation des espaces de nommage XML

Tous les attributs CC/PP doivent être associés à une adresse URI identificatrice d'un espace de nommage XML entièrement résolvable. (On ne devrait pas utiliser d'adresses URI relatives ou d'adresses URI dont l'interprétation peut dépendre du contexte de leur utilisation).

REMARQUE : On anticipe qu'une adresse URI d'espace de nommage, utilisé pour des attributs CC/PP, puisse aussi servir à identifier un schéma RDF (ou autre) relatif à ces attributs. Cependant, cette utilisation est hors du propos de cette spécification.

En général, les nouveaux attributs CC/PP seront associés à un nouvel espace de nommage, lequel sert (entre autres choses) à distinguer les utilisations différentes possibles des mêmes parties locales du nom d'attribut. Par exemple, les expressions a:chose et b:chose nomment deux attributs distincts tant que les préfixes a: et b: sont associés à des adresses URI d'espace de nommage différents.

D.3 Les principes pour la définition de nouveaux attributs

D.3.1 Réutiliser si possible les vocabulaires existants

La réutilisation de vocabulaires existants, le cas échéant, met à profit le travail qui a déjà été accompli et réduit la probabilité d'apparition de noms d'attribut différents qui approchent mais ne signifient pas tout à fait la même chose.

Remarqez qu'on peut librement mêler des noms utilisant des espaces de nommage différents dans un profil, de sorte que le besoin d'une fonctionnalité supplémentaire ne justifie pas la définition d'un nouveau vocabulaire complet.

D.3.2 Le type de valeur de l'attribut et son interprétation

Les définitions d'attribut devraient indiquer le type et l'interprétation de la valeur associée. En définitive, ce sont les applications émettrices et réceptrices qui s'arrangeront sur la façon d'interpréter une valeur d'attribut particulière.

Si possible, pour favoriser le traitement et la compatibilité avec d'autres cadres syntaxiques, les valeurs d'attribut devraient se baser sur l'un des types de données décrits dans le chapitre 4.1 de ce document.

Quand un attribut exprime une quantité associée à un client, l'unité de cette quantité devrait clairement apparaître dans la définition de l'attribut. Il n'existe pas de mécanisme permettant d'indiquer l'unité dans laquelle la valeur d'un attribut est exprimée.

D.3.3 Une interprétation indépendante des autres valeurs d'attribut

La signification de chaque attribut doit être définie isolément des autres attributs : aucun attribut ne doit avoir une signification qui change en fonction de la valeur d'un quelconque autre attribut. Par exemple, un attribut hypothétique nommé largeurPage, doit toujours s'exprimer à l'aide des mêmes unités : il n'est pas acceptable que cet attribut s'exprime en caractères pour une classe d'appareil, en millimètres pour une autre et en pouces pour encore une autre. (Remarquez qu'il est toujours admis de définir un attribut qui serait non interprétable en l'absence de la définition d'un autre attribut, l'important ici étant que l'ajout d'un nouvel attribut ne devrait pas invalider la connaissance d'un client déductible d'attributs définis précédemment).

Les attributs peuvent se définir en couches, de sorte que des capacités simples (par exemple, une aptitude à gérer les images photographiques en couleur) puissent être décrites par un attribut simple et, éventuellement, des attributs supplémentaires afin de fournir des capacités plus précises ou inhabituelles (par exemple, des capacités de contretypage exact des couleurs).

D.3.4 Les conventions de nommage des attributs

Les attributs sont des propriétés RDF. La spécification du modèle et de la syntaxe RDF [RDF], Annexe C, recommande l'emploi d'un style en casse alternée pour les noms de propriété RDF (en commençant par une lettre minuscule, les mots suivants composant le nom commençant par une lettre majuscule et sans ponctuation interne). Nous recommandons l'emploi de ce style pour les nom d'attribut CC/PP, sauf quand une certaine autre forme est préférée pour des raisons de compatibilité avec d'autres systèmes (tel que certains attributs d'impression et d'affichage compatibles avec CONNEG décrits ci-dessous).

Les noms de classe RDF utilisés dans les profils CC/PP commencent de préférence par une lettre majuscule.

D.3.5 Les attributs devraient avoir une applicabilité particulière

Si un attribut est défini pour une gamme d'applicabilité étendue, des problèmes peuvent survenir lorsqu'un utilisateur essaie d'appliquer un seul attribut à des parties différentes d'un profil.

Un attribut, défini de manière trop générale, pourrait faire l'objet de problèmes touchant à la vie privée et à la sécurité quand il est appliqué dans des circonstances variées. Par exemple, le fait de disposer d'une capacité de synthèse vocale sur un appareil de type téléphone portable peut généralement être considéré comme une caractéristique utile, mais une fonctionnalité similaire dans un ordinateur personnel pourrait signaler une déficience physique personnelle. Ainsi, la combinaison d'une aptitude à la synthèse vocale et de l'utilisation d'une plate-forme de type ordinateur personnel pourrait suggérer des informations privées qui ne seraient pas nécessairement associées à l'une des caractéristiques prises séparément.

D.4 Les interactions de protocoles

Dans certains cas, il peut y avoir chevauchement entre des vocabulaires CC/PP et un protocole particulier avec lequel CC/PP est utilisé. Par exemple, entre le vocabulaire client charset et l'en-tête accept-charset: de HTTP. À certains égards, l'indépendance vis-à-vis des protocoles de CC/PP rend ceci inévitable, au point que les protocoles existants peuvent voir réduire leurs facilités de négociation de contenu.

Pour la conception de vocabulaires, évitez de définir des caractéristiques susceptibles de faire partie du comportement particulier d'un protocole. Tout ce qui décrit ou se rapporte à un mécanisme de transfert au lieu de ce qui est transféré est à proscrire. Par exemple, la prise en charge d'une caractéristique similaire aux connections persistentes HTTP ne devrait pas apparaître dans un profil, parce que (a) c'est une caractéristique propre à un protocole et (b) ça n'aide pas réellement le serveur origine à sélectionner un contenu approprié pour le client.

De la même façon, lors de la définition des liaisons de protocole pour utiliser CC/PP, on devrait considérer et spécifier les interactions avec les mécanismes de négociation existants. L'explication détaillée de ce sujet n'est pas l'objet de cette spécification.

Annexe E : Passage en revue des vocabulaires applicables

Cette annexe est INFORMATIVE.

Ce chapitre introduit quelques sources possibles de propriétés pouvant faire l'objet d'une description par des vocabulaires d'attributs CC/PP. Ce chapitre non normatif est inclus pour donner une idée des sortes de caractéristique client qui pourraient être apportées par CC/PP.

E.1 L'enregistrement des caractéristiques de média de l'IETF (CONNEG)

L'IETF a défini un registre IANA pour les étiquettes de caractéristique de média [RFC2506] et une syntaxe [RFC2533] pour les expressions de style relationnel qui utilisent ces étiquettes pour décrire les caractéristiques de média côté client et côté serveur. Un vocabulaire commun réduit a été défini [RFC2534] et utilisé comme point de départ pour le vocabulaire commun du client CC/PP. Le groupe de travail Télécopie sur internet de l'IETF a également créé d'autres enregistrements pour décrire les capacités des télécopieurs [RFC2531].

Le document RFC 2506 [RFC2506] définit trois sortes d'étiquette de caractéristique de média :

Il existe actuellement une proposition en vue de créer un espace de nommage URN pour les registres IANA. Cela créerait un mécanisme permettant d'utiliser directement les étiquettes de caractéristiques enregistrées par l'IANA comme adresse URI dans les expressions CC/PP.

On peut utiliser les étiquettes de caractéristiques non enregistrées dans les expressions CC/PP, en supprimant la chaîne de tête u. et en ne gardant que l'adresse URI résultante.

Toutes les étiquettes et valeurs de caractéristique de média peuvent être exprimée en CC/PP, mais les profils CC/PP ne peuvent pas tous être exprimés sous forme d'étiquettes et de valeurs de caractéristique de média. En particulier, les valeurs textuelles CC/PP sont sensibles à la casse alors que les valeurs de caractéristique de média ne le sont pas. Les valeurs de caractéristique de média peuvent correspondre aux valeurs textuelles CC/PP par application d'une convention de normalisation de la casse (par exemple, une conversion en lettres minuscules).

Cette version de CC/PP ne dispose pas de mécanismes correspondant à ceux du cadre de caractéristique de média IETF, qui pourraient être utilisés dans CC/PP pour déclarer des capacités par comparaison avec des valeurs fixes (par exemple, pix-x<=640) et des valeurs d'attribut apparaissant dans certaines combinaisons (par exemple, "pix-x=640" AND "pix-y=480" OR "pix-x=800" AND "pix-y=600"). Un travail futur pourra définir de tels mécanismes.

E.2 WAP UAProf

La spécification UAProf [UAPROF] du WAP Forum est conçue afin de permettre aux appareils mobiles sans fil de déclarer leurs capacités aux serveurs de données et aux autres composants du réseau.

La conception de UAProf fait déjà appel à RDF. De ce fait, ses éléments de vocabulaire utilisent le même format de base que celui de CC/PP.

Le modèle de CC/PP suit celui de UAProf, en cela que chaque propriété d'agent utilisateur est définie comme appartenant à un composant dans un ensemble restreint, chacun de ces composants correspondant à un aspect d'un appareil agent utilisateur. Par exemple :

Bien que son schéma RDF soit plus prescriptif en ce qui concerne l'utilisation des classe et des propriétés que UAProf, la conception de CC/PP le rend rétrocompatible. L'objectif étant que des profils UAProf valides soient aussi des profils CC/PP valides ; les profils CC/PP ne sont pas forcément tous des profils UAProf valide.

E.3 TIFF

Le format TIFF est un format de fichier d'encapsulation d'image matricielle, développé et maintenu par Adobe Systems [TIFF]. C'est aussi la base du format de fichier normalisé pour la télécopie par internet [RFC2301].

Tout comme les données d'image pixélisée de plusieurs formats de codage et compression, le format TIFF gère un grand nombre d'options pour les diverses sortes d'informations propres aux images. Ces options sont susceptibles d'une candidature au rang d'attribut CC/PP. Nombre des propriétés TIFF se rapportant aux capacités de manipulation d'image sont déjà définies comme étiquettes dans l'espace CONNEG et font partie des travaux sur la télécopie par internet [RFC2531] ; celles-ci seraient certainement mieux référencées à l'aide d'adresses URI basées sur leur nom d'étiquette CONNEG.

E.4 WAVE

Le format WAVE est un format d'encapsulation pour des données audio, développé et maintenu par Microsoft [MULTIMEDIA].

Il existe un registre des codecs audio reconnus par WAVE qui pourraient être utilisés comme attributs CC/PP [RFC2361].

Les travaux en cours de l'IETF sur la messagerie vocale (VPIM/IVM) pourraient amener la création d'étiquettes de registre de caractéristiques de média IETF utilisables par les profils CC/PP au moyen des mêmes mécanismes que ceux décrits dans le chapitre E.1 ci-dessus.

E.5 MPEG-4

Le format MPEG-4 est un format d'encapsulation pour des données vidéo, éventuellement combinées à des données audio, développé et maintenu par le groupe de travail MPEG de l'ISO [MPEG].

E.6 MPEG-7

Le format MPEG-7 est un format de métadonnées pour les informations associées aux images, à la vidéo, à l'audio et d'autres données, actuellement en développement par groupe de travail MPEG de l'ISO [MPEG-7].

E.7 PWG

Le Printer Working Group défini des attributs et des capacités applicables aux appareils d'impression [PWG]. Une partie de ce travail est incorporée dans le protocole d'impression internet (IPP) de l'IETF [RFC2566].

E.8 Salutation

Salutation est un systeme de protocole et d'identification pour les appareils communiquants, principalement dans un environnement local LAN, développé et maintenu par le Salutation Consortium [SALUTATION]. Les mécanismes d'identification des capacités des appareils incluent probablement de nombreux éléments qui pourraient être utilisés comme attributs CC/PP.

Annexe F : Applications CC/PP

Cette annexe est INFORMATIVE.

CC/PP un cadre de format conçu pour une utilisation dans le contexte d'un environnement applicatif ou opérationnel global. Cette spécification ne définit pas comment utiliser CC/PP avec un protocole ou une application particuliers.

Cette annexe met en évidence d'autres questions que les développeurs d'applications doivent prendre en compte dans leur conception. Plusieurs de ces question ont été abordées par une spécification de protocole applicable utilisée pour acheminer les profils CC/PP.

Pour une utilisation efficace du cadre CC/PP, les règles d'exploitation de l'environnement global doivent spécifier :

Peu de principes de protocole entrent dans la conception de CC/PP. Bien que destiné à être largement indépendant d'un protocole, CC/PP a fait l'objet d'une attention particulière en ce qui concerne son utilisation avec le protocole HTTP pour la recherche de ressources Web.

F.1 Description du traitement des requêtes HTTP

On envisage l'utilisation de CC/PP avec HTTP de la manière suivante.

(Il ne s'agit pas de la spécification d'un protocole, mais simplement d'une indication des sortes de flux d'informations envisagées. La définition d'un protocole afin d'acheminer des informations CC/PP fait l'objet d'un effort séparé [CCPPEX]).

Figure F-1 : Le traitement d'une requête HTTP
  +------+ (5)       (4) +----------+               +-------+
  |Ag.Ut.| <==réponse==  | Serveur  | <==réponse==  |Serveur| <====> (Données de)
  |client| ===requête==> |mandataire| ===requête==> |origine| (3)    (ressource )
  +------+ (1)   |       +----------+ (2)   |       +-------+
                 |                          |
                 v                          v
(Client) <--- (Profil client) <----- (Profil requis)
(défaut)       + valeurs locales            |
                                            v
                   (Mandataire) <--- (Profil mandataire)
                     (défaut)         + valeurs locales
  1. Le client envoie une requête HTTP, accompagné d'un profil client CC/PP. Le profil client peut contenir des références à des profils par défaut décrivant une gamme de capacités communes pour le client concerné (par exemple, une combinaison particulière ordinateur/système d'exploitation/navigateur, ou bien un modèle particulier d'appareil mobile) et des valeurs consistant en variations à partir du profil par défaut.
  2. La requête HTTP peut passer au travers d'un pare-feu/serveur mandataire qui (a) impose des contraintes sur les sortes de contenu auxquelles on peut accéder ou (b) peut adapter d'autres formes de contenu aux capacités du client demandeur. Ce serveur mandataire augmente le profil CC/PP d'une description de ces contraintes et adaptations, puis renvoie le tout avec la requête HTTP au serveur origine. La requête peut passer au travers de plusieurs serveurs mandataires de ce genre.
  3. Le serveur origine reçoit la requête et interprète le profil CC/PP. Il sélectionne et/ou génère un contenu qui correspond aux capacités combinés du serveur mandataire et du client décrites dans le profil. Le tout est renvoyé, dans une réponse HTTP, au dernier serveur mandataire dans la chaîne de la requête.
  4. Si nécessaire, le serveur mandataire exerce les éventuelles adaptations de contenu et toutes les autres fonctions pour lesquelles il est conçu. La réponse et le contenu qui en résultent sont passés en retour au client demandeur.
  5. Le client reçoit la réponse HTTP et en présente le contenu.

REMARQUE : CC/PP et les diverses en-têtes accept-* HTTP se recoupent parfois. Une spécification de protocole pour l'utilisation de CC/PP et HTTP doit indiquer comment ces en-têtes accept-* peuvent s'utiliser et comment elles interagissent avec les profils CC/PP.

F.2 Les principes de protocole pour le comportement d'un serveur mandataire

Le cadre de description des comportements des serveurs mandataires donne quelques principes pour le protocole utilisé pour acheminer un profil CC/PP :

Annexe G : Compatibilité RDF

Cette annexe est INFORMATIVE.

Cette spécification CC/PP est fondée sur la spécification du modèle et de la syntaxe du cadre de description des ressource (RDF) [RDF], une recommandation du W3C. Cette version de RDF ne possède pas un typage explicite des données littérales. Les spécifications RDF sont en cours de révision au moment de la rédaction de la présente spécification. La spécification RDF révisée (Spécification de la syntaxe RDF/XML (révisée)), qui n'a pas atteint le statut de recommandation à l'heure de la rédaction, introduit la possibilité de spécifier le type de donnée de schéma XML d'une valeur littérale. Cette annexe souligne les implications pour les personnes chargés de mettre en œuvre CC/PP dans un but de compatibilité avec cette proposition ajoutée à RDF. Il faut souhaiter qu'une version future de la spécification CC/PP propose les moyens d'utiliser un typage de données explicite dans la définition des profils CC/PP.

G.1 Le typage de données implicite

Dans cette spécification, la valeur d'un attribut CC/PP contenu dans un profil CC/PP est, selon la terminologie RDF (révisée) [RDFPRIMER], un littéral simple RDF. Un schéma de vocabulaire CC/PP (tel l'exemple dans l'Annexe C), défini en fonction des types simples introduits dans le schéma CC/PP (Annexe B), peut fournir d'autres informations de type pour ces attributs. Une application consommatrice de profil CC/PP peut utiliser le schéma de vocabulaire (soit en interprétant directement les données du schéma, soit, pour des vocabulaires connus, en incorporant les informations équivalentes dans l'application) pour vérifier la validité des données fournies par un profil et contretyper ces données dans les types de données du langage de programmation.

G.2 Le typage de données explicite

Le brouillon fonctionnel RDF révisé gère le typage de données XSD (XML Schema Datatypes). Quand le typage de données explicite sera adopté, la spécification CC/PP pourrait être révisés afin de permettre à une valeur d'attribut dans un profil CC/PP d'être représentée comme littéral typé RDF. Dans la sérialisation XML d'un littéral typé RDF, le type de la valeur littérale est spécifié en attribut de l'élément contenant cette valeur littérale. Auquel cas, une application consommatrice de profil CC/PP pourrait utiliser cette information de type pour interpréter la valeur d'attribut CC/PP, sans demander un accès à d'autres informations de schéma du vocabulaire.

Dans le futur, il est possible que, pour des raisons de rétrocompatibilité, un consommateur de profil CC/PP doive être capable de manipuler des attributs CC/PP utilisant l'un ou l'autre typage de données.

Annexe W : Historique des révisions

20001218 Document créé à partir de la fusion des documents de l'architecture, de la structure et du vocabulaire.
20001219 Déplacé des éléments concernant le vocabulaire et les serveurs mandataires du chapitre 3 au chapitre 4. Diverses petites rédactions.
20010109 Diverses corrections rédactionnelles. Fusion des annexes concernant les vocabulaires pour l'impression et l'affichage. Supprimé quelques références de source de vocabulaire. Ajouté des exemples XML à plusieurs des exemples de graphe RDF. Réorganisé le matériel des chapitres 2 et 3, en déplaçant les détails techniques au chapitre 3. Déplacé la présentation des applications CC/PP dans une nouvelle annexe. Donné des numéros aux figures.
20010112 Autres remarques rédigés en révisant les groupes. Corrigé quelques erreurs de schéma. Déplacé le sommaire du schéma de client à l'annexe C. Mis à jour la référence et l'adresse URI d'espace de nommage UAProf. Ajouté les membres du groupe de travail aux remerciements.
20010116 Autres remarques rédigés en révisant les groupes. Ajouté la citation de RFC2119. Changé quelques instances de rdf:Bag en notation {...} dans les descriptions de graphe. Utilisé ccpp:defaults dans les exemples de manière cohérente. Ajouté un texte à propos des références aux valeurs par défaut externes. Ajouté des points au sujet des adresses URI et des mécanismes de résolution autorisés dans l'annexe F. Changé la notation de la figure 3-12. Chapitre 4.1, essayé de clarifier le comportement obligatoire. Chapitre 4.3, ajouté un paragraphe sur la prise en compte du schéma RDF. Annexe D, ajouté un texte recommandant l'utilisation du schéma RDF pour définir des vocabulaires. Chapitre 3.1.1, ajouté un texte au sujet de l'utilisation des propriétés rdf:type pour les ressources ccpp:Component. Annexe B, retiré les références à ccpp:Set et ccpp:Value.
20010118 Validé les exemples RDF avec SiRPAC (facilité en ligne du W3C) et corrigé les erreurs détectées. Réparé quelques liens externes.
20010129 Ajouté une table des matières hyperliée (grâce à "htmltoc" de Earl Hood)
20010223 Publié en tant que premier brouillon fonctionnel.
20010315 Ajouté un chapitre en dernier appel. Changé quelques mots. Publié en tant que brouillon fonctionnel en dernier appel.
20010425 Intégré les remarques de révision sur la rédaction. Expliqué l'utilisation des noms des adresses URI dans les exemples. Supprimé les termes inutilisés du glossaire.
20010510 Supprimé P3P du glossaire ; l'intégration de P3P sera traitée dans un document distinct sur la sécurité. Revu tous les exemples pour utiliser des adresses URI complètes au lieu de noms fictifs, et qualifié tous les attributs RDF par des préfixes d'espace de nommage. Ajouté des références croisées du chapitre 2.3 vers les chapitres 3.1.4 et 3.1.5 (utilisation de RDF par CC/PP). Ajouté une remarque expliquant pourquoi les descriptions des serveurs mandataires ne sont pas directement reliées. Ajouté la valeur séquence aux types de données. Supprimé l'obligation d'unicité d'un attribut entre tous les composants d'un profil. Ajouté la restriction selon laquelle un seul comportement de serveur mandataire doit référencer un seul type de composant, et que le type de document devrait être indiqué (chapitre 3.2.2). Précisé que la caractéristique charset indique réellement un codage de caractères. Annexe F retravaillé pour préciser que le document ne définit pas de liaison HTTP pour l'utilisation de CC/PP. Ajouté des attributs xml:lang aux schémas des annexes B et C. Revu l'interprétation de charWidth pour mieux tenir compte des caractères internationaux.
20010511 Référencé les types de données de schéma XML et réparé quelques erreurs de schéma mineures. Introduit la nouvelle classe ccpp:Structure afin de clairement distinguer toutes les propriétés de structure CC/PP des propriétés d'attribut. Corrections éditoriales en rapport avec UAProf (E.2).
20010522 Revu le texte relatif aux attributs CC/PP représentés par des chaînes d'adress URI : traitement préféré comme ressources RDF plutôt que comme chaînes d'adresses URI littérales (chapitre 4.1.1.1 et divers exemples). Présentation de la composition d'un graphe (nouveau chapitre 3.1.6). Supprimé quelques passages redondants (chapitres 3.1.1 et 3.1.2).
20010620 Revu tous les exemples afin qu'ils utilisent des préfixes d'espace de nommage explicites pour les éléments et attributs RDF. Supprimé une déclaration d'espace de nommage ccpp: inutilisée dans quelques exemples.
20010704 Réparé des petites erreurs dans les exemples 2-3b et 3-2c. Corrections de rédaction.
20010906 Récrit le texte du chapitre 3.1.5 décrivant l'utilisation de rdf:type sur l'instance ccpp:Component. Revu la description de charWidth dans l'annexe C afin de supprimer quelques erreurs concernant les caractères internationaux. Chapitre 4.1.1.1, ajouté un texte indiquant qu'on doit employer les conventions XML pour le codage des caractères non-ASCII dans les valeurs d'adresse URI (selon la spéc. RDF). Chapitre 4.1.2.2, ajouté une remarque selon laquelle les vocabulaires utilisant des valeurs de séquence devraient en définir la signification par rapport à l'ordonnancement. Ajouté une texte pointant vers des interactions de protocole possibles dans les annexes D, F, et F.1. Vérifié l'exemple avec l'élément de description vide auprès du validateur RDF.
20011102

Revu le phrasé dans le chapitre 4.1.1.1 au sujet du codage des caractères non-ASCII dans les valeurs d'adresse URI, pour référencer l'errata de la spécification XML http://www.w3.org/XML/xml-V10-2e-errata#E26. Mis à jour la référence [XML] pour citer l'errata. Révision du texte d'introduction du chapitre 4.1.2 pour préciser que des ressources RDF arbitraires peuvent s'utiliser comme valeurs d'attribut, bien que leur signification ne soit pas définie ici. Corrigé des coquilles.

20020402 Ajouté des hyperliens vers les documents de schéma.
20020501 Ajouté le terme attributs XML où c'est nécessaire afin de distinguer les attributs CC/PP des attributs XML. Réparé la référence locale de about dans la figure 2-1b. Ajouté des hyperliens vers les chapitres où c'est nécessaire. Supprimé les crochets facultatifs autour des identificateurs d'espace de nommage. Supprimé l'espace superflu des dates de réunion du groupe de travail. Supprimé les exemples de matériels et logiciels de serveur mandataire : il n'est pas nécessaire qu'un serveur mandataire rajoute une mention de son prédécesseur ou de son système d'exploitation à une requête CC/PP, cet exemple pouvant prêter à confusion. Supprimé quelques reliquats du terme chaîne d'adresse URI. Changé les titres Ne pas réutiliser les vocabulaires existants en Réutiliser les vocabulaires existants. Supprimé un Defaults capitalisé incorrectement dans le chapitre 3.1.3. Réparé les références : il y avait un problème avec les crochets. Changé schéma RDF pour Schéma RDF quand cela se rapporte à la spécification W3C.
20020502 Réparé des erreurs dans le code RDF dans la figure 1-2 et 3-3, identifiées par le service de validation RDF du W3C.
20020507 Mis à jour le chapitre 3.1.5 pour résoudre le problème 16. Mis à jour le chapitre 2.2 pour résoudre le problème 54. Ajouté un paragraphe au sujet de WAI pour résoudre le problème 115.
20020520 Mis à jour le schéma CC/PP afin d'y créer les types de données anyURI, string et integer dans l'espace de nommage CC/PP qui référence les types de données dans le schéma XML. La version précédente ne faisait que référencer les types de données du schéma XML. Changé l'espace de nommage de CC/PP pour http://www.w3.org/2002/05/20-ccpp#.
20020715 Mis à jour le chapitre des références pour distinguer les normatives des informatives, et utilisé le format d'étiquette de référence [AAAA] et non [nnnn] du guide de style du W3C pour répondre au problème 181. Supprimé les exemples employant des littéraux composites, c'est-à-dire changé toutes les reliquats de <display> pour <displayWidth> et <displayHeight> pour répondre au problème 152. Ajouté un texte au chapitre 3.1.1 pour répondre au problème 175. Inséré la figure 3.2b pour expliquer la résolution par défaut en réponse au problème 180.
20020717 Mis à jour l'adresse URL de UAProf, particulièrement dans le chapitre 2.2, et ajouté le texte proposé par Art Barstow pour résoudre le problème 54. Mis à jour aussi les exemples UAProf pour qu'ils utilisent des noms de propriété UAProf légaux.
20020719 Supprimé un reliquat de la phrase C'est l'une des trois propriétés qui décrivent le comportement d'un serveur mandataire pour répondre au problème 37.
20020812 Ajouté une phrase au chapitre 3.2 et trois autres paragraphes au chapitre 3.2.2 pour répondre au problème 182.
20020812 Changé un paragraphe au chapitre 3.2 pour répondre au problème 182.
20020924 Supprimé l'usage de ccpp:Resource pour résoudre le problème 31.
20021105 Modifié le texte du résumé pour dire que le vocabulaire de serveur mandataire est optionnel. Modifié le texte de l'introduction pour dire que le vocabulaire de serveur mandataire est optionnel. Ajouté une phrase préliminaire dans le chapitre 2.1.4 disant que la gestion de serveur mandataire est optionnelle. Idem pour le chapitre 2.2. Déplacé Client-profile, Request-profile, Proxy-profile et Proxy-Behavior du schéma CC/PP vers le schéma de serveur mandataire. Mis à jour les figures B.1 et B.2, et ajouté deux nouvelles figures B.3 et B.4 pour refléter cela. En raison de la décision du typage des données faite par le groupe de travail RDF-Core, à propos de l'interprétation des littéraux, changé toutes les instances de type de données du schéma XML en types de données CC/PP. Supprimé la phrase Remarquez que, si disponible, on utilise les types de données du schéma XML (xsdt:) pour les valeurs littérales [XMLSCHEMA-2]. du chapitre B.1. Mis à jour les adresses URI au 8 novembre 2002. Changé la définition du profil CC/PP au chapitre 2.1 pour De façon générale, un profil CC/PP est construit selon une hiérarchie à deux niveaux : un profil ayant au moins un composant, et chaque composant ayant au moins un attribut. pour lever les réserves du comité d'esquissage UAProf, à savoir que la définition d'un composant CC/PP est incompatible avec UAProf.
20021211 Réparé un problème avec la figure 2-3b décrit dans le problème 183. Clarifié la signification d'un profil CC/PP pour résoudre le problème 185. Clarifié le statut des annexes pour répondre au problème 189. Supprimé le terme expression CC/PP du chapitre 2.2 pour répondre au problème 191. Mis à jour la référence du Schéma RDF pour qu'elle pointe vers la version de la recommandation candidate de mars 2000. Réparé la référence de UAProf pour répondre au problème 198. Réparé le schéma au chapitre B.3 en réponse au problème 200. Mis à jour les paragraphes d'introduction de l'Annexe C en réponse au problème 201. Ajouté une définition de processeur CC/PP à l'annexe B en réponse au problème 202, et remplacé les instances de analyseur syntaxique CC/PP par processeur CC/PP.
20021213 Vérifié l'usage des termes optionnel et recommandé, de sorte que leurs instances soient en majuscules si nécessaire en réponse au problème 188.
20030203 Rétabli l'utilisation de http://www.w3.org/2002/12/13-ccpp-schema et http://www.w3.org/2002/12/13-ccpp comme deux espaces de nommage CC/PP. Adopté uniformément l'usage de rdf:about dans les schémas.
20030212 Réparé un problème avec le chapitre 2 dans la table des matières. Réparé les numéros en gras dans l'espace de nommage CC/PP, chapitre 2.2. Corrigé une erreur grammaticale au chapitre 4.1.2.2.
20030320 Ajouté une mention du typage de données RDF et des autres travaux du groupe de travail Indépendance par rapport aux appareils dans la section de statut. Ajouté une mention de la compatibilité avec CONNEG au chapitre 1. Supprimé l'utilisation des types simples composés dans les exemples du chapitre 2.1.3. Supprimé le chapitre 2.1.4 (introduction aux serveurs mandataires), le chapitre 2.3 (introduction à RDF), le chapitre 3.2 (les serveurs mandataires). S'assuré que le document référence les spéc. RDF (RDF M&S, RDF/XML Syntax, RDF Primer, RDF Schema) aux endroits appropriés. Promu les sous-sections du chapitre 3.1 au rang de sous-sections du chapitre 3. Supprimé le texte insensible à la casse du chapitre 4.1.1.2. Changé la valeur recommandée minimum pour les nombres entiers et corrigé le type de données de schéma XML au chapitre 4.1.1.3. Décrit l'utilisation délicate des nombres rationnels au chapitre 4.1.1.4. Clarifié la relation expressive avec CONNEG au chapitre E.1.
20030728 Supprimé les reliquats mentionnant serveur mandataire. Ajouté une remarque au sujet de l'introduction à RDF référençant des versions des spéc. RDF plus récentes dans la section de statut. Changé l'URL du schéma de http://www.w3.org/2002/11/08-ccpp à http://www.w3.org/2002/11/08-ccpp-schema au chapitre 2.2. Ajouté la compatibilité avec l'espace de nommage UAProf pour component et defaults aux chapitres 3.1 et 3.3. Changé HTML 3.0 pour HTML 3.2 dans divers exemples. Supprimé Tokens du chapitre 4.1.1.2 et de l'Annexe C. Réparé le schéma pour les nombres rationnels au chapitre 4.1.1.4. Clarifié le fait que plusieurs occurences d'un seul attribut au sein d'un seul composant ne sont pas admises, chapitre 4.1.2. Ajouté le chapitre 5 La conformité. Changé les références pour qu'elles pointent sur les copies datées au chapitre 7. Supprimé anyUri du schéma dans les annexes B et C. Changé le type de donnée Rational pour rational dans l'annexe B. Ajouté une remarque sur la normalisation de la casse pour compatibilité avec CONNEG au chapitre E.1. Ajouté l'annexe G Compatibilité avec RDF.
20030915 Divers changements rédactionnels et éclaircissements. Ajouté le terme contexte de remise au chapitre 1. Supprimé un paragraphe redondant au sujet des adresses URI d'espace de nommage au chapitre 2.2. Supprimé le chapitre 4.1.1.1 Les valeurs décrites par des adresses URI, qui aurait dû être supprimé en même temps que anyURI.

Valid HTML 4.01!