- From: David Booth via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 17 Apr 2005 04:36:25 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv8560
Modified Files:
wsdl20-primer.xml wsdl20-primer.html
Log Message:
Finished updating/editing through section 7.4.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.50
retrieving revision 1.51
diff -C2 -d -r1.50 -r1.51
*** wsdl20-primer.xml 17 Apr 2005 02:42:40 -0000 1.50
--- wsdl20-primer.xml 17 Apr 2005 04:36:22 -0000 1.51
***************
*** 1096,1100 ****
</description>]]></eg>
</example>
! <div3><head>Explanation of Example</head><p><glist><gitem><label><code>xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem><gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{tCheckAvailability}" ></code></label><def><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Check this section. I'm not sure I got it all right. In particular, is the first sample request URI correct? Shouldn't values be in the path component?</edtext></ednote><p>The <code>whttp:location</code> attribute specifies a pattern for serializing input message instance data into the path component of the request URI. The default binding rules for HTTP specify that the default input
serialization for GET is <code>application/x-www-form-urlencoded</code>. Curly braces are used to specify the name of a schema type in the input message schema, which determines what input instance data will be inserted into the path component of the request URI. The curly brace-enclosed name will be replaced with instance data in constructing the path component. Remaining input instance data (not specified by <code>whttp:location</code>) will either be serialized into the query string portion of the URI or into the message body, as follows: if a "/" is appended to a curly brace-enclosed type name, then any remaining input message instance data will be serialized into the message body. Otherwise it will be serialized into query parameters.</p><p>Thus, in this example, each of the elements in the <code>tCheckAvailability</code> type will be serialized into
the query parameters.
--- 1096,1100 ----
</description>]]></eg>
</example>
! <div3><head>Explanation of Example</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</edtext></ednote><p><glist><gitem><label><code>xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem><gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{tCheckAvailability}" ></code></label><def><p>The <code>whttp:location</code> attribute specifies a pattern for serializing input message instance data into the path compnent of the request URI. The default binding rules for HTTP specify that the default input
serialization for GET is <code>application/x-www-form-urlencoded</code>. Curly braces are used to specify the name of a schema type in the input message schema, which determines what input instance data will be inserted into the path component of the request URI. The curly brace-enclosed name will be replaced with instance data in constructing the path component. Remaining input instance data (not specified by <code>whttp:location</code>) will either be serialized into the query string portion of the URI or into the message body, as follows: if a "/" is appended to a curly brace-enclosed type name, then any remaining input message instance data will be serialized into the message body. Otherwise it will be serialized into query parameters.</p><p>Thus, in this example, each of the elements in the <code>tCheckAvailability</code> type will be serialized into
the query parameters.
***************
*** 1126,1182 ****
<div1 id="advanced-topic_ii">
<head>Advanced Topics</head>
! <ednote>
! <name>KevinL</name>
! <date>20040526</date>
! <edtext>
! This section is very incomplete, and topics are still TBD.
! </edtext>
! </ednote>
<div2 id="adv-extensibility">
<head>Extensibility</head>
! <p>WSDL 2.0 provides two extensibility mechanisms: an open content model, which allows XML elements and attributes from other (non-WSDL 2.0) XML namespaces to be interspersed into a WSDL document; and <xspecref href="&w3c-designation-part1;#Feature">Features</xspecref> and <xspecref href="&w3c-designation-part1;#Property">Properties</xspecref>. Both mechanisms use URIs to identify the semantics of the extensions. For extension XML elements and attributes, the namespace URI of the extension element or attribute acts as an unambiguous name for the semantics of that extension. For Features and Properties, the Feature or Property is named by a URI.</p><p>In either case, the URI that identifies the semantics of an extension SHOULD be dereferenceable to a document that describes the semantics of that extension. As of this writing, there is no generally accepted standard for what kind of document that should be. However, the <loc href="http://www.w3.org/2001/tag/">W3C TAG</loc> has been discussing the ssue (see TAG issue <loc href="http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</loc>) and is likely to provide guidance at some point.</p><div3 id="adv-optional-versus-required"><head>Optional Versus Required Extensions</head><p>Extensions can either be required or optional.</p><p>An <emph>optional</emph> extension is one that the client may either engage or ignore, entirely at its discretion, and is signaled by attribute <code>wsdl:required="false"</code> or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). Thus, a WSDL processor, acting on behalf of the client, that encounters an unknown optional extension can safely ignore it and continue to process the WSDL 2.0 document. However, it is important to stress that optional extensions are only optional to the <emph>client</emph> -- not the service. A service MUST support all optional and required extensions that it advertises in its WSDL 2.0 document. </p><p>A <emph>required</mph> extension is one that MUST be supported and engaged by the client in order for the interaction to procede properly, and is signaled by attribute <code>wsdl:required="true"</code>. If a WSDL processor, acting on behalf of the client, encounters a required extension that it does not recognize or does not support, then it cannot safely continue to process the WSDL 2.0 document. In most practical cases, this is likely to mean that it will have to fault and seek user intervention. </p></div3><div3 id="adv-scope-of-wsdl-required"><head>Scoping of the wsdl:required Attribute</head><ednote><edtext>ToDo: Need to check the scoping rules to see if this is correct.</edtext></ednote><p>As a convenience mechanism, the <code>wsdl:required</code> attribute need not be specified on every extension element. If it is omitted from an extension element, its effective value is inherited from the smallest enclosing scope that explicitly sets its value. If there is no enclosing scope that explicitly sets its value, thenits value defaults to <code>false</code>. </p><p>Because portions of a Web service description can be written in different physical documents by different people, one should be cautious about setting <code>wsdl:required="false"</code> when an outer scope, written by someone else, had set <code>wsdl:required="true"</code>.</p></div3></div2><div2 id="adv-FP">
<head>Features and Properties</head>
! <p>[Add material from http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html ]</p>
! </div2><div2 id="adv-import-and-authoring">
<head>Import mechanism and authoring style</head>
! <ednote>
! <name>Arthur</name>
! <date>20050322</date>
! <edtext>Here is my input for the import mechanism. Please edit. I put the complete WSDL and XSD files in the Test Suite
! in test case CreditCardFaults-1G. See http://dev.w3.org/cvsweb/2002/ws/desc/test-suite/documents/good/CreditCardFaults-1G/</edtext>
! </ednote>
- <p>[Discuss how WSDL documents should be factored to allow significant components to be reused.]</p>
<p>
In some circumstances you may want to split up a Web service description into two or more documents.
! For example, if a description if getting long or is being worked on by several authors, then it
is convenient to divide it into several parts.
Another very important case is when you expect parts of the description to be reused in several contexts.
! Clearly it is undesirable to cut and paste sections of one document into another since that is error prone
and leads to maintenance problems.
! More importantly, you may need to reuse components that belong to a namespace that is different than
that of the document you are writing, in which case the rules of WSDL 2.0 prevent you from simply cutting and pasting them
into your document.
! To solve this problem,
! WSDL 2.0 provides two mechanisms for modularizing Web service description documents: import and include.
This section discusses the import mechanism and describes some typical cases where it is be used.
</p>
<p>
! The import mechanism lets you refer to the definitions of Web service components that belong to other namespaces.
! To illustrate this, consider the hotel reservation service. Let's suppose that the reservation service uses a
standard credit card validation service that is provided by a financial services company. Furthermore, suppose that
companies in the financial services industry decided that it would be useful to report errors in credit card validation
! using a common set of faults. These faults are defined in the following Web service description:
</p>
<example id="credit-card-faults">
<head>Standard Credit Card Validation Faults (credit-card-faults.wsdl)</head>
! <eg><![CDATA[
! <?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2004/08/wsdl"
targetNamespace="http://finance.example.com/CreditCards/wsdl"
--- 1126,1254 ----
<div1 id="advanced-topic_ii">
<head>Advanced Topics</head>
!
<div2 id="adv-extensibility">
<head>Extensibility</head>
! <p>WSDL 2.0 provides two extensibility mechanisms: an open content model, which allows XML elements and attributes from other (non-WSDL 2.0) XML namespaces to be interspersed into a WSDL document; and <xspecref href="&w3c-designation-part1;#Feature">Features</xspecref> and <xspecref href="&w3c-designation-part1;#Property">Properties</xspecref>. Both mechanisms use URIs to identify the semantics of the extensions. For extension XML elements and attributes, the namespace URI of the extension element or attribute acts as an unambiguous name for the semantics of that extension. For Features and Properties, the Feature or Property is named by a URI.</p><p>In either case, the URI that identifies the semantics of an extension SHOULD be dereferenceable to a document that describes the semantics of that extension. As of this writing, there is no generally accepted standard for what kind of document that should be. However, the <loc href="http://www.w3.org/2001/tag/">W3C TAG</loc> has been discussing the ssue (see TAG issue <loc href="http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</loc>) and is likely to provide guidance at some point.</p><div3 id="adv-optional-versus-required"><head>Optional Versus Required Extensions</head><p>Extensions can either be required or optional.</p><p>An <emph>optional</emph> extension is one that the client may either engage or ignore, entirely at its discretion, and is signaled by attribute <code>wsdl:required="false"</code> or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). Thus, a WSDL processor, acting on behalf of the client, that encounters an unknown optional extension can safely ignore it and continue to process the WSDL 2.0 document. However, it is important to stress that optional extensions are only optional to the <emph>client</emph> -- not the service. A service MUST support all optional and required extensions that it advertises in its WSDL 2.0 document. </p><p>A <emph>required</mph> extension is one that MUST be supported and engaged by the client in order for the interaction to procede properly, and is signaled by attribute <code>wsdl:required="true"</code>. If a WSDL processor, acting on behalf of the client, encounters a required extension that it does not recognize or does not support, then it cannot safely continue to process the WSDL 2.0 document. In most practical cases, this is likely to mean that it will have to fault and seek user intervention. </p></div3><div3 id="adv-scope-of-wsdl-required"><head>Scoping of the wsdl:required Attribute</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Need to check the scoping rules to see if this is correct.</edtext></ednote><p>As a convenience mechanism, the <code>wsdl:required</code> attribute need not be specified on every extension element. If it is omitted from an extension element, its effective value is inherited from the smallest enclosing scope that explicitly sets its value. If there is no enclosing cope that explicitly sets its value, then its value defaults to <code>false</code>. </p><p>Because portions of a Web service description can be written in different physical documents by different people, one should be cautious about setting <code>wsdl:required="false"</code> when an outer scope, written by someone else, had set <code>wsdl:required="true"</code>.</p></div3></div2><div2 id="adv-FP">
<head>Features and Properties</head>
! <p>After a few successful trials of the reservation service, GreatH decides that it is time to make the makeReservation operation secure, so that sensitive credit-card information is not being sent across the public network in a snoopable fashion. We will do this using the WSDL 2.0 Features and Properties mechanisms <bibref ref="WSDL-PART1"/>, which is modeled after the Features and Properties mechanism defined in SOAP 1.2 <bibref ref="SOAP12-PART1"/>.</p><p>To facilitate presentation, this section will assume the existence of a hypothetical security feature named "<code>http://features.example.com/2005/securityFeature</code>", which defines, in the abstract, the idea of message confidentiality. This feature has an associated property, named "<code>http://features.example.com/2005/securityFeature/securityLevel</code>", which defines various safety levels (from 0 meaning cleartext, all the way through 10, involving highly complex cryptographic algorithms with keys in the tens of thousands of bits). We also assume that a SOAP module, named "<code>http://features.example.com/2005/modules/Security</code>", has been defined, which implements the security feature described above.</p><p>GreatH has chosen an abstract security feature which is standard in the fictitious hotels community, and has integrated both a SOAP module and a new secure HTTP binding into its infrastructure – both of which implement the security feature (the SOAP module does this inside the SOAP envelope using headers, and the secure binding does it at the transport layer). Now they'd like to advertise and control the usage of these extensions using WSDL 2.0.</p>
! <div3 id="adv-FP-soap-modules"><head>SOAP Modules</head><p>The first step GreatH takes is to require the usage of the SOAP module in their normal SOAP/HTTP endpoint, which looks like this:</p><example id="example-fp-requiring-soap-module">
! <head>Requiring a SOAP Module in an Endpoint</head>
! <eg xml:space="preserve">
! <![CDATA[
! . . .
! <service name="reservationService"
! interface="tns:reservationInterface">
!
! <endpoint name="reservationEndpoint"
! binding="tns:reservationSOAPBinding"
! address ="http://greath.example.com/2004/reservation">
! <wsoap:module uri="http://features.example.com/2005/modules/Security"
! required="true"/>
! </endpoint>
!
! </service>
! . . .
! ]]></eg>
! </example><p>This syntax indicates that a SOAP Module is required by this endpoint. This means that anyone using this endpoint must both understand the specification that the module URI references, and must use that specification when communicating with the endpoint in question, which typically means including appropriate SOAP headers on transmitted messages.
!
! </p><p>If the "required" attribute was not present, or if it was set to "<code>false</code>", then the <code><wsoap:module></code> syntax would indicate optional the availability of the referenced module, rather than a requirement to engage it, as explained in <specref ref="adv-optional-versus-required"/>.</p></div3><div3 id="adv-FP-abstract-features"><head>Abstract Features</head><p>Since GreatH began the web service improvements, they have been talking to several travel agents. The possibility of making their simple hotel interface an industry standard amongst a consortium of hotels has come up, and as such they would like to enable specifying the requirement for the "makeReservation" operation to be secure at the interface level – in other words indicating that the operation must be secure, but without specifying exactly how that should concretely be achieved (to enable maximal reuse of the interface). The next example uses the WSDL 2.0 Feature element to indicate this.</p><example id="exampl-fp-declaring-abstract-feature">
! <head>Declaring an Abstract Feature Requirement</head>
! <eg xml:space="preserve">
! <![CDATA[. . .
! <interface name="reservationInterface">
! <operation name="makeReservation">
! <feature uri="http://features.example.com/2005/securityFeature"
! required="true"/>
! . . . [The rest of the operation is unchanged] . . .
! </operation>
! </interface>
! . . .]]></eg>
! </example><p>This declaration indicates that understanding of, and compliance with, the specified security feature is required for all uses of the "makeReservation" operation. The security feature is <emph>abstract</emph>, which means that although it defines semantics and a level of detail about its general operation, it expects a concrete component (like a SOAP module or binding) to actually realize the functionality.</p><p>By definition, if you understand a SOAP module, you understand which (if any) abstract features it implements. Therefore, since the security module in this example is defined as an implementation of the abstract security feature, we know that the use of this module satisfies the requirement to implement the feature. Therefore users of the HTTP endpoint shown above (with the required SOAP module) will be able to make use of it. GreatH also defines a new endpoint:</p><example id="example-fp-soap-over-shttp">
! <head>A SOAP Binding Over a Secure HTTP Protocol</head>
! <eg xml:space="preserve">
! <![CDATA[. . .
! <binding name="reservationSecureSOAPBinding"
! interface="tns:reservationInterface"
! type="http://www.w3.org/2004/08/wsdl/soap12"
! wsoap:protocol="http://bindings.example.com/SOAPBindings/secureHTTP">
! . ..
! </binding>
! . . .
! <service name="reservationService">
! . . .
! <endpoint name="secureReservationEndpoint"
! binding="tns:reservationSecureSOAPBinding"
! address="https://greath.example.com/2004/secureReservation"/>
! </service>
! . . .]]></eg>
! </example><p>The user will have a choice as to which of the endpoints, and therefore which binding, is to be used, but they both satisfy the abstract feature requirement specified in the interface.</p><p>Note that it is not necessary to declare the abstract feature in order to use/require the SOAP module, or in order to use/require the secure binding. Abstract feature declarations serve purely to indicate requirements which must be fulfilled by more concrete components such as modules or bindings. In other words, the abstract feature declaration allows components such as interfaces to be reused without caring exactly which SOAP modules or bindings satisfy the feature.</p></div3><div3 id="adv-fp-properties"><head>Properties</head><p>So far we've discussed how to indicate the availability or the "requiredness" of features and modules. Often it is not enough to indicate that a particular extension is available/required: you also need some way to control or parameterize aspects of its behavior. This i achieved by the use of WSDL 2.0 <emph>properties</emph>. Each feature, SOAP module, or SOAP binding may express a variety of <emph>properties</emph> in its specification. These properties are very much like variables in a programming language. If GreatH would like to indicate that the securityLevel property should be 5 for the "makeReservation" operation, it would look like this:</p><example id="example-fp-def-prop">
! <head>Defining a Property</head>
! <eg xml:space="preserve">
! <![CDATA[. . .
! <interface name="reservationInterface">
! <operation name="makeReservation">
! <property
! uri="http://features.example.com/2005/securityFeature/securityLevel">
! <value>5</value>
! </property>
! . . . [rest of operation definition] . . .
! </operation>
! </interface>
! . . .]]></eg>
! </example><p>The <code>property</code> element specifies which property is to be set. By setting the <code>value</code> element, a toolkit processing this WSDL 2.0 document is informed that the securityLevel property must be set to 5. The particular meanings of any such values are up to the implementations of the modules/bindings that use them. The <code>property</code> element can be placed at many different levels in a WSDL document (see "Property Composition Model", section 2.8.1.1 in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/>).
! </p><p>It is also possible to provide a <emph>constraint</emph> on the value space for a given property. This allows the author of the WSDL 2.0 document to indicate that several valid values for the property are possible for a given scope, limiting the value space already described in the specification that defined the property. Let's extend our example to make this clearer.</p><p>The security feature specification defines securityLevel as an integer with values between 1 and 10, each of which indicates, according to the spec, a progressively higher level of security. The GreatH service authors, having read the relevant specifications, have decided that any security level between 3 and 7 will be supported by their infrastructure. Levels less than 3 are deemed unsafe for GreatH's purposes, and levels greater than 7 require too much in the way of resources to make it worthwhile. We can express this in WSDL 2.0 as follows:</p><example id="example-fp-def-prop-constraints">
! <head>Defining Property Constraints</head>
! <eg xml:space="preserve">
! <![CDATA[. . .
! <types>
! <schema>
! <simpleType name="securityLevelConstraint">
! <restriction base="xs:int">
! <min 3, max 7> <!-- check schema for syntax -->
! </restriction>
! </simpleType>
! </schema>
! </types>
! . . .
! <property uri="http://features.example.com/2005/securityFeature/securityLevel">
! <constraint type="tns:securityLevelConstraint">
! </property>
! . . .
! ]]></eg>
! </example><p>First we define, in the <code>types</code> section, an XML Schema restriction type over integers with minimum and maximum values, per our discussion above. Then instead of using the <code>value</code> element inside <code>property</code>, we use <code>constraint</code> and refer to the restriction type. This informs the implementation that the property must have the appropriate values. This information might be useful to a deployment user interface, for example, which might allow an administrator to set this value with a slider when deploying the service.</p></div3></div2><div2 id="adv-import-and-authoring">
<head>Import mechanism and authoring style</head>
!
!
<p>
In some circumstances you may want to split up a Web service description into two or more documents.
! For example, if a description is getting long or is being developed by several authors, then it
is convenient to divide it into several parts.
Another very important case is when you expect parts of the description to be reused in several contexts.
! Clearly it is undesirable to cut and paste sections of one document into another, since that is error prone
and leads to maintenance problems.
! More importantly, you may need to reuse components that belong to a wsdl:targetNamespace that is different than
that of the document you are writing, in which case the rules of WSDL 2.0 prevent you from simply cutting and pasting them
into your document.
! </p><p>To solve these problems,
! WSDL 2.0 provides two mechanisms for modularizing Web service description documents: <code>import</code> and <code>include</code>.
This section discusses the import mechanism and describes some typical cases where it is be used.
</p>
<p>
! The <code>import</code> mechanism lets you refer to the definitions of Web service components that belong to other namespaces.
! To illustrate this, consider the GreatH hotel reservation service. Suppose that the reservation service uses a
standard credit card validation service that is provided by a financial services company. Furthermore, suppose that
companies in the financial services industry decided that it would be useful to report errors in credit card validation
! using a common set of faults, and have defined these faults in the following Web service description:
</p>
<example id="credit-card-faults">
<head>Standard Credit Card Validation Faults (credit-card-faults.wsdl)</head>
! <eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2004/08/wsdl"
targetNamespace="http://finance.example.com/CreditCards/wsdl"
***************
*** 1184,1218 ****
xmlns:cc="http://finance.example.com/CreditCards/xsd">
! <documentation>
! This document describes standard faults for use by Web services
! that process credit cards.
! </documentation>
! <types>
! <xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"
! namespace="http://finance.example.com/CreditCardFaults/xsd"
! schemaLocation="credit-card-faults.xsd" />
! </types>
! <interface name="creditCardFaults">
! <fault name="cancelledCreditCard" element="cc:CancelledCreditCard">
! <documentation>Thrown when the credit card has been cancelled.</documentation>
! </fault>
! <fault name="expiredCreditCard" element="cc:ExpiredCreditCard">
! <documentation>Thrown when the credit card has expired.</documentation>
! </fault>
! <fault name="invalidCreditCardNumber" element="cc:InvalidCreditCardNumber">
! <documentation>Thrown when the credit card number is invalid.
! This fault will occur if the wrong credit card type is specified.</documentation>
! </fault>
! <fault name="invalidExpirationDate" element="cc:InvalidExpirationDate">
! <documentation>Thrown when the expiration date is invalid.</documentation>
! </fault>
! </interface>
</description>]]></eg>
--- 1256,1291 ----
xmlns:cc="http://finance.example.com/CreditCards/xsd">
! <documentation>
! This document describes standard faults for use
! by Web services that process credit cards.
! </documentation>
! <types>
! <xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"
! namespace="http://finance.example.com/CreditCardFaults/xsd"
! schemaLocation="credit-card-faults.xsd" />
! </types>
! <interface name="creditCardFaults">
! <fault name="cancelledCreditCard" element="cc:CancelledCreditCard">
! <documentation>Thrown when the credit card has been cancelled.</documentation>
! </fault>
! <fault name="expiredCreditCard" element="cc:ExpiredCreditCard">
! <documentation>Thrown when the credit card has expired.</documentation>
! </fault>
! <fault name="invalidCreditCardNumber" element="cc:InvalidCreditCardNumber">
! <documentation>Thrown when the credit card number is invalid.
! This fault will occur if the wrong credit card type is specified.
! </documentation>
! </fault>
! <fault name="invalidExpirationDate" element="cc:InvalidExpirationDate">
! <documentation>Thrown when the expiration date is invalid.</documentation>
! </fault>
! </interface>
</description>]]></eg>
***************
*** 1223,1227 ****
<code>expiredCreditCard</code>, <code>invalidCreditCardNumber</code>, and <code>invalidExpirationDate</code>.
These components belong to the namespace <code>http://finance.example.com/CreditCards/wsdl</code>.
! The faults are reused in the following hotel reservation service:
</p>
--- 1296,1300 ----
<code>expiredCreditCard</code>, <code>invalidCreditCardNumber</code>, and <code>invalidExpirationDate</code>.
These components belong to the namespace <code>http://finance.example.com/CreditCards/wsdl</code>.
! </p><p>Because these faults are defined in a different wsdl:targetNamespace than the one used by the GreatH Web service description, import must be used to make them available within the GreatH Web service description, as shown in the following example:
</p>
***************
*** 1241,1252 ****
</documentation>
! <import namespace="http://finance.example.com/CreditCards/wsdl" location="credit-card-faults.wsdl"/>
!
. . .
-
<interface name="reservation" extends="cc:creditCardFaults">
-
. . .
-
<operation name="makeReservation"
pattern="http://www.w3.org/2004/03/wsdl/in-out">
--- 1314,1322 ----
</documentation>
! <import namespace="http://finance.example.com/CreditCards/wsdl"
! location="credit-card-faults.wsdl"/>
. . .
<interface name="reservation" extends="cc:creditCardFaults">
. . .
<operation name="makeReservation"
pattern="http://www.w3.org/2004/03/wsdl/in-out">
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.31
retrieving revision 1.32
diff -C2 -d -r1.31 -r1.32
*** wsdl20-primer.html 17 Apr 2005 02:42:40 -0000 1.31
--- wsdl20-primer.html 17 Apr 2005 04:36:22 -0000 1.32
***************
*** 320,323 ****
--- 320,329 ----
    7.2 <a href="#adv-FP">Features and
