Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SOAP::WSDL::Manual::WSUser)Contributed Perl DocumenSOAP::WSDL::Manual::WS_I(3)

NAME
       SOAP::WSDL::Manual::WS_I	- How SOAP::WSDL complies to WS-I Basic
       Profile 1.0

DESCRIPTION
       This document gives an overview about how SOAP::WSDL confirms to	the
       rules of	the WS-I Basic Profile 1.0 found at
       <http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html>

       Errata are not yet worked in.

       You may find rules mis-categorized, especially in the "not applicable"
       section.

       Such mis-categorizations	are documentation bugs,	please feel free to
       report them.

       Rules are categorized into the following	sections:

       o   RULES CONFIRMED

	   This	section	contains rules SOAP::WSDL follows. Conformance to
	   these rules may be assured by a test.

       o   RULES NOT CONFIRMED

	   This	section	contains rules SOAP::WSDL does not follow yet. These
	   may be considered as	bugs.

       o   RULES NOT APPLICABLE

	   WS-I	Basic Profile contains rules for web services as a whole.
	   SOAP::WSDL only plays the part of one layer in a Web	Service
	   CONSUMER / RECEIVER,	thus does not implement	some parts the WS-I
	   Basic Profile references.

	   This	section	contains rules not applicable for SOAP::WSDL, because
	   they	refer to parts SOAP::WSDL does not implement.

