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.
Copyright © 2004
W3C®
(MIT,
ERCIM,
Keio), tous droits réservés.
Les règles de responsabilité,
de marque commerciale,
d'utilisation des documents et
d'octroi de licences logicielles
du W3C s'appliquent.
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 :
- la structure des descriptions de capacités et préférences des clients et
- l'emploi de classes RDF afin de distinguer les différents éléments d'un profil, de sorte qu'un processeur RDF,
capable d'exploiter les schémas, puisse mettre en œuvre les profils incorporés à d'autres types de documents
XML.
Le vocabulaire CC/PP consiste en identificateurs (des adresses URI)
qui désignent des capacités et préférences particulières ; il contient :
- les types de valeurs auxquels les attributs CC/PP peuvent se rapporter,
- une annexe expliquant comment développer de nouveaux vocabulaires,
- une annexe donnant un exemple de vocabulaire réduit pour un client doté de capacités d'impression et d'affichage, et
- une annexe présentant une étude sur les travaux existants qui pourraient initier de nouveaux vocabulaires.
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 :
- Les composants des profils CC/PP : leur gestion est OBLIGATOIRE.
- Les valeurs par défaut des profils CC/PP : leur gestion est OBLIGATOIRE.
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 :
- un profil ayant au moins un
composant
, et
- chaque composant ayant au moins un
attribut
.
Les branches initiales de l'arbre du profil CC/PP décrivent les composants principaux du client. Comme exemples de composants principaux :
- la plate-forme matérielle sur laquelle le logiciel s'exécute,
- la plate-forme logicielle sur laquelle toutes les applications sont hébergées,
- une application individuelle, comme un navigateur.
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>
|
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>
|
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
).
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
).
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].
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 :
- Nom du navigateur : "Mozilla"
- Version du navigateur : "5.0"
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 :
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 :
- 1/2
- 768/1024
- -254/100
- +2000/65536
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 :
- l'ensemble de valeurs ;
- la séquence de valeurs
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.
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)
|
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.
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.
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 :
- les documents (par exemple, une ressource Web)
- les producteurs (par exemple, un client Web)
- 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 :
- 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
.
- Le document DOIT employer une syntaxe valide pour les déclarations d'espace de nommage.
Voir le
chapitre 2.2
.
- L'élément profil DOIT contenir un ou plusieurs composants. Voir le
chapitre 2.1
.
- Chaque composant dans le profil DOIT contenir un ou plusieurs attributs. Voir le
chapitre 2.1
.
- Les noms de composant PEUVENT se trouver dans les attributs
rdf:about
ou rdf:ID
. Voir le chapitre 3.1
.
- 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
.
- 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
.
- 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
.
- Les références des composants par défaut DOIVENT être des URL valides. Voir le
chapitre 3.3
.
- Les composants par défaut PEUVENT s'écrire
ccpp:defaults
ou ccpp:Defaults
. Voir le chapitre 3.3
.
- 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
.
- 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
.
- Les composants PEUVENT contenir des valeurs par défaut incorporées. Voir le
chapitre 3.3
.
- 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
.
- Les composants PEUVENT référencer un document par défaut qui n'a pas d'attribut
rdf:type
. Voir le chapitre 3.3
.
- Les attributs PEUVENT avoir des ensembles de valeurs (Bag). Voir le
chapitre 4.1.2.1
.
- Les attributs PEUVENT avoir des séquences de valeurs (Seq). Voir le
chapitre 4.1.2.2
.
- Les attributs PEUVENT avoir des valeurs chaîne de caractères. Voir le
chapitre 4.1.1.2
.
- Les attributs PEUVENT avoir des valeurs entières. Voir le
chapitre 4.1.1.3
.
- Les attributs PEUVENT avoir des valeurs rationnelles. Voir le
chapitre 4.1.1.4
.
- Un composant NE DOIT PAS contenir plusieurs attributs avec le même nom. Voir le
chapitre 3.2
.
- Des attributs ayant le même nom PEUVENT se trouver dans des composants différents. Voir le
chapitre 3.1
.
- 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é :
- 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.
- 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 :
- la date de la revendication
- la classe de produit (document, producteur ou consommateur)
- la catégorie de consommateur (conforme ou conforme validant), le cas échéant
- le titre et l'adresse URI datés de ce document
- 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 :
- Mikael Nilsson, Ericsson Infotech
- Ulrich Kauschke, T-Mobil
- Ann Navarro, HTML Writers Guild
- Brad Topol, IBM
- Franklin Reynolds, Nokia
- Graham Klyne, Baltimore Technologies
- Noboru Iwayama, Fujitsu Laboratories LTD
- Takashi Nishigaya, Fujitsu Laboratories LTD
- Lalitha Surayanrayana, SBC Technology Resources
- Hidetaka Ohto, W3C (jusqu'en mars 2002) / Panasonic
- Simon McBride, DSTC Pty Ltd
- Varuni Witana, DSTC Pty Ltd
- Chris Woodrow, Information Architects
- Johan Hjelm, Ericsson
- Barry Briggs, Interleaf
- Gerd Hoelzing, SAP
- Ted Hardie, Equinix
- Serge Rigori, Sun
- Ted Wugofski, Phone.com
- Kynn Bartlett, HTML Writers Guild
- Sandeep Singhal, IBM
- Thorsten Kassing, T-Mobil
- Larry Masinter, Adobe
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.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.
| 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.
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}
|
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
|
(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
|
(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
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 :
- IETF tree : des étiquettes de caractéristique enregistrées qui sont des noms simples, définis et assignés sous les
auspices du processus de normalisation IETF.
- Global tree : des étiquettes de caractéristique enregistrées qui sont des noms simples précédés par la chaîne
de caractères
g.
. Celles-ci sont spécifiées par d'autres groupes que l'IETF
mais enregistrées auprès de l'IANA pour garantir l'unicité de ces noms.
- Unregistered : des étiquettes de caractéristique non enregistrées qui sont constituées de la chaîne de caractères
u.
suivie par une forme d'adresse URI faiblement protégée.
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 :
- Plate-forme matérielle
- Plate-forme logicielle
- Caractéristiques WAP
- Agent utilisateur navigateur
- Caractéristiques du réseau
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 :
- le protocole d'échange de capacités
- le modèle de fiabilité
- le vocabulaire
- les mécanismes de sécurité
- les contraintes sur les types de valeur d'attribut admis
- les règles de traitement et/ou de correspondance des valeurs d'attribut
- le vocabulaire d'un serveur mandataire et son traitement
- les règles pour l'identification des requêtes de profil
- les informations supplémentaires à inclure dans toutes données de ressource transmises
- les formes d'adresse URI admises pour l'identification des documents de profil référencés (par exemple, les profils par défaut)
- les mécanismes de localisation et de rapport des documents de profil référencés
- les interactions avec les mécanismes de négociation existants dans le protocole hôte
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
|
- 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.
- 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.
- 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.
- 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.
- 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 :
- Le profil CC/PP est acheminé en un ou plusieurs morceaux, chacun contenant un fragment de graphe, lesquels sont combinés
pour former un seul graphe RDF.
- En plus du graphe RDF, le protocole doit nommer distinctement la ressource RDF correspondant à la racine du
profil de requête courant.
- Le mode opératoire actuel veut que toute l'interprétation du profil CC/PP est effectuée par le serveur origine, et aucune
par les serveurs mandataires. Il peut être nécessaire que le protocole autorise le serveur origine à fournir des informations
avec sa réponse, permettant aux serveurs mandataires de décider s'il leur faut appliquer d'éventuelles conversions ou non,
par exemple, une conversion XHTML vers WML est-elle nécessaire, ou le client a-t-il une capacité XHTML intrinsèque ?
REMARQUE : Le mode opératoire actuel
ci-dessus n'empêche pas les serveurs mandataires d'interpréter des
profils CC/PP. C'est plutôt que le cadre de description des comportements des serveurs mandataires n'oblige pas les
serveurs mandataires à les interpréter.
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.
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.
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 . |
