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.
Ce document décrit la structure et les vocabulaires CC/PP (Composite Capabilities/Preference Profiles). Un profil CC/PP est une description des capacités de l'appareil et des préférences d'un utilisateur. Cette description, que l'on désigne souvent par contexte de remise d'un appareil, peut servir à guider l'adaptation du contenu présenté à l'appareil en question.
Le cadre de description des ressources (RDF) est utilisé afin de créer des profils décrivant les capacités et les préférences d'un agent utilisateur. La structure d'un profil sera expliquée dans le document. Les sujets abordés couvrent :
Le vocabulaire CC/PP consiste en identificateurs (des adresses URI) qui désignent des capacités et préférences particulières ; il contient :
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.
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
de HTTP et les attributs
Accept
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.alt
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].
La recommandation CC/PP : structure et vocabulaires
(abrégée en CC/PP dans la suite du document) définit un
format des données d'un profil client et un cadre
pour l'incorporation des caractéristiques particulières d'une application ou
d'un environnement d'exploitation. Elle ne définit pas comment le profil
est transmis ni quels attributs CC/PP doivent être générés ou reconnus. CC/PP est conçu pour une utilisation au sein d'un
cadre applicatif global. Ainsi, la spécification des éléments CC/PP
qui doivent être pris en charge et de ceux qui peuvent être omis est du ressort particulier d'une application.
Peu de principes de protocole entrent dans la conception de CC/PP. Bien que destiné à être largement
indépendant d'un protocole, CC/PP a fait l'objet d'une attention particulière en ce qui concerne son utilisation
avec le protocole HTTP pour la recherche de ressources Web. L'Annexe F
contient des explications
supplémentaires à propos des applications CC/PP.
Ce document décrit un certain nombre de fonctionnalités de CC/PP. Certaines fonctionnalités forment une partie de la
structure essentielle de CC/PP, pour laquelle la conformité est OBLIGATOIRE (voir le chapitre 5
).
L'emploi des autres fonctionnalités est RECOMMENDÉ ou OPTIONNEL. Une partie explique également la façon dont les nouveaux vocabulaires
devraient être introduits, elle s'adresse aux concepteurs d'applications CC/PP plutôt qu'aux personnes chargées de la mise en œuvre.
Le chapitre sur l'architecture ne décrit pas de fonctionnalités spécifiques mais donne les principes généraux sous-tendant la conception de CC/PP. Ce chapitre non normatif contient cependant des informations qui devraient être comprises pour la bonne mise en œuvre de CC/PP.
Le chapitre sur la structure CC/PP recouvre deux domaines principaux :
Le chapitre sur les vocabulaires d'attributs CC/PP décrit quelques fonctionnalités générales des attributs CC/PP et de leurs valeurs. La gestion des formats décrits pour les valeurs d'attribut simples est RECOMMENDÉE (la syntaxe réelle de chaque valeur CC/PP simple est définie par la spécification d'attribut correspondante) ; ces spécifications peuvent citer les informations fournies dans ce chapitre. La gestion des formats décrits pour les attributs CC/PP structurés est OBLIGATOIRE, si pertinent.
La prise en charge n'est pas nécessaire pour n'importe quel vocabulaire particulier, mais les concepteurs d'applications sont fortement encouragés à réutiliser les vocabulaires existants quand c'est possible.
Les applications CC/PP ne doivent pas obligatoirement prendre en charge les fonctionnalités décrites en annexes, cependant chaque
nouveau vocabulaire d'attributs DOIT se baser sur les classes et les propriétés RDF définies par le schéma RDF dans
l'Annexe B
(les nouveaux attributs CC/PP sont des instances de
,
les nouvelles classes de composants sont des sous-classes de ccpp:Attribute
, etc.).ccpp:Component
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).
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.
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].
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 :
[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 ressourcecontenant les valeurs indiquées (voir le [<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, 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 :
<?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>
|
Ce chapitre non normatif fournit une vue d'ensemble des fonctionnalités de CC/PP.
De façon générale, un profil CC/PP est construit selon une hiérarchie à deux niveaux :
composant, et
attribut.
Les branches initiales de l'arbre du profil CC/PP décrivent les composants principaux du client. Comme exemples de composants principaux :
Une représentation graphique simple du bas d'un arbre CC/PP construit à partir de trois composants
(MaterielFinal, LogicielFinal et NavigateurFinal) pourrait être :
[exemple:LeProfil] | +--ccpp:component-->[exemple:MaterielFinal] +--ccpp:component-->[exemple:LogicielFinal] +--ccpp:component-->[exemple:NavigateurFinal] |
Le code XML correspondant pourrait ressembler à ceci :
<?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 :
[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 :
<?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
depuis le composant
concerné vers un composant qui définit les valeurs par défaut.ccpp:defaults
[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 :
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é
, alors c'est la valeur appliquée directement qui a préséance :ccpp:defaults
[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é
appliquée directement au composant profil. De ce fait, dans ce profil, l'attribut memoryMb
a une valeur de memoryMb32
.
Le code XML correspondant pourrait ressembler à ceci :
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
,
alors l'adresse URI http://example.com/profilMateriel#PlateformeMateriel
sera utilisée pour rechercher un document RDF et,
au sein de ce document, la ressource ayant pour identificateur local http://example.com/profilMateriel
sera retenue
comme ressource par défaut. (On pourrait définir une telle ressource au sein du document cible par
#PlateformeMateriel
ou about='http://example.com/profilMateriel#PlateformeMateriel'
.
Voir également le ID='PlateformeMateriel'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.
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 :
<?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
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.defaults
REMARQUE : Retenez que les préfixes d'espace de nommage sont arbitraires : les applications NE DOIVENT PAS supposer que le préfixe
se rapporte au vocabulaire RDF, ou querdf: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.ccpp:
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
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.http://www.wapforum.org/UAPROF/ccppschema-20000405#
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 danshttp://www.w3.org/2002/11/08-ccpp-client#l'Annexe B.3).
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 dansl'Annexe C).
REMARQUE : Pour rechercher ces schémas, votre navigateur doit nécessairement comporter une en-tête
dans la requête. Les navigateurs, qui n'ajoutent pas cette en-tête ou qui utilisent l'en-têteAccept:text/xml, 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.Accept:*/*
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.
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
(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:component
est http://www.w3.org/2002/11/08-ccpp-schema#. Pour compatibilité avec UAProf, l'espace de nommage utilisé
pour qualifier ccpp
PEUT être un espace de nommage UAProf.component
L'objet d'une ressource
PEUT avoir un propriété ccpp:Component
(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.rdf:type
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é
, 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é.rdf:type
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.
[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
.
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é
. 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 ccpp:DefaultsD
majuscule) comme équivalent. Ici,
l'espace de nommage de
est ccpp
. Pour compatibilité avec UAProf,
l'espace de nommage utilisé pour qualifier http://www.w3.org/2002/11/08-ccpp-schema#
, ou defaults
, PEUT être un espace de nommage UAProf.Defaults
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 :
[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
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.ccpp:defaults
[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.
<?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 :
<?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
pour nœud racine. L'instancerdf:Descriptionest nommée à l'aide d'un attributrdf:Descriptiondont la valeur est une adresse URI. Celui-ci DOIT correspondre à la valeur de l'attribut XMLrdf:aboutde l'élémentrdf:resourcedans 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.ccpp:defaults
Voici les exemples de documents par défaut appelés précédemment :
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>
|
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>
|
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>
|
CC/PP emploie des espaces de nommage pour distinguer le vocabulaire associé à la structure (par exemple,
) des vocabulaires associés aux applications (par exemple, l'affichage par le matériel final).ccpp:component
Dans cet exemple, nous utilisons l'espace de nommage
,
associé au préfixe http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#
, pour décrire des propriétés non définies dans les espaces de nommage CC/PP ou RDF :prf:
<?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
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.ccpp:
Cette spécification utilise l'attribut
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:about
.rdf:ID
CC/PP admet les attributs
ou rdf:ID
. Par contre, les valeurs des attributs
rdf:about
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 rdf:ID
.
Si cette extension de RDF atteint le statut de recommandation, alors il faudrait
utiliser les attributs xml:base
en conjonction avec un attribut rdf:ID
au lieu de
xml:base
. 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.rdf:about
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
. On peut les identifier
utilement comme telles au moyen de la propriété ccpp:Component
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
rdf:typechapitre 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
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 :
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.-
Signed-integer ::= ( '+' | '-' )? Unsigned-integer Unsigned-integer ::= Digit (Digit)* |
Quelques exemples :
REMARQUE : Le choix de l'intervalle de nombres RECOMMANDÉ est inspiré de la gestion de Java et d'autres langages de programmation largement utilisés pour le Web.
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./
Rational-number ::= Signed-integer ( '/' Unsigned-integer )? |
Si le dénominateur est absent, on suppose une valeur de
, c'est-à-dire on traite la valeur comme un nombre entier.1
Quelques exemples :
REMARQUE : Le schéma de nombre rationnel décrit ci-dessus peut se définir dans le schéma XML [XMLSCHEMA-0] comme suit :
Figure 4-4 : Un schéma XML possible pour les nombres rationnels <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030728/"> <xs:simpleType name="rational"> <xs:annotation> <xs:documentation> La représentation lexicale canonique de toute valeur sera la forme de la valeur réduite à son plus petit dénominateur commun, avec '1' en dénominateur, le cas échéant. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="[-+]?[0-9]+(/0*[1-9][0-9]*)?"/> </xs:restriction> </xs:simpleType> </xs:schema>Alors que la forme ci-dessus donne une définition lexicale, remarquez qu'elle est imparfaite : elle interdit strictement les blancs. En outre, cette définition de type simple ne définit pas d'espace de valeurs numériques. L'ordre, l'égalité et la gestion implicite des opérations arithmétiques ne sont pas définis comme certains utilisateurs du type pourraient s'y attendre : les processeurs ont seulement besoin de reconnaître la définition d'une chaîne de caractères. En raison de ces déficiences, l'utilisation de nombres rationnels tels que définis ici peut nuire à l'interopérabilité. (Le groupe de travail XML-Schema pourra définir un type de donnée rationnel fonctionnel dans le futur).
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
, chaque membre de l'ensemble correspondant à
une propriété de cette ressource nommée rdf:Bag
, rdf:_1
, etc.
Cette construction est décrite dans le chapitre 3 de la spécification du modèle et de la syntaxe RDF [RDF].rdf:_2
[(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
n'exige pas que chaque valeur contenue soit unique. Un ensemble ne pouvant pas contenir de valeurs en double, chaque propriété d'une structurerdf:Bagutilisée pour représenter un ensemble doit donc avoir une valeur distincte.rdf:Bag
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 :
[(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 :
[(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
, chaque membre de la séquence correspondant à une
propriété de cette ressource nommée rdf:Seq
, rdf:_1
, etc. Cette structure est décrite dans
le chapitre 3 de la spécification du modèle et de la syntaxe de RDF [RDF].rdf:_2
[(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 :
[(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).
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 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 :
l'Annexe B. Voir le
chapitre 1.
chapitre 2.2.
chapitre 2.1.
chapitre 2.1.
rdf:about ou rdf:ID. Voir le chapitre 3.1.
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.
chapitre 3.
rdf:type, ceux-ci doivent se rapporter à la même adresse URI.
Voir le chapitre 3.1.
chapitre 3.3.
ccpp:defaults ou ccpp:Defaults. Voir le chapitre 3.3.
ccpp:defaults ou ccpp:Defaults, pour lesquelles
l'espace de nommage utilisé pour qualifier defaultsou
Defaultsest l'espace de nommage CC/PP ou UAProf. Voir le
chapitre 3.3.
chapitre 3.3.
chapitre 3.3.
chapitre 3.3.
rdf:type. Voir le chapitre 3.3.
chapitre 4.1.2.1.
chapitre 4.1.2.2.
chapitre 4.1.1.2.
chapitre 4.1.1.3.
chapitre 4.1.1.4.
chapitre 3.2.
chapitre 3.1.
chapitre 2.2.
Un producteur est conforme à CC/PP quand tout document de profil CC/PP généré par lui est un document conforme à 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é :
consommateur conforme à CC/PP 1.0s'il accepte n'importe quel profil CC/PP valide et en extrait les informations.
consommateur validant conforme à CC/PP 1.0s'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.
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.
Une revendication de conformité est bien formée si elle comprend les informations suivantes :
Ce document est un condensé de nombreux débats au sein du groupe de travail CC/PP du W3C, avec des amendements finaux introduits par le groupe de travail Indépendance par rapport aux appareils du W3C. Les personnes suivantes ont été membres du groupe de travail CC/PP à un moment donné ou pour la plupart de la période de préparation de cette spécification et ses prédécesseurs :
Pendant la période où le groupe de travail CC/PP développait la spécification, des corrections et des éclaircissements utiles ont été suggérés par Yuichi Koike, Stuart Williams, Sean Palmer et Toni Penttinen. Merci particulièrement à Aaron Swartz pour une très complète et éclairante relecture du premier brouillon en dernier appel.
Suite au passage des travaux au groupe de travail Indépendance par rapport aux appareils, remerciements particuliers également à David Ezell (groupe de travail XML Schema), Brian McBride (groupe de travail RDF Core), Masayasu Ishikawa (groupe de travail HTML) et Lynne Rosenthal (groupe de travail Assurance qualité) pour leur aide dans la finalisation de la spécification.
Les membres suivants du groupe de travail Indépendance par rapport aux appareils ont aussi apporté leur assistance pour terminer la spécification : Stephane Boyera, Roger Gimson, Kazuhiro Kitagawa, Andreas Schade.
Voir aussi WAP-248-UAProf Version 20-Oct-2001, disponible à http://www.wapforum.org/what/technical.htm