RULES CONFIRMED
   R1005
	A MESSAGE MUST NOT contain soap:encodingStyle attributes on any	of the elements
	whose namespace	name is	"http://schemas.xmlsoap.org/soap/envelope/".

       SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle
       attributes on any element.

   R1006
	A MESSAGE MUST NOT contain soap:encodingStyle attributes on any	element	that is
	a child	of soap:Body.

       SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle
       attributes on any element.

   R1008
	A MESSAGE MUST NOT contain a Document Type Declaration.

       SOAP::WSDL::Serializer::SOAP11 does not add DTDs.

   R1009
	A MESSAGE MUST NOT contain Processing Instructions.

       SOAP::WSDL::Serializer::SOAP11 does not add Processing Instructions

   R1010
	A RECEIVER MUST	accept messages	that contain an	XML Declaration.

       SOAP::WSDL::Expat::MessageParser	allows the use of XML Declarations.

   R1011
	A MESSAGE MUST NOT have	any element children of	soap:Envelope following
	the soap:Body element.

       SOAP::WSDL::Serializer::SOAP11 does not emit children of	soap:Envelope
       following the soap:Body element.	Other serializers may behave
       different.

   R1012
	A MESSAGE MUST be serialized as	either UTF-8 or	UTF-16.

       SOAP::WSDL::Serializer::SOAP11 serializes messages as UTF-8.

   R1018
	The media type of a MESSAGE's envelope MUST indicate the correct character
	encoding, using	the charset parameter.

       SOAP::WSDL::Transport::HTTP sets	the Content-type header	to "text/xml;
       charset=utf8". SOAP::Transport does, too. Other transport backends may
       behave different.

   R1014
	The children of	the soap:Body element in a MESSAGE MUST	be namespace
	qualified.

       SOAP::WSDL::Serializer::SOAP11 emits namespace-qualified	child elements
       of the soap:Body	element.

   R1017
	A RECEIVER MUST	NOT mandate the	use of the xsi:type attribute in messages
	except as required in order to indicate	a derived type (see XML	Schema
	Part 1:	Structures, Section 2.6.1).

       SOAP::WSDL::Expat::MessageParser	does not require the use of xsi:type
       attributes, but uses typemaps instead.

       Other deserializers may not comply to this rule.

   R1028
	When a Fault is	generated by a RECEIVER, further processing SHOULD NOT be
	performed on the SOAP message aside from that which is necessary to rollback,
	or compensate for, any effects of processing the message prior to the
	generation of the Fault.

       A fault is generated when an error occurs processing the	message.
       SOAP::WSDL::Deserializer::SOAP11	does not perform any additional
       processing after	an error occurred.

   R1029
	Where the normal outcome of processing a SOAP message would have resulted
	in the transmission of a SOAP response,	but rather a SOAP Fault	is generated
	instead, a RECEIVER MUST transmit a SOAP Fault message in place	of the
	response.

       A fault is generated when an error occurs processing the	message.

   R1030
	A RECEIVER that	generates a SOAP Fault SHOULD notify the end user that a
	SOAP Fault has been generated when practical, by whatever means	is deemed
	appropriate to the circumstance.

       Via return value.

   R1140
	A MESSAGE SHOULD be sent using HTTP/1.1.

       SOAP::WSDL::Transport::HTTP uses	HTTP/1.1

   R1141
	A MESSAGE MUST be sent using either HTTP/1.1 or	HTTP/1.0.

       SOAP::WSDL::Transport::HTTP uses	HTTP/1.1

   R1107
	A RECEIVER MUST	interpret SOAP messages	containing only	a soap:Fault element
	as a Fault.

       SOAP::WSDL::Deserializer::SOAP11	does this.

   R1132
	A HTTP request MESSAGE MUST use	the HTTP POST method.

       Both SOAP::WSDL::Transport::HTTP	and SOAP::Transport::HTTP use POST.

   R1108
	A MESSAGE MUST NOT use the HTTP	Extension Framework (RFC2774).

       SOAP::WSDL::Transport::HTTP does	not use	the HTTP Extension framework,
       however SOAP::Transport::HTTP use M-POST	if POST	was not	successful.

       To be sure you comply to	this rule, use SOAP::WSDL::Transport::HTTP as
       transport backend.

   R1109
	The value of the SOAPAction HTTP header	field in a HTTP	request
	MESSAGE	MUST be	a quoted string.

       SOAP::WSDL::Client always quotes	the SOAPAction header.

   R1119
	A RECEIVER MAY respond with a Fault if the value of the	SOAPAction
	HTTP header field is not quoted.

       SOAP::WSDL does not apply any processing	on the SOAPAction header
       field.

   R1131
	A CONSUMER MAY automatically redirect a	request	when it	encounters a
	"307 Temporary Redirect" HTTP status code in a response.

       LWP::UserAgent (used by SOAP::WSDL::Transport::HTTP and
       SOAP::Transport::HTTP) accepts up to 7 levels of	redirect by default.

   R2113
	A MESSAGE containing serialized	arrays MUST NOT	include	the
	soapenc:arrayType attribute.

       SOAP::WSDL does not natively support soapenc::arrayType.

   R2114
	The target namespace for WSDL definitions and the target namespace for
	schema definitions in a	DESCRIPTION MAY	be the same.

       SOAP::WSDL does not impose any constraints on the target	namespace for
       WSDL definitions	or schema definitions.

   R2301
	The order of the elements in the soap:body of a	MESSAGE	MUST be	the same
	as that	of the wsdl:parts in the wsdl:message that describes it.

       SOAP::WSDL obeys	the part order.

   R2712
	A document-literal binding MUST	be represented on the wire as a
	MESSAGE	with a soap:Body whose child element is	an instance of the
	global element declaration referenced by the corresponding wsdl:message
	part.

       If defined accordingly in the DESCRIPTION, SOAP::WSDL issues document-
       literal binding operation MESSAGES conforming to	this rule.

   R2748
	A CONSUMER MUST	NOT interpret the presence of the wsdl:required	attribute
	on a soapbind extension	element	with a value of	"false"	to mean	the extension
	element	is optional in the messages generated from the WSDL description.

       SOAP::WSDL does not imterpret the wsdl:required attribute at all.

   R5000
	An INSTANCE MAY	require	the use	of HTTPS.

       SOAP::WSDL supports https.

   R5010
	An INSTANCE MAY	require	the use	of HTTPS with mutual authentication.

       SOAP::WSDL supports all kinds of	authentication known to	LWP::UserAgent

   R2742
	A MESSAGE MAY contain a	fault detail entry in a	SOAP fault that	is not
	described by a wsdl:fault element in the corresponding WSDL description.

       SOAP::WSDL does not emit	such faults. Such faults can be	processed by
       adding custom maps to the type maps for
       SOAP::WSDL::Expat::MessageParser.

   R2744
	A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with	a
	quoted value equal to the value	of the soapAction attribute of
	soapbind:operation, if present in the corresponding WSDL description.

       SOAP::WSDL uses the soapAction attribute	from soapbind:operation	as
       SOAPAction header in generated code.

       Alternative WSDL	parsers	/ code generator have to assure	they pass the
       correct soap_action to SOAP::WSDL::Client.

       The interpreting	SOAP::WSDL client does not conform to this rule, but
       "guesses" the SOAPAction	header from the	operation name and the top
       node's namespace.

   R2745
	A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with	a
	quoted empty string value, if in the corresponding WSDL	description, the
	soapAction of soapbind:operation is either not present,	or present with	an
	empty string as	its value.

       SOAP::WSDL::Client always assures the SOAPaction	header is quoted, thus
       automatically inserts the empty string if no SOAPAction header is
       defined.

   R1015
	A RECEIVER MUST	generate a fault if they encounter a message whose document
	element	has a local name of "Envelope" but a namespace name that is not
	"http://schemas.xmlsoap.org/soap/envelope/".

       SOAP::WSDL::Expat::MessageParser	checks the namespace of	the SOAP
       envelope.

       SOAP::WSDL::Expat::MessageParser	does not check that Envelope is	the
       root element, yet.

   R1110
	An INSTANCE MAY	accept connections on TCP port 80 (HTTP)

       SOAP::WSDL::Server::CGI may be used in a	web server listening at	port
       80.

   R1124
	An INSTANCE MUST use a 2xx HTTP	status code for	responses that
	indicate a successful outcome of a request.

       SOAP::WSDL::Server::CGI sends a 2xx HTTP	status code for	successful
       requests.

   R1111
	An INSTANCE SHOULD use a "200 OK" HTTP status code for responses
	that contain a SOAP message that is not	a SOAP fault.

       SOAP::WSDL::Server::CGI does this.

   R1112
	An INSTANCE SHOULD use either a	"200 OK" or "202 Accepted" HTTP
	status code for	a response that	does do	not contain a SOAP message
	but indicates successful HTTP outcome of a request.

       SOAP::WSDL::Server::CGI does this.

   R1130
	An INSTANCE MUST use HTTP status code "307 Temporary Redirect"
	when redirecting a request to a	different endpoint.

       SOAP::WSDL::Server::CGI has no means of redirecting. The	web server
       running a SOAP::WSDL::Server::CGI script	is responsible for redirecting
       with a 307 HTTP status code.

   R1125
	An INSTANCE MUST use a 4xx HTTP	status code for	responses that indicate
	a problem with the format of the request.

       SOAP::WSDL does this.

   R1113
	An INSTANCE SHOULD use a "400 Bad Request "HTTP	status code, if	the
	request	message	is a malformed HTTP request, or	not well-formed	XML.

       SOAP::WSDL does this.

   R1114
	An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the
	request	method was not "POST".

       SOAP::WSDL does this.

   R1115
	An INSTANCE SHOULD use a "415 Unsupported Media	Type" HTTP status code if
	the Content-Type HTTP request header did not have a value consistent with
	the value specified for	the corresponding binding of the input message.

       SOAP::WSDL::Server::CGI does not	support	any content type other than
       text/xml	and application/xml yet.

