4. Data Model for Resource Properties (Modèle de données pour les propriétés de ressources)

4. Data Model for Resource Properties (Modèle de données pour les propriétés de ressources)

4.1 The Resource Property Model (Le modèle de propriété de ressource)

Les propriétés sont des morceaux de données qui décrivent l'état d'une ressource. Les propriétés sont des données sur les données.

Les propriétés sont utilisées dans les environnements de création distribuée pour fournir une découverte et une gestion efficaces des ressources. Par exemple, une propriété 'subject' pourrait permettre l'indexation de toutes les ressources par leur sujet, et une propriété 'author' pourrait permettre la découverte des auteurs ayant écrit quels documents.

Le modèle de propriété DAV consiste en des paires nom/valeur. Le nom d'une propriété identifie la syntaxe et la sémantique de la propriété, et fournit une adresse par laquelle référencer sa syntaxe et sa sémantique.

Il existe deux catégories de propriétés: "live" et "dead". Une propriété live a sa syntaxe et sa sémantique imposées par le serveur. Les propriétés live incluent les cas où a) la valeur d'une propriété est protégée et maintenue par le serveur, et b) la valeur de la propriété est maintenue par le client, mais le serveur effectue une vérification syntaxique sur les valeurs soumises. Toutes les instances d'une propriété live donnée DOIVENT se conformer à la définition associée à ce nom de propriété. Une propriété dead a sa syntaxe et sa sémantique imposées par le client; le serveur enregistre simplement la valeur de la propriété textuellement.

4.2 Properties and HTTP Headers (Propriétés et en-têtes HTTP)

Les propriétés existent déjà, dans un sens limité, dans les en-têtes de message HTTP. Cependant, dans les environnements de création distribuée, un nombre relativement important de propriétés est nécessaire pour décrire l'état d'une ressource, et les définir/retourner toutes via des en-têtes HTTP est inefficace. Ainsi, un mécanisme est nécessaire qui permet à un principal d'identifier un ensemble de propriétés qui l'intéressent et de définir ou récupérer uniquement ces propriétés.

4.3 Property Values (Valeurs de propriété)

La valeur d'une propriété est toujours un fragment XML bien formé.

XML a été choisi car c'est un format de données structuré flexible et auto-descriptif qui prend en charge des définitions de schéma riches, et en raison de son support pour plusieurs jeux de caractères. La nature auto-descriptive de XML permet d'étendre la valeur de toute propriété en ajoutant des éléments. Les clients ne se briseront pas lorsqu'ils rencontrent des extensions car ils auront toujours les données spécifiées dans le schéma original et DOIVENT ignorer les éléments qu'ils ne comprennent pas.

Le support de XML pour plusieurs jeux de caractères permet à toute propriété lisible par l'homme d'être encodée et lue dans un jeu de caractères familier à l'utilisateur. Le support de XML pour plusieurs langues humaines, utilisant l'attribut "xml:lang", gère les cas où le même jeu de caractères est employé par plusieurs langues humaines. Notez que la portée xml:lang est récursive, donc un attribut xml:lang sur tout élément contenant un élément de nom de propriété s'applique à la valeur de propriété à moins qu'il n'ait été remplacé par un attribut de portée plus locale. Notez qu'une propriété n'a qu'une seule valeur, dans une seule langue (ou la langue PEUT rester non définie); une propriété n'a pas plusieurs valeurs dans différentes langues ou une seule valeur dans plusieurs langues.

Une propriété est toujours représentée par un élément XML consistant en le nom de la propriété, appelé "property name element". L'exemple le plus simple est une propriété vide, qui est différente d'une propriété qui n'existe pas:

<R:title xmlns:R="http://www.example.com/ns/"></R:title>

La valeur de la propriété apparaît à l'intérieur de l'élément de nom de propriété. La valeur peut être n'importe quel type de contenu XML bien formé, y compris du contenu texte uniquement et du contenu mixte. Les serveurs DOIVENT préserver les éléments d'information XML suivants (Information Items, utilisant la terminologie de [REC-XML-INFOSET]) dans le stockage et la transmission des propriétés dead:

Pour l'Element Information Item de nom de propriété lui-même:

• [namespace name]
• [local name]
• [attributes] nommés "xml:lang" ou tout attribut de ce type en portée
• [children] de type element ou character

Sur tous les Element Information Items dans la valeur de propriété:

• [namespace name]
• [local name]
• [attributes]
• [children] de type element ou character

Sur les Attribute Information Items dans la valeur de propriété:

• [namespace name]
• [local name]
• [normalized value]

Sur les Character Information Items dans la valeur de propriété:

• [character code]

Étant donné que les préfixes sont utilisés dans certains vocabulaires XML (XPath et XML Schema, par exemple), les serveurs DEVRAIENT préserver, pour tout Information Item dans la valeur:

• [prefix]

Les attributs XML Infoset non listés ci-dessus PEUVENT être préservés par le serveur, mais les clients NE DOIVENT PAS compter sur leur préservation. Les règles ci-dessus s'appliqueraient également par défaut aux propriétés live, sauf définition contraire.

Les serveurs DOIVENT ignorer l'attribut XML xml:space s'il est présent et ne jamais l'utiliser pour modifier le traitement des espaces blancs. Les espaces blancs dans les valeurs de propriété sont significatifs.

4.3.1 Exemple - Propriété avec contenu mixte

Considérons une propriété dead 'author' créée par le client comme suit:

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe</x:name>
    <!-- Jane's contact info -->
    <x:uri type='email'
           added='2005-11-26'>mailto:[email protected]</x:uri>
    <x:uri type='web'
           added='2005-11-27'>http://www.example.com</x:uri>
    <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of <![CDATA[<RFC2518>]]>.
    </x:notes>
  </x:author>
</D:prop>

Lorsque cette propriété est demandée, un serveur pourrait retourner:

<D:prop xmlns:D='DAV:'><author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    <x:name>Jane Doe</x:name>
    <x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]</x:uri>
    <x:uri   added="2005-11-27" type="web"
      >http://www.example.com</x:uri>
    <x:notes>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    </x:notes>
  </author>
</D:prop>

Notez dans cet exemple:

• Le [prefix] pour le nom de propriété lui-même n'a pas été préservé, étant non significatif, alors que toutes les autres valeurs [prefix] ont été préservées,
• les valeurs d'attribut ont été réécrites avec des guillemets doubles au lieu de guillemets simples (le style de citation n'est pas significatif), et l'ordre des attributs n'a pas été préservé,
• l'attribut xml:lang a été retourné sur l'élément de nom de propriété lui-même (il était en portée lorsque la propriété a été définie, mais la position exacte dans la réponse n'est pas considérée comme significative tant qu'elle est en portée),
• les espaces blancs entre les balises ont été préservés partout (pas les espaces blancs entre les attributs),
• l'encapsulation CDATA a été remplacée par l'échappement de caractères (l'inverse serait également légal),
• l'élément de commentaire a été supprimé (tout comme l'aurait été un élément d'instruction de traitement).

Note d'implémentation: il existe des cas tels que des scénarios d'édition où les clients peuvent exiger que le contenu XML soit préservé caractère par caractère (tel que l'ordre des attributs ou le style de citation). Dans ce cas, les clients devraient envisager d'utiliser une valeur de propriété texte uniquement en échappant tous les caractères ayant une signification spéciale dans l'analyse XML.

4.4 Property Names (Noms de propriété)

Un nom de propriété est un identifiant universellement unique qui est associé à un schéma fournissant des informations sur la syntaxe et la sémantique de la propriété.

Parce que le nom d'une propriété est universellement unique, les clients peuvent dépendre d'un comportement cohérent pour une propriété particulière sur plusieurs ressources, sur le même serveur et sur différents serveurs, tant que cette propriété est "live" sur les ressources en question, et que l'implémentation de la propriété live est fidèle à sa définition.

Le mécanisme d'espace de noms XML, qui est basé sur les URI ([RFC3986]), est utilisé pour nommer les propriétés car il empêche les collisions d'espace de noms et offre différents degrés de contrôle administratif.

L'espace de noms des propriétés est plat; c'est-à-dire qu'aucune hiérarchie de propriétés n'est explicitement reconnue. Ainsi, si une propriété A et une propriété A/B existent sur une ressource, il n'y a aucune reconnaissance d'une relation entre les deux propriétés. On s'attend à ce qu'une spécification séparée soit éventuellement produite qui abordera les questions relatives aux propriétés hiérarchiques.

Enfin, il n'est pas possible de définir la même propriété deux fois sur une seule ressource, car cela provoquerait une collision dans l'espace de noms des propriétés de la ressource.

4.5 Source Resources and Output Resources (Ressources source et ressources de sortie)

Certaines ressources HTTP sont générées dynamiquement par le serveur. Pour ces ressources, il existe vraisemblablement un code source quelque part régissant la façon dont cette ressource est générée. La relation entre les fichiers source et les ressources HTTP de sortie peut être un à un, un à plusieurs, plusieurs à un, ou plusieurs à plusieurs. Il n'existe aucun mécanisme dans HTTP pour déterminer si une ressource est même dynamique, encore moins où existent ses fichiers source ou comment les créer. Bien que ce problème serait utilement résolu, des implémentations WebDAV interopérables ont été largement déployées sans résoudre réellement ce problème, en ne traitant que des ressources statiques. Ainsi, le problème source vs. sortie n'est pas résolu dans cette spécification et a été reporté à un document séparé.