Properties</a><br />
+         7.2.1 <a
+ href="#adv-FP-soap-modules">SOAP Modules</a><br />
+         7.2.2 <a
+ href="#adv-FP-abstract-features">Abstract Features</a><br />
+         7.2.3 <a
+ href="#adv-fp-properties">Properties</a><br />
    7.3 <a
[...979 lines suppressed...]
<code>id</code> attributes. The id of the
--- 5068,5072 ----
<h4>7.14.1 Using the id Attribute to Identify Inline Schemas</h4>
! <p><a href="#schemaIds.wsdl">Example 7-20</a> shows the use of the
<code>id</code> attribute. Both of the inline schemas have
<code>id</code> attributes. The id of the
***************
*** 4818,4822 ****
<p style="text-align: left" class="exampleHead"><a
id="schemaIds.wsdl" name="schemaIds.wsdl"></a><i><span>Example
! 7-15.</span> Using Ids in Inline Schemas: schemaIds.wsdl</i></p>
<div class="exampleInner">
--- 5085,5089 ----
<p style="text-align: left" class="exampleHead"><a
id="schemaIds.wsdl" name="schemaIds.wsdl"></a><i><span>Example
! 7-20.</span> Using Ids in Inline Schemas: schemaIds.wsdl</i></p>
<div class="exampleInner">
Received on Sunday, 17 April 2005 04:36:25 UTC