RULES NOT CONFIRMED
   R4001
	A RECEIVER MUST	accept messages	that include the Unicode Byte Order Mark
	(BOM).

       May automatically work with XML::Parser::Expat, but is not tested yet.

       TODO write test.	If not confirmed, add encoding support.

   R1002
	A RECEIVER MUST	accept fault messages that have	any number of elements,
	including zero,	appearing as children of the detail element. Such children
	can be qualified  or unqualified.

       Partially confirmed: This only works when the fault detail elements are
       added to	the deserializer's typemap.

       TODO add	processing of arbitrary	content	of faults to
       SOAP::WSDL::Expat::MessageParser

   R1003
	A RECEIVER MUST	accept fault messages that have	any number of qualified	or
	unqualified attributes,	including zero,	appearing on the detail	element.
	The namespace of qualified attributes can be anything other than
	"http://schemas.xmlsoap.org/soap/envelope/".

       TODO add	processing of arbitrary	attributes to
       SOAP::WSDL::SOAP::Typelib::Fault11

   R1016
	A RECEIVER MUST	accept fault messages that carry an xml:lang attribute on
	the faultstring	element.

       SOAP::WSDL::Expat::MessageParser	currently ignores all attributes.

       TODO add	processing of the xml:lang attribute to
       SOAP::WSDL::SOAP::Typelib::Fault11

   R1007
	A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle
	attribute on any elements are grandchildren of soap:Body.

       SOAP::WSDL::Serializer::SOAP11 does not add soap:encodingStyle
       attributes on any element.

       However,	rpc-literal bindings are not supported,	yet.

       TODO support rpc-literal	bindings.

   R2008
	In a DESCRIPTION the value of the location attribute of	a wsdl:import element
	SHOULD be treated as a hint.

       The wsdl:import element imports the referenced WSDL definition.

       This is rather hard-wired and does not allow one	to specify a
       wsdl:import without a resolvable	location in SOAP::WSDL.

   R4002
	A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).

       TODO Test.

   R4003
	A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.

       TODO Test whether UTF-16	works.

   R2020
	The wsdl:documentation element MAY occur as a child of the wsdl:import
	element	in a DESCRIPTION.

       Not tested yet.

   R2024
	The wsdl:documentation element MAY occur as a first child of the
	wsdl:definitions element in a DESCRIPTION.

       TODO Test.

   R2027
	If during the processing of an element in the WSDL namespace in	a
	description, a consumer	encounters a WSDL extension element amongst
	its element children, that has a wsdl:required attribute with a	boolean
	value of "true"	that the consumer does not understand or cannot	process,
	the CONSUMER MUST fail processing of that element in the WSDL namespace.

       TODO Implement support for wsdl:required

   R2750
	A CONSUMER MUST	ignore a SOAP response carried in a response from a
	one-way	operation.

       SOAP::WSDL does not ignore the SOAP response from a one way operation
       yet.

       TODO Define operation type signature, and ignore	result from one	way
       operations.

   R2747
	A CONSUMER MUST	understand and process all WSDL	1.1 SOAP Binding extension
	elements, irrespective of the presence or absence of the wsdl:required
	attribute on an	extension element; and irrespective of the value of the
	wsdl:required attribute, when present.

       SOAP::WSDL does not implement all WSDL 1.1 SOAP Binding extension yet.

       TODO check and implement.

   R2800
	A DESCRIPTION MAY use any construct from XML Schema 1.0.

       SOAP::WSDL's WSDL parser	doen not allow all constructs from XML Schema
       1.0 to be used.

       TODO become "minimal conformant".

