Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.w3.org/2002/07/soap-translation/soap12-part2.html below:

SOAP Version 1.2 Partie 2 : Ajouts

Cette annexe définit le type de media "application/soap+xml" qui peut être utilisé pour décrire des messages SOAP 1.2 sérialisé en XML.

Note:

Au moment de la publication de ce document, le processus d'enregistrement de ce type de media auprès de l'IANA suit son cours, avec le brouillon

. Une version future de la spécification SOAP pourrait faire référence au type de media dans les enregistrements de l'IANA.

Nom de type de media MIME :

application

Nom de sous-type MIME :

soap+xml

Paramètres requis :

aucun

paramètres optionnels :

charset

Ce paramètre a la même sémantique que le paramètre charset du type de media "application/xml" tel que spécifié dans la RFC 3023 [RFC 3023].

action

Voir section A.3 Le paramètre action.

Considérations d'encodage :

Identiques à celle de "application/xml", telles que décrites dans la RFC 3023 [RFC 3023], section 3.2, comme appliquées à l'infoset d'enveloppe SOAP.

Considérations de sécurité :

Voir section A.2 Considérations de sécurité.

Considérations d'interopérabilité :

Il n'y a pas de problèmes d'interopérabilité connus.

Spécification publiée :

Ce document (Partie 2) et dans la partie 1 de SOAP 1.2 [SOAP Partie 1].

Applications utilisant ce type de media :

Aucune application connue n'utilise actuellement ce type de media.

Informations complémentaires :

Extension de fichier :

Les messages SOAP ne sont pas obligés ni supposés être stockésen tant que fichiers.

Identifiant de fragment :

Identique à celui de "application/xml" tel que décrit dans la RFC 3023 [RFC 3023], section 5.

URI de base :

Tel que spécifié dans la RFC 3023 [RFC 3023], section 6. Voir aussi [SOAP Partie 1], section Utilisation d'URIs dans SOAP.

Code de type de fichier Macintosh :

TEXT

Personne et adresse électronique à contacter pour plus d'informations :

Mark Baker <mbaker@idokorro.com>

Utilisation envisagée :

COMMON (commune)

Auteur/Contrôle de changements :

L'ensemble de spécifications SOAP 1.2 est un travail produit au Groupe de travail XML Protocol du World Wide Web Consortium. Le W3C a le contrôle des changements sur ces spécifications.

