Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections normatives.
Ce document est également disponible dans les formats non normatifs suivants : XHTML avec notation Z, PDF, PostScript, XML et texte ordinaire.
Cf. également d'éventuelles traductions.
Copyright 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Ce document décrit le langage de description de services web version 2.0 (WSDL 2.0), un langage XML pour décrire des services web. Cette spécification définit le noyau du langage que l'on peut utiliser pour décrire des services web selon un modèle abstrait de ce qu'offre le service. Elle définit également les critères de conformité des documents dans ce langage.
Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver la liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.
Il s'agit de la recommandation du W3C du Langage de description de services web (WSDL) version 2.0 tome 1 — Cœur du langage examinée par les membres du W3C et les tiers intéressés. Elle est produite par le groupe de travail Web Services Description, sous l'égide de l'activité Web Services du W3C.
Veuillez envoyer les commentaires concernant ce document à la liste de diffusion publique public-ws-desc-comments@w3.org (archives publiques).
Le groupe de travail a publié une suite de tests en même temps qu'un rapport de mise en œuvre. Une version annotée en différence avec la version précédente de ce document est disponible.
Ce document a été examiné par les membres du W3C, par des développeurs de logiciels et par d'autres groupes du W3C et des tiers intéressés, et approuvé par le Directeur comme recommandation du W3C. C'est un document stable pouvant être utilisé comme document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du web.
Ce document est régi par la politique de brevets du W3C de janvier 2002 telle que corrigée par la procédure de transition de politique de brevets du W3C. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour la divulgation d'un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.
anyURI de XML Schemaname avec élément possesseur [owner element] bindinginterface avec élément possesseur [owner element] bindingtype avec élément possesseur [owner element] bindingname avec élément possesseur [owner element] endpointbinding avec élément possesseur [owner element] endpointaddress avec élément possesseur [owner element] endpointapplication/wsdl+xml
Le langage de description de services web version 2.0 (WSDL 2.0) fournit un modèle et un format XML pour décrire des services web. WSDL 2.0 permet de séparer la description de la fonctionnalité abstraite offerte par un service des détails concrets du service tels que « comment » et « où » cette fonctionnalité est offerte.
Cette spécification définit un langage pour décrire la fonctionnalité abstraite d'un service ainsi qu'un cadre d'applications (framework) pour décrire les détails concrets d'une description de service. Elle définit également les critères de conformité des documents dans ce langage.
La spécification complémentaire Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments [WSDL 2.0 Adjuncts] décrit des extensions pour les modèles d'échanges de messages, la sécurité des opérations, les styles d'opérations et des extensions de liaisons (pour les protocoles SOAP [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] et HTTP [IETF RFC 2616]).
WSDL 2.0 décrit un service web en deux étapes fondamentales : l'une abstraite et l'autre concrète. Lors de chaque étape, la description utilise plusieurs concepts (constructs) afin de promouvoir la réutilisabilité de la description et de séparer des préoccupations de conception indépendantes.
Au niveau abstrait, WSDL 2.0 décrit un service web en fonction des messages que celui-ci envoie et reçoit ; les messages sont décrits indépendamment d'un format de transmission (wire format) particulier en utilisant un système de typage (type system), typiquement XML Schema.
Une opération (operation) associe un modèle d'échange de messages à un ou plusieurs messages. Un modèle d'échange de messages (message exchange pattern) identifie la séquence et la cardinalité des messages envoyés ou reçus ainsi que leurs destinataires ou leurs émetteurs logiques. Une interface (interface) regroupe les opérations sans engagement vis-à-vis d'un format de transport ou de transmission.
Au niveau concret, une liaison (binding) définit les détails des formats de transport et de transmission d'une ou plusieurs interfaces. Une extrémité (endpoint) associe une adresse de réseau à une liaison. Enfin, un service (service) regroupe les extrémités qui mettent en œuvre une interface commune.
Une description de service WSDL 2.0 indique comment des clients potentiels sont censés interagir avec le service décrit. Elle représente l'assertion selon laquelle le service décrit met en œuvre et se conforme entièrement à ce que le document WSDL 2.0 décrit. Par exemple, ainsi que cela est approfondi dans la section 6.1.1 Extensions obligatoires, si le document WSDL 2.0 indique une extension optionnelle particulière, la fonctionnalité impliquée par cette extension n'est optionnelle que pour le client. Elle doit être gérée par le service web.
Une interface WSDL 2.0 décrit des interactions potentielles avec un service web, non des interactions nécessaires. La déclaration d'une opération dans une interface WSDL 2.0 n'est pas une assertion selon laquelle l'interaction décrite par l'opération doit se produire. C'est plutôt : si une telle interaction est amorcée (d'une certaine manière), alors l'opération déclarée décrit la façon dont cette interaction est censée avoir lieu.
Un item d'information d'élément (element information item), comme défini dans
l'ensemble d'information XML [XML Information Set]),
dont le nom d'espace de noms est "http://www.w3.org/ns/wsdl" et la partie locale (local part)
est description, est conforme à cette spécification s'il est valide selon le schéma XML de cet élément
tel que défini par cette spécification (c'est-à-dire http://www.w3.org/2007/06/wsdl/wsdl20.xsd)
et, en outre, adhère à toutes les contraintes décrites dans cette spécification et se conforme aux définitions des extensions
qui y sont contenues. Un tel item d'information d'élément constitue un document WSDL 2.0
(WSDL 2.0 document).
La définition du langage WSDL 2.0 s'appuie sur l'ensemble d'information XML [XML Information Set], mais elle impose aussi beaucoup de contraintes sémantiques pour la conformité de la structure, sur et au-dessus d'elle, à cet ensemble d'information XML. Pour décrire précisément ces contraintes, et afin d'aider à définir exactement la signification de chaque document WSDL 2.0, la spécification WSDL 2.0 définit un modèle de composants (Component Model), cf. la section 2. Modèle de composants, en couche supplémentaire d'abstraction au-dessus de l'ensemble d'information XML. Les contraintes et la signification sont définies en fonction de ce modèle de composants, et la définition de chaque composant inclut une correspondance (mapping) indiquant comment les valeurs du modèle de composants sont dérivées des éléments (items) correspondants de l'ensemble d'information XML.
Un document XML 1.0, qui est valide par rapport au schéma XML de WSDL 2.0 et correspond à un modèle de composant WSDL 2.0 valide, est conforme à la spécification WSDL 2.0.
Toutes les parties de cette spécification sont normatives, à l'exception des remarques, des pseudo-schémas, des exemples et des sections marquées explicitement comme non normatives.
Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans ce document doivent s'interpréter selon le RFC 2119 [IETF RFC 2119].
Les noms d'espaces de noms de la forme générale "http://example.org/..." ou "http://example.com/..." représentent des adresses URI d'application ou dépendantes du contexte [IETF RFC 3986].
anyURI de XML SchemaCette spécification utilise le type xs:anyURI de XML Schema,
cf. [XML Schema: Datatypes]. Il est défini de façon à ce que les valeurs
xs:anyURI soient essentiellement des adresses IRI, cf. [IETF RFC 3987].
La conversion des valeurs xs:anyURI en adresses URI réelles intervient au travers d'une
procédure d'échappement (escaping procedure) définie dans [XLink 1.0],
laquelle est essentiellement identique à celle décrite dans la section 3.1 de [IETF RFC 3987]).
Pour l'interopérabilité, les créateurs (authors) WSDL sont conviés à ne pas utiliser
les caractères US-ASCII suivants : « < », « > », « " », espace, « { », « } », « | », « \ », « ^ »
et « ` », admis dans les valeurs de type xs:anyURI mais pas dans les adresses IRI.
Cette spécification utilise tout du long des préfixes d'espaces de noms prédéfinis ; les voici dans la liste suivante. Notez que le choix d'un préfixe d'espace de noms est arbitraire et n'a pas d'importance sémantique (cf. [XML Namespaces]).
| Préfixe | Espace de noms | Notes |
|---|---|---|
| wsdl | "http://www.w3.org/ns/wsdl" | Défini par cette spécification. |
| wsdli | "http://www.w3.org/ns/wsdl-instance" | Défini par cette spécification, 7.1 Item d'information d'attribut wsdli:wsdlLocation. |
| wsdlx | "http://www.w3.org/ns/wsdl-extensions" | Défini par cette spécification, 3.3 Description des messages en rapport avec des services et des extrémités. |
| wrpc | "http://www.w3.org/ns/wsdl/rpc" | Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts]. |
| wsoap | "http://www.w3.org/ns/wsdl/soap" | Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts]. |
| whttp | "http://www.w3.org/ns/wsdl/http" | Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts]. |
| xs | "http://www.w3.org/2001/XMLSchema" | Défini dans la spécification XML Schema du W3C, [XML Schema : Structures], [XML Schema : Datatypes]. |
| xsi | "http://www.w3.org/2001/XMLSchema-instance" | Défini dans la spécification XML Schema du W3C, [XML Schema : Structures], [XML Schema : Datatypes]. |
Cette section décrit les termes et concepts introduits dans le tome 1 de la spécification WSDL version 2.0 (ce document).
Comme dans la spécification [XML Schema : Structures], l'expression « valeur réelle » (actual value) se rapporte au membre de l'espace de valeurs de la définition de type simple associée à un item d'information d'attribut qui correspond à sa valeur normalisée. Ce sera souvent une chaîne mais ça peut être un entier, un booléen, une adresse IRI, etc.
Un schéma XML défini dans l'item d'information d'élément wsdl:types d'une description WSDL 2.0.
Par exemple, un schéma XML défini dans l'item d'information d'élément xs:schema,
cf. la section 3.1.2 Incorporation d'un schéma XML.
Cette spécification se réfère à des propriétés dans l'ensemble d'information XML [XML Information Set]. Ces propriétés sont signalées par des crochets, ainsi [children] et [attributes].
Cette spécification définit et se réfère à des propriétés du modèle de composants WSDL 2.0, cf. la section 2. Modèle de composants. Ces propriétés sont signalées par des accolades, ainsi {name}, {interfaces}.
Cette spécification obéit à une convention d'écriture cohérente pour les propriétés du modèle de composants qui se rapportent aux composants. Si une propriété se rapporte à un composant obligatoire ou optionnel, le nom de propriété est le même que celui du composant. Si une propriété se rapporte à un ensemble de composants, le nom de propriété prend alors la forme du pluriel du nom de composant.
La notation Z [Z notation Reference Manual] a été utilisée pour le développement de cette spécification. La notation Z est un langage de définition formel fondé sur une notation mathématique standard. La notation Z de cette spécification a été contrôlée à l'aide du vérificateur de saisie (type-checker) Fuzz 2000 [Fuzz 2000].
La notation Z n'étant pas très connue, elle n'est pas incluse dans la version normative de cette spécification. Par contre, la notation Z est incluse dans une version non normative, où on peut la cacher ou la faire apparaître dynamiquement. Les navigateurs affichent correctement les caractères Unicode mathématiques, à condition que les fontes (fonts) nécessaires soient installées. Les fontes mathématiques pour Mozilla Firefox sont téléchargeables sur le site web de Mozilla.
La notation Z a été utilisée pour améliorer la qualité du texte normatif définissant le modèle de composants et pour s'assurer que la suite de tests couvrait toutes les règles importantes impliquées par le modèle de composants. Par contre, la notation Z n'étant pas normative, tout conflit intervenant entre elle et le texte normatif sera considéré comme une erreur de la notation Z. Les lecteurs et les développeurs (implementers) peuvent néanmoins trouver la notation Z utile lorsque le texte normatif n'est pas clair.
La syntaxe de la notation Z présente deux aspects contredisant les conventions d'écriture décrites dans les sections précédentes. Dans la notation Z, les crochets servent à introduire des ensembles de base, par exemple [ID], en contradiction de leur utilisation pour signaler les propriétés de l'ensemble d'information XML, cf. la section 1.4.6 Propriétés de l'ensemble d'information XML. Dans la notation Z encore, les accolades servent à indiquer un ensemble et son contenu, par exemple {1, 2, 3}, en contradiction de leur utilisation pour signaler les propriétés du modèle de composants de WSDL 2.0, cf. la section 1.4.7 Propriétés du modèle de composants WSDL 2.0. Quoi qu'il en soit, la signification attendue des crochets et des accolades devrait être claire dans le contexte, et ces conflits d'écriture ne devraient pas entraîner de confusion.
Des pseudo-schémas sont fournis pour chaque composant en préalable de leur description. Ils utilisent des conventions de type BNF pour les attributs et les éléments : un caractère « ? » indique une nature optionnelle (c'est-à-dire zéro ou une apparition), un caractère « * » indique zéro ou plus apparitions, le caractère « + » indique une ou plusieurs apparitions, les caractères « [ » et « ] » servent à former des groupes, et le caractère « | » représente un choix. Les attributs reçoivent conventionnellement une valeur qui correspond à leur type, tel que défini dans le schéma normatif. Les éléments à contenu simple reçoivent conventionnellement une valeur qui correspond au type de leur contenu, tel que défini dans le schéma normatif. Les pseudo-schémas ne contiennent pas de points d'extension pour la concision.
<!-- exemple de pseudo-schéma -->
<élément_défini
attribut_obligatoire_de_type_string="xs:string"
attribut_optionnel_de_type_int="xs:int"? >
<élément_obligatoire />
<élément_optionnel />?
<un_ou_plusieurs_de_ces_éléments />+
[ <choix_1 /> | <choix_2 /> ]*
</élément_défini>
Les assertions concernant des documents et des composants WSDL 2.0 que le schéma XML de WSDL 2.0 ne fait pas valoir (non enforced) sont signalées par une croix « † » en fin de phrase. À chaque assertion est affecté un identificateur unique composé d'un préfixe textuel descriptif et d'un suffixe numérique unique. Les suffixes numériques sont attribués successivement et jamais réutilisés ; il peut donc y avoir des trous dans la succession. Les identificateurs d'assertion PEUVENT être utilisés par les mises en œuvre de cette spécification quel qu'en soit le but, par exemple pour l'identification d'erreurs (error reporting).
Les assertions et leurs identificateurs sont repris dans la section E. Récapitulatif des assertions.
Cette section décrit le modèle conceptuel de WSDL 2.0 comme un ensemble de composants avec des propriétés, qui décrit collectivement un service web. Ce modèle est appelé le modèle de composants (component model) de WSDL 2.0. Un modèle de composants WSDL 2.0 valide est un ensemble de composants et propriétés WSDL 2.0 qui satisfait à toutes les exigences données dans cette spécification en fonction des indications des mots-clés à interpréter selon le RFC 2119 [IETF RFC 2119].
Les composants sont des collections typées de propriétés qui correspondent à des aspects différents des services web. Chaque sous-section à suivre décrit un type de composant différent, ses propriétés définies et sa représentation comme ensemble d'information XML [XML Information Set].
Les propriétés, non ordonnées, sont uniques par rapport au composant auquel elles sont associées. Les définitions des propriétés individuelles peuvent contraindre leur contenu (par exemple, à une valeur typée, un autre composant, ou un ensemble de valeurs typées ou de composants), et les composants peuvent imposer la présence d'une propriété pour prétendre à la conformité. Ces propriétés sont marquées comme étant OBLIGATOIRES, et celles dont la présence n'est pas nécessaire comme étant OPTIONNELLES. Par convention, pour la définition des règles de correspondance entre la représentation de l'ensemble d'information XML d'un composant et le composant même, une propriété optionnelle qui est absente du composant en question est décrite comme étant « vide ». Sauf indication contraire, lorsqu'une propriété est identifiée comme étant une collection (un ensemble ou une liste), sa valeur peut être une collection de zéro élément (vide). Pour simplifier la présentation des règles concernant des ensembles de composants, pour toutes les propriétés OPTIONNELLES dont le type est un ensemble, on DOIT interpréter l'absence d'une telle propriété dans un composant comme sémantiquement équivalente à la présence d'une propriété de même nom dont la valeur est l'ensemble vide. En d'autres termes, on DOIT partir du principe que toutes les propriétés à valeur d'ensemble (set-valued property) ont l'ensemble vide comme valeur par défaut, à utiliser en absence de la propriété.
Les définitions de composants sont sérialisables en format XML 1.0 mais elles sont indépendantes de toute sérialisation particulière du modèle de composants. Les définitions de composants utilisent un sous-ensemble (cf. la section 2.14 Types simples XML Schema 1.0 utilisés dans le modèle de composants) des types simples définis par la spécification XML Schema 1.0 [XML Schema: Datatypes].
Outre la représentation directe dans l'ensemble d'information XML décrite ici, le modèle de composants admet des composants extérieurs à l'ensemble d'information au travers des mécanismes décrits dans la section 4. Modularisation des descriptions WSDL 2.0.
On peut extraire un modèle de composants d'un ensemble d'information XML donné conforme au schéma XML
de WSDL 2.0 en associant récursivement les items d'information à leurs composants identifiés, en commençant par
l'item d'information d'élément wsdl:description. Cela comprend l'application des mécanismes décrits dans la section
4. Modularisation des descriptions WSDL 2.0.
Ce document ne définit pas de méthode pour produire une représentation dans l'ensemble d'information XML depuis une instance du modèle de composants. Notamment, parce qu'il y a en général plusieurs méthodes valides de modularisation d'une instance donnée du modèle de composants en un ou plusieurs ensembles d'information XML.
Au niveau supérieur, le composant Description est juste un conteneur pour deux catégories de composants : les composants WSDL 2.0 (WSDL 2.0 components) et les composants de système de typage (type system components).
Les composants WSDL 2.0 sont des interfaces, des liaisons et des services. Les composants de système de typage sont des déclarations d'éléments et des définitions de types.
Les composants de système de typage décrivent les contraintes exercées sur le contenu d'un message. Par défaut, ces contraintes sont exprimées en fonction de l'ensemble d'information XML [XML Information Set], c'est-à-dire qu'elles définissent les propriétés de nom local [local name], de nom d'espace de noms [namespace name], de sous-éléments [children] et d'attributs [attributes] d'un item d'information d'élément. Les systèmes de typage fondés sur d'autres modèles de données sont généralement pris en charge par des extensions de WSDL 2.0 ; cf. la section 6. Extensibilité du langage. Au cas où une extension définit des informations équivalentes à celles d'une déclaration d'élément global XML Schema, on peut la traiter comme si elle était une telle déclaration.
Cette spécification ne définit pas quel serait le comportement d'un document WSDL 2.0 utilisant simultanément plusieurs langages de schéma pour décrire des composants de système de typage.
Un composant Element Declaration définit le nom et le modèle de contenu d'un item d'information d'élément tels ceux définis par une déclaration d'élément globale XML Schema. Le composant a une propriété {name} qui est le nom qualifié QName de l'item d'information d'élément et une propriété {system} qui est l'adresse IRI de l'espace de noms des items d'information d'élément d'extension du système de typage, par exemple l'espace de noms de XML Schema.
Un composant Type Definition définit le modèle de contenu d'un item d'information d'élément tel que celui défini par une définition de type globale XML Schema. Le composant a une propriété {name} qui est le nom qualifié QName du type et une propriété {system} qui est l'adresse IRI de l'espace de noms des items d'information d'élément du système de typage, par exemple l'espace de noms de XML Schema.
Les composants Interface, Binding, Service, Element Declaration et Type Definition sont directement contenus dans le composant Description ; on les appelle des composants de niveau supérieur (top-level components). Les composants WSDL 2.0 de niveau supérieur contiennent d'autres composants, par exemple les composants Interface Operation et Endpoint, que l'on appelle des composants nichés (nested components). Les composants nichés peuvent contenir d'autres composants nichés. Le composant contenant un composant niché est appelé le parent (parent) du composant niché. Les composants nichés ont une propriété {parent} qui est une référence à leur composant parent.
Les propriétés du composant Description sont les suivantes :
{interfaces}, OPTIONNELLE. Un ensemble de composants Interface.
{element declarations}, OPTIONNELLE. Un ensemble de composants Element Declaration.
{type definitions}, OBLIGATOIRE. Un ensemble de composants Type Definition.
L'ensemble des composants de niveau supérieur contenus dans le composant Description
associé au document WSDL 2.0 initial se compose des composants définis dans le document initial, plus les composants
associés aux documents WSDL 2.0 inclus par le document initial, plus les composants définis par les
autres documents WSDL 2.0 dans les espaces de noms importés par le document initial. Le modèle de composants
ne fait aucune distinction entre les composants définis dans le document initial et ceux définis dans les documents inclus ou
les espaces de noms importés. Par contre, tout document WSDL 2.0 contenant des définitions de composants qui se
réfèrent par un nom qualifié QName à des composants WSDL 2.0 appartenant à un espace de noms différent
DOIT contenir un item d'information d'élément wsdl:import pour cet espace de noms
(cf. la section 4.2 Importation des descriptions). En outre, toutes les références QName
(QName references), qu'elles soient au même espace de noms ou à des espaces de noms différents,
doivent se résoudre en composants (cf. la section 2.17 Résolution des noms qualifiés QName).
Lorsqu'on utilise le langage XML Schema pour décrire des composants de système de typage, l'inclusion des composants Element Declaration et Type Definition dans un composant Description obéit aux règles édictées dans la section 3.1 Utilisation du langage de définition XML Schema du W3C.
Outre des composants WSDL 2.0 et des composants de système de typage, on PEUT ajouter des composants d'extension supplémentaires, cf. la section 6. Extensibilité du langage. On PEUT aussi ajouter par extension des propriétés supplémentaires aux composants WSDL 2.0 et aux composants de système de typage.
<description
targetNamespace="xs:anyURI" >
<documentation />*
[ <import /> | <include /> ]*
<types />?
[ <interface /> | <binding /> | <service /> ]*
</description>
Les descriptions WSDL 2.0 sont représentées en XML par un ou plusieurs ensembles d'information
WSDL 2.0, c'est-à-dire un ou plusieurs items d'information d'élément description.
Un ensemble d'information WSDL 2.0 contient les représentations d'une collection de composants WSDL 2.0
partageant un espace de noms cible commun et zéro ou plus items d'information d'élément wsdl:import, cf. la section
4.2 Importation des descriptions, correspondant à une collection avec des composants de
plusieurs espaces de noms cibles.
Les composants définis ou inclus directement dans un composant Description sont dits
appartenir au même espace de noms cible (target namespace). Ainsi,
l'espace de noms cible regroupe un ensemble de définitions de composants liés et représente un nom univoque pour la sémantique
attendue de la collection de composants. La valeur de
l'item d'information d'attribut targetNamespace DEVRAIT être
résolvable †.
Elle DEVRAIT se résoudre en un document
exploitable par un humain ou une machine définissant directement ou indirectement la sémantique attendue de ces
composants †.
Elle PEUT se résoudre en un
document WSDL 2.0 fournissant une information de description de service pour cet
espace de noms †.
Si un document WSDL 2.0 est scindé en plusieurs
documents WSDL 2.0 (lesquels peuvent être combinés au besoin selon les indications de la section
4.1 Inclusion des descriptions), alors l'item d'information d'élément targetNamespace
DEVRAIT se résoudre en un document WSDL 2.0 maître comprenant tous les
documents WSDL 2.0 nécessaires pour cette description de service †. Cette approche permet la bonne résolution des
identificateurs de fragment d'indicateur de composant WSDL 2.0.
Les composants appartenant à des espaces de noms importés ont des valeurs d'espace de noms cible différentes de celle du document WSDL 2.0 importeur. L'importation est donc le mécanisme pour utiliser des composants d'un espace de noms dans la définition de composants d'un autre espace de noms.
Notez que chaque document WSDL 2.0 ou composant de système de typage de même nature doit être identifié de façon unique par son nom qualifié. C'est-à-dire que, si deux composants distincts de même nature (Interface, Binding, etc.) sont dans le même espace de noms cible, alors leurs noms qualifiés DOIVENT être uniques. En revanche, des composants de types différents (par exemple, un composant Interface et un composant Binding) PEUVENT avoir le même nom qualifié QName. Les noms qualifiés des composants doivent donc être uniques dans l'espace de ces composants au sein d'un espace de noms cible donné.
L'item d'information d'élément description a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de description ;
un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl" ;
un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :
un item d'information d'attribut targetNamespace OBLIGATOIRE comme décrit à la
section 2.1.2.1 Item d'information d'attribut targetNamespace ;
zéro ou plus items d'information d'attribut, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit † :
zéro ou plus items d'information d'élément documentation (cf. la section
5. Documentation) ;
zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :
zéro ou plus items d'information d'élément include (cf. la section
4.1 Inclusion des descriptions) ;
zéro ou plus items d'information d'élément import (cf. la section
4.2 Importation des descriptions) ;
zéro ou plus items d'information d'éléments, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
un item d'information d'élément types OPTIONNEL (cf. la section
3. Types) ;
zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :
un item d'information d'élément interface (cf. la section
2.2.2 Représentation XML du composant Interface) ;
des items d'information d'élément binding (cf. la section
2.7.2 Représentation XML du composant Binding) ;
des items d'information d'élément service (cf. la section
2.12.2 Représentation XML du composant Service) ;
zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
targetNamespaceL'item d'information d'attribut targetNamespace définit l'affiliation à un espace de noms des composants
de niveau supérieur définis dans cet item d'information d'élément description. Les composants
Interface, Binding et Service
sont des composants de niveau supérieur.
L'item d'information d'attribut targetNamespace a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de targetNamespace ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut targetNamespace est xs:anyURI.
Sa valeur DOIT être une adresse IRI
absolue (cf. [IETF RFC 3987]) et devrait être résolvable †.
La correspondance de la représentation XML de l'item d'information d'élément description (cf. la section
2.1.2 Représentation XML du composant Description)
aux propriétés du composant Description est décrite dans le
tableau 2-1.
| Propriété | Valeur |
|---|---|
| {interfaces} | L'ensemble des composants Interface correspondant à tous les items d'information d'élément
interface dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant,
plus tous les composants Interface inclus (via wsdl:include) ou importés
(via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0. |
| {bindings} | L'ensemble des composants Binding correspondant à tous les items d'information d'élément
binding dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant,
plus tous les composants Binding inclus (via wsdl:include) ou importés
(via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0. |
| {services} | L'ensemble des composants Service correspondant à tous les items d'information d'élément
service dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant,
plus tous les composants Service inclus (via wsdl:include) ou importés
(via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0. |
| {element declarations} | L'ensemble des composants Element Declaration correspondant à toutes les
déclarations d'élément définies comme descendants de l'item d'information d'élément types, le cas échéant,
plus tous les composants Element Declaration inclus (via xs:include)
ou importés (via xs:import). L'ensemble incluera au minimum toutes les déclarations d'élément globales définies par
les items d'information d'élément element de XML Schema. Il PEUT
également inclure les déclarations d'autres systèmes de typage décrivant les propriétés de nom local [local name],
de nom d'espace de noms [namespace name], d'attributs [attributes] et de sous-éléments [children] d'un item d'information d'élément.
Chaque déclaration d'élément XML Schema DOIT
avoir un nom qualifié QName unique †. |
| {type definitions} | L'ensemble des composants Type Definition correspondant à toutes les définitions de type
définies comme descendants des items d'information d'élément types, le cas échéant, plus tous les composants
Type Definition inclus (via xs:include) ou importés (via xs:import) ;
plus les types de données intégrés définis par la spécification XML Schema
[XML Schema: Datatypes], à savoir les 19 types de données primitifs suivants,
xs:string, xs:boolean, xs:decimal, xs:float, xs:double,
xs:duration, xs:dateTime, xs:time, xs:date, xs:gYearMonth,
xs:gYear, xs:gMonthDay, xs:gDay, xs:gMonth, xs:hexBinary,
xs:base64Binary, xs:anyURI, xs:QName, xs:NOTATION, et les 25 types de données
dérivés, xs:normalizedString, xs:token, xs:language, xs:NMTOKEN,
xs:NMTOKENS, xs:Name, xs:NCName, xs:ID, xs:IDREF,
xs:IDREFS, xs:ENTITY, xs:ENTITIES, xs:integer,
xs:nonPositiveInteger, xs:negativeInteger, xs:long, xs:int,
xs:short, xs:byte, xs:nonNegativeInteger, xs:unsignedLong,
xs:unsignedInt, xs:unsignedShort, xs:unsignedByte, xs:positiveInteger.
L'ensemble PEUT également inclure les définitions d'autres systèmes de typage décrivant les
propriétés d'attributs [attributes] et de sous-éléments [children] d'un item d'information d'élément.
Chaque définition de type XML Schema
DOIT avoir un nom qualifié QName unique † |
Un composant Interface décrit les séquences de messages qu'un service envoie ou reçoit. Il regroupe les messages liés en opérations. Une opération est une séquence de messages entrants et sortants, et une interface est un ensemble d'opérations.
Une interface peut en option étendre une ou plusieurs interfaces. Afin d'éviter les définitions circulaires, une interface NE DOIT PAS apparaître dans l'ensemble d'interfaces qu'elle étend, que ce soit directement ou indirectement †. L'ensemble des opérations disponibles dans une interface comprend toutes les opérations définies par les interfaces que cette interface étend directement ou indirectement, ainsi que toutes les opérations qu'elle définit directement. Les opérations définies directement dans une interface sont appelées les opérations déclarées (declared operations) de l'interface. Au cours du processus, les composants d'opération équivalents, selon la section 2.15 Équivalence des composants, sont traités comme un seul composant. Le mécanisme d'extension d'interface agit de façon similaire pour tous les autres composants susceptibles d'être définis dans une interface, à savoir les composants Interface Fault.
Les interfaces sont des structures nommées qui peuvent être appelées par un nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName). Les composants Binding, par exemple, se réfèrent aux interfaces de cette façon.
Les propriétés du composant Interface sont les suivantes :
{name}, OBLIGATOIRE. Un nom qualifié xs:QName.
{extended interfaces}, OPTIONNELLE. Un ensemble de composants Interface déclarés que cette interface étend.
{interface faults}, OPTIONNELLE. L'ensemble des composants Interface Fault déclarés. Notez que le nom d'espace de noms de la propriété {name} de chaque composant Interface Fault dans cet ensemble est le même que celui de la propriété {name} de ce composant Interface.
{interface operations}, OPTIONNELLE. Un ensemble de composants Interface Operation déclarés. Notez que le nom d'espace de noms de la propriété {name} de chaque composant Interface Operation dans cet ensemble est le même que celui de la propriété {name} de ce composant Interface.
Pour chaque composant Interface dans la propriété {interfaces} d'un composant Description, la propriété {name} DOIT être unique †.
<description>
<interface
name="xs:NCName"
extends="liste de xs:QName"?
styleDefault="liste de xs:anyURI"? >
<documentation />*
[ <fault /> | <operation /> ]*
</interface>
</description>
La représentation XML d'un composant Interface est un item d'information d'élément avec les propriétés d'ensemble d'information suivante :
un nom local [local name] de interface ;
un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl" ;
un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :
un item d'information d'attribut name OBLIGATOIRE comme décrit ci-dessous à la section
2.2.2.1 Item d'information d'attribut name avec élément possesseur [owner element] interface ;
un item d'information d'attribut extends OPTIONNEL comme décrit ci-dessous à
la section 2.2.2.2 Item d'information d'attribut extends ;
un item d'information d'attribut styleDefault OPTIONNEL comme décrit ci-dessous à
la section 2.2.2.3 Item d'information d'attribut styleDefault ;
zéro ou plus items d'information d'attribut, qualifiés dans un espace de noms, dont le nom d'espace de noms n'est pas "http://www.w3.org/ns/wsdl".
zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit :
zéro ou plus items d'information d'élément documentation (cf. la section
5. Documentation) ;
zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :
zéro ou plus items d'information d'élément fault, cf. la section
2.3.2 Représentation XML du composant Interface Fault ;
zéro ou plus items d'information d'élément operation, cf. la section
2.4.2 Représentation XML du composant Interface Operation ;
zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
name avec élément possesseur [owner element] interfaceL'item d'information d'attribut name avec l'item d'information d'attribut targetNamespace
de l'item d'information d'élément description parent [parent] forment le nom qualifié QName de l'interface.
L'item d'information d'attribut name a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de name ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut name est xs:NCName.
extendsL'item d'information d'attribut extends liste les interfaces dont cette interface dérive.
L'item d'information d'attribut extends a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de extends ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut extends est une liste de noms qualifiés xs:QName séparés
par des caractères blancs.
La liste des noms qualifiés xs:QName dans un
item d'information d'attribut extends NE DOIT PAS contenir de
doubles †.
styleDefaultL'item d'information d'attribut styleDefault indique le style par défaut (cf. la section
2.4.1.2 Style d'opération) utilisé pour construire les propriétés
{element declaration} des propriétés
{interface message references} de toutes les opérations
contenues dans l'élément possesseur [owner element] interface.
L'item d'information d'attribut styleDefault a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de styleDefault ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut styleDefault est une liste de xs:anyURI.
Si présent, sa valeur DOIT contenir des
adresses IRI absolues (cf. [IETF RFC 3987]) †.
La correspondance de la représentation XML de l'item d'information d'élément interface (cf. la section
2.2.2 Représentation XML du composant Interface)
aux propriétés du composant Interface est décrite dans le
tableau 2-2.
| Propriété | Valeur |
|---|---|
| {name} | Le nom qualifié QName dont le nom local est la valeur réelle (actual value)
de l'item d'information d'attribut name et le nom d'espace de noms est la valeur réelle de
l'item d'information d'attribut targetNamespace de l'item d'information d'élément description
parent [parent]. |
| {extended interfaces} | L'ensemble des composants Interface en lesquels se résolvent les valeurs
dans l'item d'information d'attribut extends, le cas échéant (cf. la section
2.17 Résolution des noms qualifiés QName). |
| {interface faults} | L'ensemble des composants Interface Fault correspondant aux
items d'information d'élément fault dans les sous-éléments [children], le cas échéant. |
| {interface operations} | L'ensemble des composants Interface Operation correspondant aux
items d'information d'élément operation dans les sous-éléments [children], le cas échéant. |
Rappellez-vous, cf. la section 2.2.1 Le composant Interface, que les composants Interface dans la propriété {extended interfaces} d'un composant Interface donné NE DOIVENT PAS contenir de composant Interface dans l'une de leurs propriétés {extended interfaces}, pour dire que les interfaces d'extension récursives sont prohibées.
Un incident (fault) est un événement survenant pendant l'exécution d'un échange de messages, qui bouleverse le flux normal des messages.
Un incident survient typiquement lorsqu'une partie est dans l'impossibilité de communiquer une condition d'erreur dans le flux de messages normal ou souhaite terminer un échange de messages. Un message d'incident peut être utilisé pour communiquer une information hors bande telle que la raison de l'erreur, l'origine de la panne, ainsi que d'autres diagnostics informels tel qu'une trace de pile de programme (program stack trace).
Un composant Interface Fault décrit un incident qui PEUT se produire au cours de l'invocation d'une opération de l'interface. Le composant Interface Fault déclare un incident abstrait en le nommant et en indiquant le contenu du message d'incident. Le composant Interface Operation indique quand et comment le message d'incident circule.
Le composant Interface Fault fournit un mécanisme clair pour nommer et décrire l'ensemble des incidents qu'une interface peut générer. Cela permet aux opérations d'identifier aisément par leur nom les incidents individuels que les interfaces peuvent générer. Ce mécanisme permet d'identifier immédiatement le même incident survenant à travers plusieurs opérations et référencé dans plusieurs liaisons, et de réduire la multiplication des descriptions d'un incident individuel.
D'autres incidents que ceux décrits dans le composant Interface peuvent également être générés à l'exécution (at run-time), c'est-à-dire que les incidents forment un ensemble ouvert. Le composant Interface décrit les incidents ayant une sémantique au niveau de l'application, c'est-à-dire que le client ou le services sont censés les prendre en charge et potentiellement récupérer d'eux, dans le cadre de la logique de traitement de l'application. Par exemple, un composant Interface qui accepte un numéro de carte de crédit peut décrire les incidents indiquant que le numéro de la carte est invalide, qu'elle a été signalée volée ou qu'elle est périmée. Le composant Interface ne décrit pas les incidents de systèmes généraux tels que les pannes de réseau, les conditions de dépassement de mémoire, les conditions de pénurie d'espace disque, les formats de message invalides, etc., même si ces incidents peuvent survenir dans le cadre de l'échange de messages. De tels incidents de systèmes généraux peuvent survenir au cours de n'importe quel échange de messages et les décrire explicitement dans un composant Interface n'est donc pas informatif.
Les propriétés du composant Interface Fault sont les suivantes :
{name}, OBLIGATOIRE. Un nom qualifié xs:QName ;
{message content model}, OBLIGATOIRE. Un type xs:token ayant l'une des valeurs suivantes : #any, #none, #other ou #element †. Une valeur de #any indique que le contenu des incidents est n'importe quel élément seul ; une valeur de #none indique qu'il n'y aucun contenu d'incident ; une valeur de #other indique que le contenu d'incident est décrit par une autre propriété d'extension référençant une déclaration dans un système de typage d'extension non-XML ; une valeur de #element indique que l'incident se compose d'un seul élément décrit par la déclaration d'élément globale référencée par la propriété {element declaration}. Cette propriété n'est utilisée que si l'incident est décrit en utilisant un modèle de données fondé sur XML ;
{element declaration}, OPTIONNELLE. Une référence à un composant Element Declaration dans la propriété {element declarations} du composant Description. Cet élément représente le contenu, ou « charge utile » (payload), de l'incident. Lorsque la propriété {message content model} a la valeur #any ou #none, la propriété {element declaration} DOIT être vide † ;
{parent}, OBLIGATOIRE. Le composant Interface qui contient ce composant dans sa propriété {interface faults}.
Pour chaque composant Interface Fault dans la propriété {interface faults} d'un composant Interface, la propriété {name} doit être unique. Notez que le schéma XML normatif de WSDL 2.0 fait valoir cette contrainte.
Les composants Interface Fault sont identifiés de manière unique par le nom qualifié QName du composant Interface englobant et le nom qualifié du composant Interface Fault même.
Remarque :
Bien qu'ils aient une propriété {name}, les composants Interface Fault ne peuvent pas être identifiés exclusivement par leur nom qualifié QName. En effet, deux composants Interface, dont la valeur de la propriété {name} a le même nom d'espace de noms mais des noms locaux différents, peuvent contenir des composants Interface Fault ayant la même valeur de propriété {name}. La propriété {name} des composants Interface Fault est donc insuffisante pour former l'identité unique d'un composant Interface Fault. Une méthode pour identifier les composants de manière unique est définie dans la section A.2 Identificateurs de fragment. Cf. la section A.2.5 Le composant Interface Fault pour la définition de l'identificateur de fragment du composant Interface Fault.
Au cas où deux (ou plus) composants Interface Fault ont des propriétés {name} de même valeur, en raison d'une interface qui étend une ou plusieurs autres interfaces, alors les modèles de composant de ces composants Interface Fault DOIVENT être équivalents (cf. la section 2.15 Équivalence des composants) †. Si les composants Interface Fault sont équivalents, alors ils sont censés fusionner en un seul composant. Au sein du même composant Interface, si deux composants Interface Fault ne sont pas équivalents, alors leurs propriétés {name} NE DOIVENT PAS être égales.
À cause des règles précédentes, notez que si deux interfaces ont la même valeur de nom d'espace de noms pour leurs propriétés {name} et ont aussi un ou plusieurs incidents avec la même valeur pour leurs propriétés {name}, alors ces interfaces ne peuvent pas les deux former une partie de la chaîne de dérivation d'une interface dérivée, à moins que ces incidents n'en soient qu'un.
Pour la raison précédente, une bonne pratique DEVRAIT être de s'assurer, le cas échéant, que le nom local de la propriété {name} des composants Interface Fault au sein d'un espace de noms soit unique, rendant ainsi possible une telle dérivation sans erreur accidentelle †.
Si un sytème de typage non fondé sur l'ensemble d'information XML [XML Information Set] est en vigueur (comme examiné dans la section 3.2 Utitilisation d'autres langages de schéma), alors il faudrait ajouter d'autres propriétés au composant Interface Fault (en même temps que des attributs d'extension à sa représentation XML) afin de pouvoir associer ces types de message au message de référence.
<description>
<interface>
<fault
name="xs:NCName"
element="union de xs:QName, xs:token"? >
<documentation />*
</fault>
</interface>
</description>
La représentation XML d'un composant Interface Fault est un item d'information d'élément avec les propriétés d'ensemble d'information suivantes :
un nom local [local name] de fault ;
un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl" ;
un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :
un item d'information d'attribut name OBLIGATOIRE comme décrit ci-dessous à la section
2.3.2.1 Item d'information d'attribut name avec élément possesseur [owner element] fault ;
un item d'information d'attribut element OPTIONNEL comme décrit à la section
2.3.2.2 Item d'information d'attribut element avec élément possesseur [owner element] fault ;
zéro ou plus items d'information d'attribut, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit :
zéro ou plus items d'information d'élément documentation (cf. la section
5. Documentation) ;
zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".
name avec élément possesseur [owner element] faultL'item d'information d'attribut name identifie un item d'information d'élément fault donné à l'intérieur
d'un item d'information d'élément interface.
L'item d'information d'attribut name a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de name ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut name est xs:NCName.
element avec élément possesseur [owner element] faultL'item d'information d'attribut element se rapporte, par un nom qualifié QName, à un composant
Element Declaration.
L'item d'information d'attribut element a les propriétés d'ensemble d'information suivantes :
un nom local [local name] de element ;
un nom d'espace de noms [namespace name] sans valeur.
Le type de l'item d'information d'attribut element est l'union d'un type xs:QName et d'un type xs:token,
où les valeurs d'atome (token) permises sont #any, #none ou #other.
La correspondance de la représentation XML de l'item d'information d'élément fault (cf. la section
2.3.2 Représentation XML du composant Interface Fault)
aux propriétés du composant Interface Fault est décrite dans le
tableau 2-3.
| Propriété | Valeur |
|---|---|
| {name} | Le nom qualifié QName dont le nom local est la valeur réelle de l'item d'information d'attribut name et
dont le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de
l'item d'information d'élément description parent [parent] de l'item d'information d'élément interface
parent [parent]. |
| {message content model} | Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors c'est
#element ; sinon la valeur réelle de l'item d'information d'attribut element, le cas échéant ;
sinon #other. |
| {element declaration} | Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors c'est
le composant Element Declaration de la propriété
{element declarations} du composant
Description en lequel est résolue la valeur de l'item d'information d'attribut
element (cf. la section 2.17 Résolution des noms qualifiés QName) ; sinon vide.
Si l'item d'information d'attribut element a une valeur,
alors elle DOIT se résoudre dans le composant Element Declaration
de la propriété {element declarations} du composant
Description †. |
| {parent} | Le composant Interface correspondant à l'item d'information d'élément interface
dans le parent [parent]. |
Un composant Interface Operation décrit une opération prise en charge par une interface donnée. Une opération est une interaction avec le service consistant en un ensemble de messages échangés (ordinaires et d'incident) entre le service et les autres parties prenantes de l'interaction. Le séquencement (sequencing) et la cardinalité des messages impliqués dans une interaction particulière sont régis par le modèle d'échange de messages (message exchange pattern) utilisé par l'opération (cf. la propriété {message exchange pattern}).
Un modèle d'échange de messages définit les paramètres fictifs (placeholders) des messages, les participants du modèle (c'est-à-dire les émetteurs et les récepteurs des messages), et la cardinalité et le séquencement des messages échangés par les participants. Les paramètres fictifs de message sont associés à des types de message spécifiques par l'opération utilisant le modèle au moyen de références de message et d'incident (cf les propriétés {interface message references} et {interface fault references}). Le service dont l'opération utilise le modèle devient un participant du modèle. Cette spécification ne définit pas de langage interprétable par une machine pour décrire des modèles d'échange de messages ni ne définit de modèles spécifiques. La spécification complémentaire [WSDL 2.0 Adjuncts] définit un ensemble de tels modèles et définit des adresses IRI d'identification, dont chacune PEUT être utilisée comme valeur de la propriété {message exchange pattern}.
Les propriétés du composant Interface Operation sont les suivantes :
{name}, OBLIGATOIRE. Un nom qualifié xs:QName ;
{message exchange pattern}, OBLIGATOIRE. Un type xs:anyURI identifiant le modèle d'échange de messages utilisé par l'opération. Cette adresse xs:anyURI DOIT être une adresse IRI absolue (cf. [IETF RFC 3987]) † ;
{interface message references}, OPTIONNELLE. Un ensemble de composants Interface Message Reference pour les messages ordinaires que l'opération accepte ou envoie ;
{interface fault references}, OPTIONNELLE. Un ensemble de composants Interface Fault Reference pour les messages d'incident que l'opération accepte ou envoie ;
{style}, OPTIONNELLE. Un ensemble d'adresses xs:anyURI identifiant les règles utilisées pour construire les propriétés {element declaration} de la propriété {interface message references} (cf. la section 2.4.1.2 Style d'opération). Ces adresses xs:anyURI DOIVENT être des adresses IRI absolues (cf. [IETF RFC 3986]) † ;
{parent}, OBLIGATOIRE. Le composant Interface qui contient ce composant dans sa propriété {interface operations}.
Pour chaque composant Interface Operation dans la propriété {interface operations} d'un composant Interface, la propriété {name} DOIT être unique. Notez que le schéma XML normatif de WSDL 2.0 fait valoir cette contrainte.
Les composants Interface Operation sont identifiés de manière unique par le nom qualifié QName du composant Interface englobant et le nom qualifié QName du composant Interface Operation même.
Remarque :
Bien qu'ils aient une propriété {name}, les composants Interface Operation ne peuvent pas être identifiés exclusivement par leur nom qualifié QName. En effet, deux composants Interface, dont la valeur de la propriété {name} a le même nom d'espace de noms mais des noms locaux différents, peuvent contenir des composants Interface Operation ayant la même valeur de propriété {name}. La propriété {name} des composants Interface Operation est donc insuffisante pour former l'identité unique d'un composant Interface Operation. Une méthode pour identifier les composants de manière unique