RULES NOT APPLICABLE
   R0004
	A MESSAGE MAY contain conformance claims, as specified in the conformance claim	schema.

       SOAP::WSDL::Serializer::SOAP11 does not add conformance claims.	Other
       serializers may act different.

   R0005
	A MESSAGE's conformance	claims MUST be carried as SOAP header blocks.

       SOAP::WSDL::Serializer::SOAP11 does not add conformance claims.	Other
       serializers may act different.

   R0006
	A MESSAGE MAY contain conformance claims for more than one profile.

       SOAP::WSDL::Serializer::SOAP11 does not add conformance claims.	Other
       serializers may act different.

   R0007
	A SENDER MUST NOT use the soap:mustUnderstand attribute	when sending a SOAP
	header block containing	a conformance claim.

       SOAP::WSDL::Serializer::SOAP11 does not add conformance claims.	Other
       serializers may act different.

   R3020
	REGDATA	of type	uddi:tModel claiming conformance with a	Profile	MUST be
	categorized using the ws-i-org:conformsTo:2002_12 taxonomy.

       SOAP::WSDL does not publish web services	yet.

   R3030
	REGDATA	of type	uddi:tModel claiming conformance with a	Profile	MUST use
	the ws-i-org:conformsTo:2002_12	categorization value corresponding to
	the conformance	claim URI for that Profile.

       SOAP::WSDL does not publish web services	yet.

   R3021
	A REGISTRY MUST	support	the WS-I Conformance category system by	adding
	the ws-i-org:conformsTo:2002_12	tModel definition to its registry content.

       SOAP::WSDL does not publish web services	yet.

   R3005
	REGDATA	other than uddi:tModel elements	representing conformant	Web service
	types MUST NOT be categorized using the	ws-i-org:conformsTo:2002_12
	taxonomy and a categorization of "http://ws-i.org/profiles/basic/1.0".

       SOAP::WSDL does not publish web services	yet.

   R3004
	REGDATA	of type	uddi:tModel MUST be constructed	so that	the conformance
	claim it makes is consistent with the conformance claim	made by	the
	wsdl:binding to	which it refers.

       SOAP::WSDL does not publish web services	yet.

   R1000
	When a MESSAGE contains	a soap:Fault element, that element MUST	NOT have element
	children other than faultcode, faultstring, faultactor and detail.

       SOAP::WSDL does not send	fault messages.	However,
       SOAP::WSDL::SOAP::Typelib::Fault11 complies to this rule.

   R1001
	When a MESSAGE contains	a soap:Fault element its element children MUST be
	unqualified.

       SOAP::WSDL does not send	fault messages.	However,
       SOAP::WSDL::SOAP::Typelib::Fault11 complies to this rule.

   R1004
	When a MESSAGE contains	a faultcode element the	content	of that	element
	SHOULD be one of the fault codes defined in SOAP 1.1 or	a namespace qualified
	fault code.

       SOAP::WSDL does not send	fault messages.	However, the fault issued by
       SOAP::WSDL::Deserializer	comply to this rule.

   R1031
	When a MESSAGE contains	a faultcode element the	content	of that	element	SHOULD
	NOT use	of the SOAP 1.1	"dot" notation to refine the meaning of	the Fault.

       SOAP::WSDL does not send	fault messages.	However, the fault issued by
       SOAP::WSDL::Deserializer	comply to this rule.

   R1013
	A MESSAGE containing a soap:mustUnderstand attribute MUST only use the lexical
	forms "0" and "1".

       SOAP::WSDL does not add soap:mustUnderstand attributes.

   R1025
	A RECEIVER MUST	handle messages	in such	a way that it appears that all
	checking of mandatory header blocks is performed before	any actual
	processing.

       SOAP::WSDL does not check mandatory header blocks yet.

   R1027
	A RECEIVER MUST	generate a "soap:MustUnderstand" fault when a message
	contains a mandatory header block (i.e., one that has a	soap:mustUnderstand
	attribute with the value "1") targeted at the receiver (via soap:actor)
	that the receiver does not understand.

       SOAP::WSDL does not check mandatory header blocks yet.

   R1120
	An INSTANCE MAY	use the	HTTP state mechanism ("Cookies").

       SOAP::WSDL::Server::CGI does not	use cookies. A web server running a
       SOAP::WSDL::Server::CGI script may use cookies..

   R1122
	An INSTANCE using Cookies SHOULD conform to RFC2965.

       SOAP::WSDL::Server::CGI does not	use cookies. A web server running a
       SOAP::WSDL::Server::CGI script may use cookies..

   R1121
	An INSTANCE SHOULD NOT require consumer	support	for Cookies in order to
	function correctly

       SOAP::WSDL::Server::CGI does not	use cookies. A web server running a
       SOAP::WSDL::Server::CGI script may use cookies.

   R1123
	The value of the cookie	MUST be	considered to be opaque	by the CONSUMER.

       SOAP::WSDL::Server::CGI does not	use cookies. A web server running a
       SOAP::WSDL::Server::CGI script may use cookies.

   R2028
	A DESCRIPTION using the	WSDL namespace (prefixed "wsdl"	in this	Profile)
	MUST be	valid according	to the XML Schema found	at
	"http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".

       See 2029.

   R2029
	A DESCRIPTION using the	WSDL SOAP binding namespace (prefixed "soapbind"
	in this	Profile) MUST be valid according to the	XML Schema found at
	"http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

       Although	the Profile requires WSDL descriptions to be Schema valid, it
       does not	require	consumers to validate WSDL documents.

       It is the responsibility	of a WSDL document's author to assure that it
       is Schema valid.

   R2001
	A DESCRIPTION MUST only	use the	WSDL "import" statement	to import another
	WSDL description.

       SOAP::WSDL (partially) supports the wsdl:import statement. The
       wsdl:include statement is not supported.

       It's the	responsibility of the WSDL author to use only the wsdl:import
       statement for importing WSDL descriptions.

   R2002
	To import XML Schema Definitions, a DESCRIPTION	MUST use the XML Schema
	"import" statement.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2003
	A DESCRIPTION MUST use the XML Schema "import" statement only within the
	xsd:schema element of the types	section.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2004
	A DESCRIPTION MUST NOT use the XML Schema "import" statement to	import a
	Schema from any	document whose root element is not "schema" from the
	namespace "http://www.w3.org/2001/XMLSchema".

       SOAP::WSDL has no means of generating WSDL definitions.

   R2009
	An XML Schema directly or indirectly imported by a DESCRIPTION MAY include
	the Unicode Byte Order Mark (BOM).

       SOAP::WSDL has no means of generating WSDL definitions.

   R2010
	An XML Schema directly or indirectly imported by a DESCRIPTION MUST
	use either UTF-8 or UTF-16 encoding.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2011
	An XML Schema directly or indirectly imported by a DESCRIPTION MUST use
	version	1.0 of the eXtensible Markup Language W3C Recommendation.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2007
	A DESCRIPTION MUST specify a non-empty location	attribute on the wsdl:import
	element.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2022
	When they appear in a DESCRIPTION, wsdl:import elements	MUST precede all
	other elements from the	WSDL namespace except wsdl:documentation.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2023
	When they appear in a DESCRIPTION, wsdl:types elements MUST precede all
	other elements from the	WSDL namespace except wsdl:documentation and
	wsdl:import.

       SOAP::WSDL has no means of generating WSDL definitions.

   R4004
	A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C
	Recommendation.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2005
	The targetNamespace attribute on the wsdl:definitions element of a
	description that is being imported MUST	have same the value as the
	namespace attribute on the wsdl:import element in the importing
	DESCRIPTION.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2021
	The wsdl:documentation element MAY occur as a child of the wsdl:part
	element	in a DESCRIPTION.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2025
	A DESCRIPTION containing WSDL extensions MUST NOT use them to
	contradict other requirements of the Profile.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2026
	A DESCRIPTION SHOULD NOT include extension elements with a wsdl:required
	attribute value	of "true" on any WSDL construct	(wsdl:binding,
	wsdl:portType, wsdl:message, wsdl:types	or wsdl:import)	that claims
	conformance to the Profile.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2101
	A DESCRIPTION MUST NOT use QName references to elements	in namespaces that
	have been neither imported, nor	defined	in the referring WSDL document.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2102
	A QName	reference to a Schema component	in a DESCRIPTION MUST use the
	namespace defined in the targetNamespace attribute on the xsd:schema
	element, or to a namespace defined in the namespace attribute on an
	xsd:import element within the xsd:schema element.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2105
	All xsd:schema elements	contained in a wsdl:types element of a
	DESCRIPTION MUST have a	targetNamespace	attribute with a valid and non-null
	value, UNLESS the xsd:schema element has xsd:import and/or
	xsd:annotation as its only child element(s).

       SOAP::WSDL has no means of generating WSDL definitions.

   R2110
	In a DESCRIPTION, array	declarations MUST NOT extend or	restrict the
	soapenc:Array type.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2111
	In a DESCRIPTION, array	declarations MUST NOT use wsdl:arrayType attribute
	in the type declaration.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2112
	In a DESCRIPTION, array	declaration wrapper elements SHOULD NOT	be named
	using the convention ArrayOfXXX.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2201
	A document-literal binding in a	DESCRIPTION MUST, in each of its
	soapbind:body element(s), have at most one part	listed in the parts
	attribute, if the parts	attribute is specified.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2210
	If a document-literal binding in a DESCRIPTION does not	specify	the parts
	attribute on a soapbind:body element, the corresponding	abstract
	wsdl:message MUST define zero or one wsdl:parts.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2202
	A wsdl:binding in a DESCRIPTION	MAY contain soapbind:body element(s) that
	specify	that zero parts	form the soap:Body.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2203
	An rpc-literal binding in a DESCRIPTION	MUST refer, in its soapbind:body
	element(s), only to wsdl:part element(s) that have been	defined	using the
	type attribute.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2211
	A MESSAGE described with an rpc-literal	binding	MUST NOT have the xsi:nil
	attribute with a value of "1" or "true"	on the part accessors.

   R2207
	A wsdl:message in a DESCRIPTION	MAY contain wsdl:parts that use	the
	elements attribute provided those wsdl:parts are not referred to by a
	soapbind:body in an rpc-literal	binding.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2204
	A document-literal binding in a	DESCRIPTION MUST refer,	in each	of its
	soapbind:body element(s), only to wsdl:part element(s) that have been
	defined	using the element attribute.

       SOAP::WSDL has no means of generating WSDL definitions.

       Note: SOAP::WSDL	requires that a	DESCRIPTION confirms to	these rules.

   R2208
	A binding in a DESCRIPTION MAY contain soapbind:header element(s) that
	refer to wsdl:parts in the same	wsdl:message that are referred to by its
	soapbind:body element(s).

   R2205
	A wsdl:binding in a DESCRIPTION	MUST refer, in each of its soapbind:header,
	soapbind:headerfault and soapbind:fault	elements, only to wsdl:part
	element(s) that	have been defined using	the element attribute.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2209
	A wsdl:binding in a DESCRIPTION	SHOULD bind every wsdl:part of a
	wsdl:message in	the wsdl:portType to which it refers to	one of
	soapbind:body, soapbind:header,	soapbind:fault or soapbind:headerfault.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2206
	A wsdl:message in a DESCRIPTION	containing a wsdl:part that uses the
	element	attribute MUST refer, in that attribute, to a global element
	declaration.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2302
	A DESCRIPTION MAY use the parameterOrder attribute of an
	wsdl:operation element to indicate the return value and	method
	signatures as a	hint to	code generators.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2303
	A DESCRIPTION MUST NOT use Solicit-Response and	Notification type
	operations in a	wsdl:portType definition.

   R2304
	A wsdl:portType	in a DESCRIPTION MUST have operations with distinct
	values for their name attributes.

       Note: SOAP::WSDL	requires that a	DESCRIPTION confirms to	these rules.

   R2305
	A wsdl:portType	in a DESCRIPTION MUST be constructed so	that the
	parameterOrder attribute, if present, omits at most 1 wsdl:part
	from the output	message.

   R2306
	A wsdl:message in a DESCRIPTION	MUST NOT specify both type and
	element	attributes on the same wsdl:part.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2401
	A wsdl:binding element in a DESCRIPTION	MUST use WSDL SOAP
	Binding	as defined in WSDL 1.1 Section 3.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2701
	The wsdl:binding element in a DESCRIPTION MUST be constructed so
	that its soapbind:binding child	element	specifies the transport
	attribute.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2702
	A wsdl:binding element in a DESCRIPTION	MUST specify the HTTP
	transport protocol with	SOAP binding. Specifically, the	transport
	attribute of its soapbind:binding child	MUST have the value
	"http://schemas.xmlsoap.org/soap/http".

       SOAP::WSDL has no means of generating WSDL definitions.

   R2705
	A wsdl:binding in a DESCRIPTION	MUST use either	be a rpc-literal
	binding	or a document-literal binding.

       SOAP::WSDL has no means of generating WSDL definitions.

       Note: SOAP::WSDL	does not support rpc-literal bindings yet.

   R2706
	A wsdl:binding in a DESCRIPTION	MUST use the value of "literal"
	for the	use attribute in all soapbind:body, soapbind:fault,
	soapbind:header	and soapbind:headerfault elements.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2707
	A wsdl:binding in a DESCRIPTION	that contains one or more
	soapbind:body, soapbind:fault, soapbind:header or soapbind:headerfault
	elements that do not specify the use attribute MUST be interpreted as
	though the value "literal" had been specified in each case.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2709
	A wsdl:portType	in a DESCRIPTION MAY have zero or more wsdl:bindings
	that refer to it, defined in the same or other WSDL documents.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2710
	The operations in a wsdl:binding in a DESCRIPTION MUST result in wire
	signatures that	are different from one another.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2711
	A DESCRIPTION SHOULD NOT have more than	one wsdl:port with the same
	value for the location attribute of the	soapbind:address element.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2714
       For one-way operations, an INSTANCE MUST	NOT return a HTTP response
       that contains a SOAP envelope. Specifically, the	HTTP response entity-
       body must be empty.

       SOAP::WSDL does not act as a server, yet.

   R2727
	For one-way operations,	a CONSUMER MUST	NOT interpret a	successful
	HTTP response status code (i.e., 2xx) to mean the message is valid
	or that	the receiver would process it.

       SOAP::WSDL regards a successful HTTP status code	for a one-way
       operation as an acknowledgement of the RECEIVER having receive (not
       processed!)  the	message.

       SOAP::WSDL makes	no assumptions about the processing of SOAP messages,
       but higher level	clients	may do.

   R2716
	A document-literal binding in a	DESCRIPTION MUST NOT have the
	namespace attribute specified on contained soapbind:body,
	soapbind:header, soapbind:headerfault and soapbind:fault elements.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2717
	An rpc-literal binding in a DESCRIPTION	MUST have the namespace	attribute
	specified, the value of	which MUST be an absolute URI, on
	contained soapbind:body	elements.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2726
	An rpc-literal binding in a DESCRIPTION	MUST NOT have the namespace
	attribute specified on contained soapbind:header, soapbind:headerfault
	and soapbind:fault elements.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2718
	A wsdl:binding in a DESCRIPTION	MUST have the same set of
	wsdl:operations	as the wsdl:portType to	which it refers

       SOAP::WSDL has no means of generating WSDL definitions.

   R2719
	A wsdl:binding in a DESCRIPTION	MAY contain no soapbind:headerfault
	elements if there are no known header faults.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2740
	A wsdl:binding in a DESCRIPTION	SHOULD contain a  soapbind:fault describing
	each known fault.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2741
	A wsdl:binding in a DESCRIPTION	SHOULD contain a soapbind:headerfault
	describing each	known header fault.

       SOAP::WSDL has no means of generating WSDL definitions.

   R2743
	A MESSAGE MAY contain the details of a header processing related fault in a
	SOAP header block that is not described	by a wsdl:headerfault element in the
	corresponding WSDL description.

   R2720
	A wsdl:binding in a DESCRIPTION	MUST use the attribute named part with a
	schema type of "NMTOKEN" on all	contained soapbind:header and
	soapbind:headerfault elements.

   R2749
	A wsdl:binding in a DESCRIPTION	MUST NOT use the attribute named parts on
	contained soapbind:header and soapbind:headerfault elements.

   R2721
	A wsdl:binding in a DESCRIPTION	MUST have the name attribute specified on all
	contained soapbind:fault elements.

   R2754
	In a DESCRIPTION, the value of the name	attribute on a soapbind:fault element
	MUST match the value of	the name attribute on its parent wsdl:fault element.

   R2722
	A wsdl:binding in a DESCRIPTION	MAY specify the	use attribute on contained
	soapbind:fault elements.

   R2723
	If in a	wsdl:binding in	a DESCRIPTION the use attribute	on a contained
	soapbind:fault element is present, its value MUST be "literal".

   R2728
	A wsdl:binding in a DESCRIPTION	that omits the use attribute on	a contained
	soapbind:fault element MUST be interpreted as though use="literal" had been
	specified.

   R2724
	If an INSTANCE receives	a message that is inconsistent with its	WSDL
	description, it	SHOULD generate	a soap:Fault with a faultcode of "Client",
	unless a "MustUnderstand" or "VersionMismatch" fault is	generated.

   R2725
	If an INSTANCE receives	a message that is inconsistent with its	WSDL
	description, it	MUST check for "VersionMismatch", "MustUnderstand" and
	"Client" fault conditions in that order.

   R2729
	A MESSAGE described with an rpc-literal	binding	that is	a response message
	MUST have a wrapper element whose name is the corresponding wsdl:operation
	name suffixed with the string "Response".

   R2735
	A MESSAGE described with an rpc-literal	binding	MUST place the part accessor
	elements for parameters	and return value in no namespace.

   R2737
	A MESSAGE described with an rpc-literal	binding	MUST namespace qualify the
	children of part accessor elements for the parameters and the return value
	with the targetNamespace in which their	types are defined.

   R2738
	A MESSAGE MUST include all soapbind:headers specified on a wsdl:input or
	wsdl:output of a wsdl:operation	of a wsdl:binding that describes it.

   R2739
	A MESSAGE MAY contain SOAP header blocks that are not described	in the
	wsdl:binding that describes it.

   R2753
	A MESSAGE containing SOAP header blocks	that are not described in the
	appropriate wsdl:binding MAY have the mustUnderstand attribute on such SOAP
	header blocks set to '1'.

   R2751
	The order of soapbind:header elements in soapbind:binding  sections of a
	DESCRIPTION MUST be considered independent of the order	of SOAP	header blocks
	in the message.

   R2752
	A MESSAGE MAY contain more than	one instance of	each SOAP header block for
	each soapbind:header element in	the appropriate	child of soapbind:binding in
	the corresponding description.

   R2801
	A DESCRIPTION MUST use XML Schema 1.0 Recommendation as	the basis of user
	defined	datatypes and structures.

   R3100
	REGDATA	of type	uddi:bindingTemplate representing a conformant INSTANCE	MUST
	contain	the uddi:accessPoint element.

   R3002
	REGDATA	of type	uddi:tModel representing a conformant Web service type MUST
	use WSDL as the	description language.

   R3003
	REGDATA	of type	uddi:tModel representing a conformant Web service type MUST be
	categorized using the uddi:types taxonomy and a	categorization of "wsdlSpec".

   R3010
	REGDATA	of type	uddi:tModel representing a conformant Web service type MUST
	follow V1.08 of	the UDDI Best Practice for Using WSDL in a UDDI	Registry.

   R3011
	The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST	itself
	conform	to the Profile.

   R5001
	If an INSTANCE requires	the use	of HTTPS, the location attribute of the
	soapbind:address element in its	wsdl:port description MUST be a	URI whose
	scheme is "https"; otherwise it	MUST be	a URI whose scheme is "http".

       SOAP::WSDL has no means of generating WSDL definitions.

LICENSE	AND COPYRIGHT
       This file contains quotes from
       <http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html>.	To
       these quotes, the legal notice from the document	source applies.

       Rest of this file: Copyright 2007 Martin	Kutter.

       This file is part of SOAP-WSDL. You may distribute/modify it under the
       same terms as perl itself

AUTHOR
       Martin Kutter <martin.kutter fen-net.de>

REPOSITORY INFORMATION
	$Rev: 562 $
	$LastChangedBy:	kutterma $
	$Id: WS_I.pod 562 2008-02-22 20:32:17Z kutterma	$
	$HeadURL: https://soap-wsdl.svn.sourceforge.net/svnroot/soap-wsdl/SOAP-WSDL/trunk/lib/SOAP/WSDL/Manual/WS_I.pod	$

perl v5.32.0			  2020-01-20	   SOAP::WSDL::Manual::WS_I(3)

NAME | DESCRIPTION | RULES CONFIRMED | RULES NOT CONFIRMED | RULES NOT APPLICABLE | LICENSE AND COPYRIGHT | AUTHOR | REPOSITORY INFORMATION

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=SOAP::WSDL::Manual::WS_I&sektion=3&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help