Puisque SOAP peut transporter des données définies par une application, dont la sémantique est indépendante de celle de tout enrobage MIME (ou contexte dans lequel l'enrobage MIME est utilisé), on ne pourrait pas s'attendre à être capable de comprendre la sémantique du message SOAP en se basant sur la sémantique de l'enrobage MIME seul. Par conséquent, dès que l'on utilise le type de media "application/soap+xml" il est FORTEMENT RECOMMANDÉ de comprendre complètement les implications sur la sécurité du contexte dans lequel le message SOAP est utilisé. Les implications sur la sécurité sont susceptibles de mettre en jeu aussi bien la liaison spécifique de SOAP sur un protocole sous-jacent que la sémantique définie par l'application des données transportées dans le message SOAP (bien qu'on doive être très vigilant en utilisant ceci, comme l'indique la discussion dans la partie 1 de SOAP 1.2 [SOAP Partie 1], section Liaison sur des protocoles spécifiques à l'application.

Voir aussi dans la partie 1 de SOAP 1.2 [SOAP Partie 1], la section entière Considérations de sécurité.

De plus, comme ce type de media utilise la convention "+xml", il partage les mêmes considérations de sécurité que celles décrites dans la RFC 3023 [RFC 3023], section 10.

Ce paramètre optionnel peut être utilisé pour spécifier l'URI qui identifie le but du message. Dans SOAP 1.2, il sert à la même chose que le champ d'en-tête HTTP SOAPAction dans SOAP 1.1 : sa valeur identifie le but du message.

La valeur du paramètre action est une URI-référence absolue, comme définie dans la RFC 2396 [RFC 2396]. SOAP ne pose aucune restriction sur la spécificité de l'URI ou sur le fait qu'elle puisse être résolue.

Bien que l'intérêt du paramètre action soit d'indiquer le but du message SOAP, il n'y a pas de mécanisme pour calculer automatiquement sa valeur d'après l'enveloppe SOAP. En d'autres termes, sa valeur doit être déterminée hors-ligne.

Il est recommandé d'utiliser la même valeur pour identifier des ensembles de types de messages logiquement liés d'une certaine manière, par exemple faisant partie d'un même "service". Il est FORTEMENT RECOMMANDÉ que l'URI reste globalement unique et stable dans le temps.

La présence et le contenu du paramètre action POURRAIENT être utilisés par des serveurs comme des pare-feu pour filtrer convenablement les messages SOAP et ils pourraient être utilisés par les serveurs pour faciliter la répartition de messages SOAP à des gestionnaires internes de messages, etc. Ils NE DEVRAIENT PAS être utilisés comme une forme non sécurisée d'autorisation d'accès.

L'utilisation du paramètre action est OPTIONNELLE. Les récepteurs SOAP POURRAIENT l'utiliser comme indice pour optimiser le traitement, mais NE DEVRAIENT PAS requérir sa présence pour fonctionner.

Cette annexe détaille un algorithme pour, à un nom défini par une application, comme le nom d'une variable ou d'un champ dans un langage de programmation, fait correspondre les caractères Unicode légaux dans les noms des éléments et attributs XML définis dans [Namespaces in XML]

1. Un nom XML a deux parties : Prefix (préfixe) et LocalPart (PartieLocale). Prenons Prefix déterminé par les règles et contraintes spécifiées dans Espaces de nommage en XML (Namespaces in XML) [Namespaces in XML].

2. Soit T un nom dans une application, représenté comme une séquence de caractères encodés dans un encodage de caractères donné.

3. Soit M la fonction définie par l'implémentation pour transcoder les caractères utilisés dans le nom défini par l'application en une chaîne équivalente de caractères Unicode.

   Note:

   Idéalement, si ce transcodage part d'un encodage non-Unicode il devrait à la fois être réversible et normalisant en Unicode Forme C (c'est-à-dire les combinaisons de séquences seront dans l'ordre canonique prescrit). Il est à noter que certains transcodages ne peuvent être parfaitement réversibles et que la normalisation NFC pourrait altérer la séquence originale dans quelques cas. Voir http://www.w3.org/TR/charmod/#sec-Transcoding. Pour s'assurer que des noms concordants continuent à concorder après la correspondance, les séquences Unicode devraient être normalisées avec la Normalisation Unicode Forme C (Normalization Form C).

   Note:

   Ce transcodage est explicitement vers les valeurs scalaires Unicode ("code points") et non vers un schéma d'encodage de caractères particulier d'Unicode, comme UTF-8 ou UTF-16.

   Note:

   Note : les séquences de paires substituts correctement formées doivent être converties en leurs valeurs scalaires respectives ("code points") [c-a-d, la séquence U+D800 U+DC00 devrait être transcodée en caractère U+10000]. Si le transcodage commence avec un encodage Unicode, les séquences UTF-8 et UTF-16 non conformes (formes n'étant pas les plus courtes) doivent être converties en leurs valeurs scalaires respectives.

   Note:

   Le nombre de caractère dans T n'est pas nécessairement le même que le nombre de caractères dans M, car le transcodage peut être de un-vers-plusieurs ou plusieurs-vers-un. Les détails du transcodage peuvent être définis par l'implémentation. Il peut y avoir des cas (très rares) où il n'y a pas de représentation Unicode équivalente pour T ; ces cas ne sont pas couverts ici.

4. Soit C la séquence de valeurs scalaires Unicode (caractères) représentée par M(T)

5. Soit N le nombre de caractères dans C. Soient C₁, C₂, ..., C_N les caractères de C, dans l'ordre du plus au moins significatif (ordre logique).

6. Pour chaque i entre 1 (un) et N, notons X_i la chaîne de caractères Unicode définie par les règles suivantes :

   Cas :

   1. Si C_i n'est pas défini (c-a-d un caractère ou une séquence de caractères défini(e) par la séquence de caractère T de l'application n'a pas de correspondance dans Unicode), alors X_i est défini par l'implémentation

   2. Si i<=N-1 et C_i est "_" (U+005F LOW LINE) et C_i+1 est "x" (U+0078 LATIN SMALL LETTER X), alors X_i sera "_x005F_"

   3. Si i=1, et N>=3, et C₁ est "x" (U+0078 LATIN SMALL LETTER X) ou "X" (U+0058 LATIN CAPITAL LETTER X), et C₂ est "m" (U+006D LATIN SMALL LETTER M) ou "M" (U+004D LATIN CAPITAL LETTER M), et C₃ est "l" (U+006C LATIN SMALL LETTER L) ou "L" (U+004C LATIN CAPITAL LETTER L) (en d'autres termes, une chaîne de 3 lettres ou plus commençant par le texte "xml" ou toute recapitalisation de celui-ci), alors si C₁ est "x" (U+0078 LATIN SMALL LETTER X) alors X₁ sera "_x0078_"; sinon, si C₁ est "X" (U+0058 LATIN CAPITAL LETTER X) alors X₁ sera "_x0058_".

   4. Si C_i n'est pas un caractère NCName XML valide (voir Espaces de nommage en XML [Namespaces in XML]) ou si i=1 (un) et C₁ n'est pas un premier caractère valide d'un NCName XML (voir [Namespaces in XML]) alors :

      Notons U₁, U₂, ... , U₆ les 6 chiffres hexadécimaux [PROD: 5] tels que C_i soit "U+" U₁ U₂ ... U₆ dans la valeur scalaire Unicode.

      Cas :

      1. Si U₁=0, U₂=0, U₃=0, et U₄=0, alors X_i="_x" U₅ U₆ "_".

         Ce cas implique que C_i est un caractère dans le plan multilingue basique (Basic Multilingual Plane, Plane 0) d'Unicode et peut être complètement représenté par une simple séquence UTF-16 code point U+U₅U₆.

      2. Sinon, X_i sera "_x" U₁ U₂ U₃ U₄ U₅ U₆ "_".

   5. Sinon, X_i sera M_i. C'est-à-dire que tout caractère dans X qui est un caractère valide dans un NCName XML est simplement copié.

7. LocalPart est la chaîne de caractères concaténation de X₁, X₂, ... , X_N dans l'ordre du plus au moins significatif.

8. Le nom XML est le QName d'après Espaces de nommages XML (Namespaces in XML) [Namespaces in XML]

Hello world -> Hello_x0020_world
Hello_xorld -> Hello_x005F_xorld
Helloworld_ -> Helloworld_

          x -> x
        xml -> _x0078_xml
       -xml -> _x002D_xml
       x-ml -> x-ml

     Ælfred -> Ælfred
   άγνωστος -> άγνωστος
ᜉᜅᜎᜈ        -> _x1709__x1705__x170E__x1708_
ᏙᏚᎥ         -> _x13D9__x13DA__x13A5_
      

Comme noté dans 3.1.4 Calcul de la propriété nom du type (Type Name) les noeuds de graphes SOAP sont étiquetés par des noms de type mais les processeurs conformes ne sont pas obligés d'effectuer la validation des messages SOAP encodés.

Ces sections décrivent des techniques pouvant être utilisées lorsque l'on souhaite utiliser la validation avec les Schémas XML du W3C dans les applications SOAP. Toute erreur ou faute résultant d'une telle validation sont au-delà de ce que couvre la recommandation normative ; du point de vue de SOAP, ces fautes sont considérées comme des échecs au niveau applicatif.

Bien que les Schémas XML soient conventionnellement échangés sous forme de documents de schéma (voir [XML Schema Partie 1]), la recommandation Schémas est construite sur une définition abstraite de schémas auxquels tous les processeurs doivent se conformer. La recommendation Schémas prévoit que tous ces schémas incluent des définitions d'un ensemble de base de types intégrés d'origine, comme les entiers (integers), les dates, etc. (voir [XML Schema Partie 1], Définition d'origine de type simple (Built-in Simple Type Definition)). Ainsi, il est possible de discuter de la validation d'un message SOAP selon ce schéma miminal, qui est celui que l'on obtiendrait sans fournir de définitions ni déclarations supplémentaires (c-a-d pas de document de schéma) à un processeur de schéma.

Le schéma minimal prévoit que tout document XML bien formé sera valide, sauf que lorsqu'un xsi:type est présent, le type désigné doit être prédéfini d'origine, et l'élément correspondant doit être valide par rapport à ce type. Ainsi, la validation d'un message SOAP 1.2 utilisant un schéma minimal se rapproche des types définis d'origine dans SOAP 1.1.

La validation selon le schéma minimal (voir C.1 Validation utilisant le schéma minimal) ne réussira pas là où les noeuds de graphe encodés ont des arcs entrants multiple. Ceci parce que les éléments représentant ces noeuds de graphe vont transporter des items d'information attributs id illégaux sur des éléments de type "xs:string", "xs:integer" etc.

L'encodage SOAP de tels graphes POURRAIT être validé selon le schéma d'encodage SOAP. Pour que cet encodage soit valide, les étiquettes d'arcs et donc les propriétés [local name] et [namespace name] de l' item d'information élément

, doivent nécessairement correspondre à celles définies dans le schéma de l'encodage SOAP. La validation du graphe encodé selon le schéma d'encodage SOAP résulterait en l'assignation du nom de type adéquat à la propriété nom de type du noeud de graphe.

Il se pourrait que des schémas soient construits pour décrire l'encodage de certains graphes. La validation du graphe encodé selon ce schéma résulterait en l'assignation du nom de type adéquat à la propriété nom de type du noeud de graphe. Un tel schéma peut aussi fournir des valeurs par défaut ou fixées pour un ou plus des items d'information attributs itemType , arraySize ou nodeType  ; de telles valeurs d'attributs par défaut affectent le graphe désérialisé de la même manière que si les attributs étaient explicitement fournis dans le message. Les erreurs ou incohérences introduites par suite (par ex. si la valeur d'un attribut est fausse ou inappropriée) devraient être rapportées comme erreurs du niveau application ; les fautes provenant de l'espace de nommage "http://www.w3.org/2003/05/soap-encoding" ne devraient être rapportées que si les parties normatives de cette spécification sont violées.

Cette spécification est le travail du groupe de travail XML Protocol du W3C.

Participent au groupe de travail (à ce jour et par ordre alphabétique) : Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly of Allaire), David Fallside (IBM), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Ont été membres : Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricité de France)), Olivier Boudeville (EDF (Electricité de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (Tibco), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).

Aux personnes ayant contribué aux discussions sur xml-dist-app@w3.org nous adressons notre reconnaissance et nos remerciements.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4