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