- From: David Booth via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 17 Apr 2005 23:17:20 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv5033
Modified Files:
wsdl20-primer.xml wsdl20-primer.html
Log Message:
Finished updating/editing through sec 7.9 (Enabling Easy Message Dispatch).
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.53
retrieving revision 1.54
diff -C2 -d -r1.53 -r1.54
*** wsdl20-primer.xml 17 Apr 2005 18:42:48 -0000 1.53
--- wsdl20-primer.xml 17 Apr 2005 23:17:18 -0000 1.54
***************
*** 1130,1134 ****
<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>
--- 1130,1134 ----
<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 the processor will require manual intervention to deal with the extension. For example, a client developer might manually provide an implementation for the required extension to the WSDL processor. </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 fro 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, 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>
***************
*** 1547,1580 ****
<div2 id="adv-RPCstyle">
<head>RPC Style</head>
! <p>Section <specref ref="more-interfaces-op-attr"/> mentioned that the (optional) <code>style</code> attribute of an interface operation is used to indicate that the operation conforms to a particular pre-defined operation style, or set of constraints. Operation styles are named using URIs, in order to be unambigous while still permitted new styles to be defined. WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> defines three such operation styles; one of these is the <emph>RPC Style</emph> (<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC Style</xspecref>).</p><p>The RPC Style is designed to facilitate programming language
bindings to WSDL 2.0 constructs. It allows a WSDL 2.0 interface
operation to be easily mapped to a method or function signature, such as a method signature in
! Java(TM) or C#. A WSDL 2.0 document makes use of the RPC Style in an interface operation by first defining the operation in conformance with all of the RPC Style rules (detailed in section "<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC Style</xspecref>"), and then setting that operation's <code>style</code> attribute to include the URI that identifies the RPC Style, thus asserting that the operation does indeed conform to the RPC Style. If desired, the <code>style</code> attribute can actually be set to a list of URIs, indicating that the operation simultaneously conforms to multiple styles.</p><p> detail conventions for defining </p><p>The RPC Style </p><p>An interface operation that uses the In-Out MEP (see WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> section "<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#in-out">In-Out</xspecref>") can be mapped easily
! to a method signature in the target language. The method signature corresponds to an
! RPC call by following the constraints that are specified in Section
! 3.1 [1]. These rules define the relationship between XML Schema
! elements that constitute the input and ouput messages. Since the
! interface operation designates a single method signature, the
! relationship between the input and output elements is significant. In
! order to provide a meaningful signature for language bindings,
! parameters in a method signature that are inputs, outputs, or those
! that are both input and outputs as well as return value(s) in a
! signature should be easily determinable. The rules in Section 3.1.1
! determine how the content of the input and output elements map to the
! parameters. For example, a local element that occurs both as the first
! child of the input element and the output element designates an in-out
! parameter for the method signature. Elements that occur only as
! local element children of the input element are considered to
! represent input parameters of the method signature. Similarly,
! elements that occur only as local element children of the output
! element represent output parameters.</p></div2>
<div2 id="adv-message-dispatch">
<head>Enabling Easy Message Dispatch</head>
! <p>Suppose a WSDL document has two input-output operation and uses the same input message schema for both. When the service receives the input message, how will the service know which operation is supposed to be invoked? Although the data contained in a runtime message may be sufficient to distinguish between the operations, this can be a problem for WSDL toolkits that are looking only at the message schema, rather than the actual messages. (For example, the toolkit may be operating at designtime, without access to the runtime messages.) This is the problem of <emph>dispatch</emph>. How can a WSDL document be written to ensure easy message dispatch? </p>
! <p>One technique is to ensure that the top-level elements declared in the message schema are different for different operations. This is probably the most general solution, since it is guaranteed to provide a way to perform dispatch, without preventing toolkits from potentially using other dispatch techniques.</p>
! <p>Another technique is to define a required feature that enables a particular dispatching convention. This approach makes the dispatching convention explicit, although it may not be supported by every WSDL toolkit.</p>
</div2><div2 id="adv-get-vs-post"><head>GET Versus POST: Which to Use?</head>
! <p>[Add material from http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html that prescribes when to use GET versus POST as well as some useful example]</p>
</div2>
--- 1547,1637 ----
<div2 id="adv-RPCstyle">
<head>RPC Style</head>
! <p>Section <specref ref="more-interfaces-op-attr"/> mentioned that the (optional) <code>style</code> attribute of an interface operation is used to indicate that the operation conforms to a particular pre-defined operation style, or set of constraints. Actually, if desired the <code>style</code> attribute can hold a list of URIs, indicating that the operation simultaneously conforms to multiple styles.</p><p>Operation styles are named using URIs, in order to be unambigous while still permitted new styles to be defined without requiring updates to the WSDL 2.0 language. WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> defines three such operation styles; one of these is the RPC Style (<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC Style</xspecref>).</p><p>The <emph>RPC Style</emph> is designed to facilitate programming language
bindings to WSDL 2.0 constructs. It allows a WSDL 2.0 interface
operation to be easily mapped to a method or function signature, such as a method signature in
! Java(TM) or C#. RPC Style is restricted to operations that use the In-Out or In-Only MEPs (see <specref ref="more-interfaces-meps"/>).</p><p>A WSDL 2.0 document makes use of the RPC Style in an interface operation by first defining the operation in conformance with all of the RPC Style rules, and then setting that operation's <code>style</code> attribute to include the URI that identifies the RPC Style, thus asserting that the operation does indeed conform to the RPC Style. These rules permit the input and output message schemas to map conveniently to inputs and outputs of a method signature. Roughly, input elements map to input parameters, output elements map to output parameters, and elements that appear both in the input and output message schemas map to input/output parameters. WSDL 2.0 Part 2 section "<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC Style</xspecref>" provides full details of the mapping rules and requirements.</p><p>The RPC Style also permits the ful signature of the intended mapping to be indicated explicitly, using the <code>wrpc:signature</code> attribute defined in WSDL 2.0 Part 2 section "<xspecref href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts">wrpc:signature Extension</xspecref>". This is an (optional) extension to the WSDL 2.0 language whose value designates how input and output message schema elements map to input and output parameters in the method signature. </p><p>The example below illustrates how RPC Style may be used to designate a
! signature. This example is a modified version of the GreatH reservation
! service. In particular, the <code>interface</code> and <code>types</code> sections have been modified to specify and conform to the RPC Style.</p><example id="example-rpc-style">
! <head>Specifying RPC Style </head>
!
! <eg><![CDATA[. . .
! <types>
!
! <xs:element name="checkAvailability">
! <xs:complexType>
! <xs:sequence>
! <xs:element name="checkInDate" type="xs:date"/>
! <xs:element name="checkOutDate" type="xs:date"/>
! <xs:element name="roomType" type="xs:string"/>
! </xs:sequence>
! </xs:complexType>
! </xs:element>
!
! <xs:element name="checkAvailabilityResponse">
! <xs:complexType>
! <xs:sequence>
! <xs:element name="roomType" type="xs:string"/>
! <xs:element name="rateType" type="xs:string"/>
! <xs:element name="rate" type="xs:double"/>
! </xs:sequence>
! </xs:complexType>
! </xs:element>
! . . .
! </types>
!
! <interface name = "reservationInterface" >
!
! <operation name="checkAvailability"
! pattern="http://www.w3.org/@@@@/@@/wsdl/in-out"
! style="http://www.w3.org/@@@@/@@/wsdl/style/rpc"
! wrpc:signature=
! "checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return">
! <input messageLabel="In"
! element="tns:checkAvailability" />
! <output messageLabel="Out"
! element="tns:checkAvailabilityResponse" />
!
! </operation>
! . . .
! </interface>
! . . .]]></eg></example><p>Note that the interface operation's name "<code>checkAvailability</code>", is the
! same as the localPart of the input element's QName,
! "<code>tns:checkAvailability</code>". This is one of the requirements of the RPC Style. The name of the operation is
! used as the name of the method in a language binding,
! subject to further mapping restrictions specific to the target
! programming language. In this case, the name of the method would be
! "checkAvailability".</p><p>The local children elements of the input element and output element
! designate
! the parameters and the return type for a method call. Note that the
! elements <code>checkInDate</code>, <code>checkOutDate</code> are input parameters, however the
! element <code>roomType</code> is an in-out parameter, as it appears both as a local
! element child of both input and output elements. This indicates that the reservation system may change the room type
! requested based on availability. </p><p>The reservation service also returns a rate type for the reservation, such as "rack rate". The return value for the method is designated as the
! "rate" element.</p><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Add a bib entry for JAX RPC 1.1 - Java(TM) API for XML-based RPC JAX-RPC 1.1
! (http://java.sun.com/xml/downloads/jaxrpc.html) - and fill in the @@bibref@@ below.</edtext></ednote><p>Based on the value of the <code>wrpc:signature</code> attribute, the method signature would be obtained following the order of the parameters. A sample
! mapping is provided below for the Java(TM) language. This example was created using JAX RPC 1.1 @@bibref@@
! for mapping simple types to Java types and
! designated inout and output parameters by using Holder classes.</p><example id="example-rpc-style-java-sig">
! <head>Sample Java(TM) Signature for RPC Style</head>
!
! <eg><![CDATA[public interface reservationInterface extends Remote{
!
! double checkAvailability(java.util.calendar checkInDate,
! java.util.calendar checkOutDate,
! StringHolder roomType,
! StringHolder rateType) throws RemoteException;
! . . .
! }
! ]]></eg></example><p>Programming languages may further specify how faults are mapped to
! langauage constructs and their scopes, such as Exceptions, but they
! are not specific to RPC style.</p></div2>
<div2 id="adv-message-dispatch">
<head>Enabling Easy Message Dispatch</head>
! <p>Suppose a WSDL 2.0 document has two input-output operations and uses the same input message schema for both. When the service receives the input message, how will the service know which operation is supposed to be invoked? Although the data contained in a runtime message may be sufficient to distinguish between the operations, this can be a problem for WSDL 2.0 toolkits that are looking only at the message schema, rather than the actual messages. (For example, the toolkit may be operating at designtime, without access to the runtime messages.) This is the problem of <emph>dispatch</emph>. How can a WSDL 2.0 document be written to ensure easy message dispatch? Strategies include:</p>
! <ulist><item><p><b>Use unique top-level elements</b>, i.e., ensure that the top-level elements declared in the message schemas are different for different operations. This is probably the most general solution, since it is guaranteed to provide a way to perform dispatch, without preventing toolkits from potentially using other dispatch techniques.</p></item><item><p><b>Include a required extension</b> that enables a particular dispatching convention. This approach makes the dispatching convention explicit, although it may not be supported by every WSDL toolkit. However, as explained in <specref ref="adv-optional-versus-required"/>, toolkits that do not natively support the extension could seek manual input, thus permitting a client developer to supply an appropriate module that implements the necessary extension. This strategy has thus permits future WSDL toolkits to support and process the extension automatically, while also ensuring that the extension will be handled properly by toolkits that re not yet able to process it automatically.</p></item></ulist>
! <p>To ensure that client and service implementations can easily determine the interface operation under which a received message was sent (even though not every client or service may need to make such a determination), it is considered good practice to follow one of the above strategies when authoring WSDL 2.0 documents.</p>
</div2><div2 id="adv-get-vs-post"><head>GET Versus POST: Which to Use?</head>
! <p>@@@@@@@@@@@@@@@@@@@@@@@@@@@@</p><p>[Add material from http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html that prescribes when to use GET versus POST as well as some useful example]</p>
</div2>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.34
retrieving revision 1.35
diff -C2 -d -r1.34 -r1.35
*** wsdl20-primer.html 17 Apr 2005 18:42:48 -0000 1.34
--- wsdl20-primer.html 17 Apr 2005 23:17:18 -0000 1.35
***************
*** 275,287 ****
href="#more-interfaces-operations">Interface Operations</a><br />
        5.4.1 <a
! href="#id5208184">Operation Attributes</a><br />
        5.4.2 <a
! href="#id5208340">Operation Message References</a><br />
            5.4.2.1
! <a href="#id5208392">The messageLabel Attribute</a><br />
            5.4.2.2
! <a href="#id5208428">The element Attribute</a><br />
            5.4.2.3
! <a href="#id5208492">Multiple infault or outfault
Elements</a><br />
        5.4.3 <a
--- 275,287 ----
href="#more-interfaces-operations">Interface Operations</a><br />
        5.4.1 <a
! href="#more-interfaces-op-attr">Operation Attributes</a><br />
        5.4.2 <a
! href="#id5208344">Operation Message References</a><br />
            5.4.2.1
! <a href="#id5208397">The messageLabel Attribute</a><br />
            5.4.2.2
! <a href="#id5208433">The element Attribute</a><br />
            5.4.2.3
! <a href="#id5208497">Multiple infault or outfault
Elements</a><br />
        5.4.3 <a
***************
*** 308,312 ****
Binding Extension</a><br />
        6.6.1 <a
! href="#id5209842">Explanation of Example</a><br />
7. <a href="#advanced-topic_ii">Advanced Topics</a><br />
    7.1 <a
--- 308,312 ----
Binding Extension</a><br />
        6.6.1 <a
! href="#id5209846">Explanation of Example</a><br />
7. <a href="#advanced-topic_ii">Advanced Topics</a><br />
    7.1 <a
***************
*** 343,386 ****
    7.6 <a href="#adv-MTOM">MTOM
Support</a><br />
!     7.7 <a href="#adv-security">Security
! Considerations</a><br />
!     7.8 <a href="#adv-RPCstyle">Operation Style
! and RPC</a><br />
!     7.9 <a
href="#adv-message-dispatch">Enabling Easy Message
Dispatch</a><br />
!     7.10 <a href="#adv-get-vs-post">GET Versus
POST: Which to Use?</a><br />
!     7.11 <a
href="#adv-service-references">Service References</a><br />
!         7.11.1 <a
href="#reservationDetails">The Reservation Details Web
Service</a><br />
!         7.11.2 <a
href="#reservationList">The Reservation List Web Service</a><br />
!     7.12 <a href="#adv-xml-schema-examples">XML
Schema Examples</a><br />
!     7.13 <a
href="#adv-multiple-inline-schemas">Multiple In-Line
Schemas</a><br />
!         7.13.1 <a
! href="#id5212651">Schemas in Imported Documents</a><br />
!         7.13.2 <a
! href="#id5212955">Multiple Inline Schemas on One Document</a><br />
!     7.14 <a href="#adv-schema-location">The
schemaLocation Attribute</a><br />
!         7.14.1 <a
! href="#id5213262">Using the id Attribute to Identify Inline
Schemas</a><br />
!     7.15 <a href="#adv-rdf-mapping">Mapping to
RDF and Semantic Web</a><br />
!     7.16 <a href="#adv-notes-on-uris">Notes on
URIs</a><br />
!         7.16.1 <a
href="#adv-namespaces-and-schema-locations">XML Namespaces and
Schema Locations</a><br />
!         7.16.2 <a
href="#adv-relative-uris">Relative URIs</a><br />
!         7.16.3 <a
href="#adv-generating-uris">Generating Temporary URIs</a><br />
8. <a href="#References">References</a><br />
--- 343,384 ----
    7.6 <a href="#adv-MTOM">MTOM
Support</a><br />
!     7.7 <a href="#adv-RPCstyle">RPC
! Style</a><br />
!     7.8 <a
href="#adv-message-dispatch">Enabling Easy Message
Dispatch</a><br />
!     7.9 <a href="#adv-get-vs-post">GET Versus
POST: Which to Use?</a><br />
!     7.10 <a
href="#adv-service-references">Service References</a><br />
!         7.10.1 <a
href="#reservationDetails">The Reservation Details Web
Service</a><br />
!         7.10.2 <a
href="#reservationList">The Reservation List Web Service</a><br />
!     7.11 <a href="#adv-xml-schema-examples">XML
Schema Examples</a><br />
!     7.12 <a
href="#adv-multiple-inline-schemas">Multiple In-Line
Schemas</a><br />
!         7.12.1 <a
! href="#id5195262">Schemas in Imported Documents</a><br />
!         7.12.2 <a
! href="#id5213617">Multiple Inline Schemas on One Document</a><br />
!     7.13 <a href="#adv-schema-location">The
schemaLocation Attribute</a><br />
!         7.13.1 <a
! href="#id5212951">Using the id Attribute to Identify Inline
Schemas</a><br />
!     7.14 <a href="#adv-rdf-mapping">Mapping to
RDF and Semantic Web</a><br />
!     7.15 <a href="#adv-notes-on-uris">Notes on
URIs</a><br />
!         7.15.1 <a
href="#adv-namespaces-and-schema-locations">XML Namespaces and
Schema Locations</a><br />
!         7.15.2 <a
href="#adv-relative-uris">Relative URIs</a><br />
!         7.15.3 <a
href="#adv-generating-uris">Generating Temporary URIs</a><br />
8. <a href="#References">References</a><br />
***************
*** 2358,2362 ****
<div class="div3">
! <h4>5.4.1 Operation Attributes</h4>
<p>An <code>operation</code> has two required and two optional
--- 2356,2361 ----
<div class="div3">
! <h4><a id="more-interfaces-op-attr"
! name="more-interfaces-op-attr"></a>5.4.1 Operation Attributes</h4>
<p>An <code>operation</code> has two required and two optional
***************
*** 2378,2388 ****
<li>
! <p>An optional <code>style</code> attribute whose value is a a list
of absolute URIs. Each URI identifies a certain set of rules that
! were used to construct the message type definitions used by the
! <code>operation</code>. It is an error if a particular style is
! indicated, but the associated rules are not followed. See <a
! href="#adv-RPCstyle"><b>7.8 Operation Style and RPC</b></a> for an
! example of using the <code>style</code> attribute.</p>
<table border="1" summary="Editorial note">
--- 2377,2387 ----
<li>
! <p>An optional <code>style</code> attribute whose value is a list
of absolute URIs. Each URI identifies a certain set of rules that
! were followed in defining this <code>operation</code>. It is an
! error if a particular style is indicated, but the associated rules
! are not followed. See <a href="#adv-RPCstyle"><b>7.7 RPC
! Style</b></a> for an example of using the <code>style</code>
! attribute.</p>
<table border="1" summary="Editorial note">
***************
*** 3356,3361 ****
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>
</div>
--- 3355,3362 ----
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 the processor will require manual intervention
! to deal with the extension. For example, a client developer might
! manually provide an implementation for the required extension to
! the WSDL processor.</p>
</div>
***************
*** 4230,4241 ****
</div>
! <p>The HTTP Message Transmission Optimization feature is engaged
! using the <code>feature</code> element. Note that the attribute
! required=”true” on the feature declaration indicates that the
! message must be encoded using the HTTP Optimization feature. If the
! attribute were required=”false” (or this attribute were absent), it
! would indicate that the service accepts either MTOM-encoded
! messages, or the embedded base64Binary data directly in the Body,
! and the client is free to send either form of message.</p>
<p>The example above shows MTOM enabled for a specific message
--- 4231,4243 ----
</div>
! <p>The HTTP Message Transmission Optimization (MTOM) feature is
! engaged using the <code>feature</code> element. Note that the
! attribute required=”true” on the feature declaration indicates that
! the message must be encoded using the HTTP Optimization feature. If
! the attribute were required=”false” (or this attribute were
! absent), it would indicate that the use of MTOM is optional for
! this service: the service accepts either MTOM-encoded messages, or
! the embedded base64Binary data directly in the Body, and the client
! is free to send either form of message.</p>
<p>The example above shows MTOM enabled for a specific message
***************
*** 4246,4298 ****
require (or enable if required=”false”) MTOM support for all the
operations in that interface.</p>
-
- <p>This section shows how Features and Properties can be used to
- indicate the use of MTOM. @@ Example from GlenD:
- http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0076.html
- @@</p>
</div>
<div class="div2">
! <h3><a id="adv-security" name="adv-security"></a>7.7 Security
! Considerations</h3>
</div>
! <div class="div2">
! <h3><a id="adv-RPCstyle" name="adv-RPCstyle"></a>7.8 Operation
! Style and RPC</h3>
</div>
<div class="div2">
<h3><a id="adv-message-dispatch"
! name="adv-message-dispatch"></a>7.9 Enabling Easy Message
Dispatch</h3>
! <p>Suppose a WSDL document has two input-output operation and uses
! the same input message schema for both. When the service receives
! the input message, how will the service know which operation is
! supposed to be invoked? Although the data contained in a runtime
! message may be sufficient to distinguish between the operations,
! this can be a problem for WSDL toolkits that are looking only at
! the message schema, rather than the actual messages. (For example,
! the toolkit may be operating at designtime, without access to the
! runtime messages.) This is the problem of <em>dispatch</em>. How
! can a WSDL document be written to ensure easy message dispatch?</p>
! <p>One technique is to ensure that the top-level elements declared
! in the message schema are different for different operations. This
! is probably the most general solution, since it is guaranteed to
! provide a way to perform dispatch, without preventing toolkits from
! potentially using other dispatch techniques.</p>
! <p>Another technique is to define a required feature that enables a
! particular dispatching convention. This approach makes the
! dispatching convention explicit, although it may not be supported
! by every WSDL toolkit.</p>
</div>
<div class="div2">
! <h3><a id="adv-get-vs-post" name="adv-get-vs-post"></a>7.10 GET
Versus POST: Which to Use?</h3>
<p>[Add material from
http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html
--- 4248,4489 ----
require (or enable if required=”false”) MTOM support for all the
operations in that interface.</p>
</div>
<div class="div2">
! <h3><a id="adv-RPCstyle" name="adv-RPCstyle"></a>7.7 RPC Style</h3>
!
! <p>Section <a href="#more-interfaces-op-attr"><b>5.4.1 Operation
! Attributes</b></a> mentioned that the (optional) <code>style</code>
! attribute of an interface operation is used to indicate that the
! operation conforms to a particular pre-defined operation style, or
! set of constraints. Actually, if desired the <code>style</code>
! attribute can hold a list of URIs, indicating that the operation
! simultaneously conforms to multiple styles.</p>
!
! <p>Operation styles are named using URIs, in order to be unambigous
! while still permitted new styles to be defined without requiring
! updates to the WSDL 2.0 language. WSDL 2.0 Part 2 [<cite><a
! href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines three such
! operation styles; one of these is the RPC Style (<a
! href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
! Style</a>).</p>
!
! <p>The <em>RPC Style</em> is designed to facilitate programming
! language bindings to WSDL 2.0 constructs. It allows a WSDL 2.0
! interface operation to be easily mapped to a method or function
! signature, such as a method signature in Java(TM) or C#. RPC Style
! is restricted to operations that use the In-Out or In-Only MEPs
! (see <a href="#more-interfaces-meps"><b>5.4.3 Understanding Message
! Exchange Patterns (MEPs)</b></a>).</p>
!
! <p>A WSDL 2.0 document makes use of the RPC Style in an interface
! operation by first defining the operation in conformance with all
! of the RPC Style rules, and then setting that operation's
! <code>style</code> attribute to include the URI that identifies the
! RPC Style, thus asserting that the operation does indeed conform to
! the RPC Style. These rules permit the input and output message
! schemas to map conveniently to inputs and outputs of a method
! signature. Roughly, input elements map to input parameters, output
! elements map to output parameters, and elements that appear both in
! the input and output message schemas map to input/output
! parameters. WSDL 2.0 Part 2 section "<a
! href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
! Style</a>" provides full details of the mapping rules and
! requirements.</p>
!
! <p>The RPC Style also permits the full signature of the intended
! mapping to be indicated explicitly, using the
! <code>wrpc:signature</code> attribute defined in WSDL 2.0 Part 2
! section "<a
! href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts">wrpc:signature
! Extension</a>". This is an (optional) extension to the WSDL 2.0
! language whose value designates how input and output message schema
! elements map to input and output parameters in the method
! signature.</p>
!
! <p>The example below illustrates how RPC Style may be used to
! designate a signature. This example is a modified version of the
! GreatH reservation service. In particular, the
! <code>interface</code> and <code>types</code> sections have been
! modified to specify and conform to the RPC Style.</p>
!
! <div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a
! id="example-rpc-style"
! name="example-rpc-style"></a><i><span>Example 7-11.</span>
! Specifying RPC Style</i></p>
!
! <div class="exampleInner">
! <pre>
! . . .
! <types>
!
! <xs:element name="checkAvailability">
! <xs:complexType>
! <xs:sequence>
! <xs:element name="checkInDate" type="xs:date"/>
! <xs:element name="checkOutDate" type="xs:date"/>
! <xs:element name="roomType" type="xs:string"/>
! </xs:sequence>
! </xs:complexType>
! </xs:element>
!
! <xs:element name="checkAvailabilityResponse">
! <xs:complexType>
! <xs:sequence>
! <xs:element name="roomType" type="xs:string"/>
! <xs:element name="rateType" type="xs:string"/>
! <xs:element name="rate" type="xs:double"/>
! </xs:sequence>
! </xs:complexType>
! </xs:element>
! . . .
! </types>
!
! <interface name = "reservationInterface" >
!
! <operation name="checkAvailability"
! pattern="http://www.w3.org/@@@@/@@/wsdl/in-out"
! style="http://www.w3.org/@@@@/@@/wsdl/style/rpc"
! wrpc:signature=
! "checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return">
! <input messageLabel="In"
! element="tns:checkAvailability" />
! <output messageLabel="Out"
! element="tns:checkAvailabilityResponse" />
!
! </operation>
! . . .
! </interface>
! . . .
! </pre>
! </div>
</div>
! <p>Note that the interface operation's name
! "<code>checkAvailability</code>", is the same as the localPart of
! the input element's QName, "<code>tns:checkAvailability</code>".
! This is one of the requirements of the RPC Style. The name of the
! operation is used as the name of the method in a language binding,
! subject to further mapping restrictions specific to the target
! programming language. In this case, the name of the method would be
! "checkAvailability".</p>
!
! <p>The local children elements of the input element and output
! element designate the parameters and the return type for a method
! call. Note that the elements <code>checkInDate</code>,
! <code>checkOutDate</code> are input parameters, however the element
! <code>roomType</code> is an in-out parameter, as it appears both as
! a local element child of both input and output elements. This
! indicates that the reservation system may change the room type
! requested based on availability.</p>
!
! <p>The reservation service also returns a rate type for the
! reservation, such as "rack rate". The return value for the method
! is designated as the "rate" element.</p>
!
! <table border="1" summary="Editorial note: dbooth">
! <tr>
! <td align="left" valign="top" width="50%"><b>Editorial note:
! dbooth</b></td>
! <td align="right" valign="top" width="50%">2005-04-15</td>
! </tr>
!
! <tr>
! <td colspan="2" align="left" valign="top">ToDo: Add a bib entry for
! JAX RPC 1.1 - Java(TM) API for XML-based RPC JAX-RPC 1.1
! (http://java.sun.com/xml/downloads/jaxrpc.html) - and fill in the
! @@bibref@@ below.</td>
! </tr>
! </table>
!
! <p>Based on the value of the <code>wrpc:signature</code> attribute,
! the method signature would be obtained following the order of the
! parameters. A sample mapping is provided below for the Java(TM)
! language. This example was created using JAX RPC 1.1 @@bibref@@ for
! mapping simple types to Java types and designated inout and output
! parameters by using Holder classes.</p>
!
! <div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a
! id="example-rpc-style-java-sig"
! name="example-rpc-style-java-sig"></a><i><span>Example 7-12.</span>
! Sample Java(TM) Signature for RPC Style</i></p>
!
! <div class="exampleInner">
! <pre>
! public interface reservationInterface extends Remote{
!
! double checkAvailability(java.util.calendar checkInDate,
! java.util.calendar checkOutDate,
! StringHolder roomType,
! StringHolder rateType) throws RemoteException;
! . . .
! }
! </pre>
! </div>
! </div>
!
! <p>Programming languages may further specify how faults are mapped
! to langauage constructs and their scopes, such as Exceptions, but
! they are not specific to RPC style.</p>
</div>
<div class="div2">
<h3><a id="adv-message-dispatch"
! name="adv-message-dispatch"></a>7.8 Enabling Easy Message
Dispatch</h3>
! <p>Suppose a WSDL 2.0 document has two input-output operations and
! uses the same input message schema for both. When the service
! receives the input message, how will the service know which
! operation is supposed to be invoked? Although the data contained in
! a runtime message may be sufficient to distinguish between the
! operations, this can be a problem for WSDL 2.0 toolkits that are
! looking only at the message schema, rather than the actual
! messages. (For example, the toolkit may be operating at designtime,
! without access to the runtime messages.) This is the problem of
! <em>dispatch</em>. How can a WSDL 2.0 document be written to ensure
! easy message dispatch? Strategies include:</p>
! <ul>
! <li>
! <p><b>Use unique top-level elements</b>, i.e., ensure that the
! top-level elements declared in the message schemas are different
! for different operations. This is probably the most general
! solution, since it is guaranteed to provide a way to perform
! dispatch, without preventing toolkits from potentially using other
! dispatch techniques.</p>
! </li>
! <li>
! <p><b>Include a required extension</b> that enables a particular
! dispatching convention. This approach makes the dispatching
! convention explicit, although it may not be supported by every WSDL
! toolkit. However, as explained in <a
! href="#adv-optional-versus-required"><b>7.1.1 Optional Versus
! Required Extensions</b></a>, toolkits that do not natively support
! the extension could seek manual input, thus permitting a client
! developer to supply an appropriate module that implements the
! necessary extension. This strategy has thus permits future WSDL
! toolkits to support and process the extension automatically, while
! also ensuring that the extension will be handled properly by
! toolkits that are not yet able to process it automatically.</p>
! </li>
! </ul>
!
! <p>To ensure that client and service implementations can easily
! determine the interface operation under which a received message
! was sent (even though not every client or service may need to make
! such a determination), it is considered good practice to follow one
! of the above strategies when authoring WSDL 2.0 documents.</p>
</div>
<div class="div2">
! <h3><a id="adv-get-vs-post" name="adv-get-vs-post"></a>7.9 GET
Versus POST: Which to Use?</h3>
+ <p>@@@@@@@@@@@@@@@@@@@@@@@@@@@@</p>
+
<p>[Add material from
http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html
***************
*** 4303,4307 ****
<div class="div2">
<h3><a id="adv-service-references"
! name="adv-service-references"></a>7.11 Service References</h3>
<table border="1" summary="Editorial note: Arthur">
--- 4494,4498 ----
<div class="div2">
<h3><a id="adv-service-references"
! name="adv-service-references"></a>7.10 Service References</h3>
<table border="1" summary="Editorial note: Arthur">
***************
*** 4335,4339 ****
<div class="div3">
! <h4><a id="reservationDetails" name="reservationDetails"></a>7.11.1
The Reservation Details Web Service</h4>
--- 4526,4530 ----
<div class="div3">
! <h4><a id="reservationDetails" name="reservationDetails"></a>7.10.1
The Reservation Details Web Service</h4>
***************
*** 4347,4351 ****
will be the endpoint address for a Reservation Detail Web service
that can retrieve and update the state of a reservation. <a
! href="#reservationDetails-OMX736.xml">Example 7-11</a> shows the
format of the reservation detail.</p>
--- 4538,4542 ----
will be the endpoint address for a Reservation Detail Web service
that can retrieve and update the state of a reservation. <a
! href="#reservationDetails-OMX736.xml">Example 7-13</a> shows the
format of the reservation detail.</p>
***************
*** 4354,4358 ****
id="reservationDetails-OMX736.xml"
name="reservationDetails-OMX736.xml"></a><i><span>Example
! 7-11.</span> Detail for Reservation OMX736</i></p>
<div class="exampleInner">
--- 4545,4549 ----
id="reservationDetails-OMX736.xml"
name="reservationDetails-OMX736.xml"></a><i><span>Example
! 7-13.</span> Detail for Reservation OMX736</i></p>
<div class="exampleInner">
***************
*** 4375,4379 ****
<p>The Reservation Details Web service provides operations for
retrieving and updating the detail for a reservation. <a
! href="#reservationDetails.wsdl">Example 7-12</a> shows the
description for this Web service. Note that there is no
<code>wsdl:service</code> element in this description since the set
--- 4566,4570 ----
<p>The Reservation Details Web service provides operations for
retrieving and updating the detail for a reservation. <a
! href="#reservationDetails.wsdl">Example 7-14</a> shows the
description for this Web service. Note that there is no
<code>wsdl:service</code> element in this description since the set
***************
*** 4385,4389 ****
<p style="text-align: left" class="exampleHead"><a
id="reservationDetails.wsdl"
! name="reservationDetails.wsdl"></a><i><span>Example 7-12.</span>
The Reservation Details Web Service Description:
reservationDetails.wsdl</i></p>
--- 4576,4580 ----
<p style="text-align: left" class="exampleHead"><a
id="reservationDetails.wsdl"
! name="reservationDetails.wsdl"></a><i><span>Example 7-14.</span>
The Reservation Details Web Service Description:
reservationDetails.wsdl</i></p>
***************
*** 4453,4457 ****
</div>
! <p><a href="#reservationDetails.xsd">Example 7-13</a> shows the XML
schema elements that are used in this Web service.</p>
--- 4644,4648 ----
</div>
! <p><a href="#reservationDetails.xsd">Example 7-15</a> shows the XML
schema elements that are used in this Web service.</p>
***************
*** 4459,4463 ****
<p style="text-align: left" class="exampleHead"><a
id="reservationDetails.xsd"
! name="reservationDetails.xsd"></a><i><span>Example 7-13.</span> The
Reservation Details Web Service XML Schema:
reservationDetails.xsd</i></p>
--- 4650,4654 ----
<p style="text-align: left" class="exampleHead"><a
id="reservationDetails.xsd"
! name="reservationDetails.xsd"></a><i><span>Example 7-15.</span> The
Reservation Details Web Service XML Schema:
reservationDetails.xsd</i></p>
***************
*** 4556,4560 ****
<div class="div3">
! <h4><a id="reservationList" name="reservationList"></a>7.11.2 The
Reservation List Web Service</h4>
--- 4747,4751 ----
<div class="div3">
! <h4><a id="reservationList" name="reservationList"></a>7.10.2 The
Reservation List Web Service</h4>
***************
*** 4586,4590 ****
</table>
! <p><a href="#reservationList-all.xml">Example 7-14</a> shows the
format of the response from the Reservation List service.</p>
--- 4777,4781 ----
</table>
! <p><a href="#reservationList-all.xml">Example 7-16</a> shows the
format of the response from the Reservation List service.</p>
***************
*** 4592,4596 ****
<p style="text-align: left" class="exampleHead"><a
id="reservationList-all.xml"
! name="reservationList-all.xml"></a><i><span>Example 7-14.</span>
Response from the Reservation List Web Service</i></p>
--- 4783,4787 ----
<p style="text-align: left" class="exampleHead"><a
id="reservationList-all.xml"
! name="reservationList-all.xml"></a><i><span>Example 7-16.</span>
Response from the Reservation List Web Service</i></p>
***************
*** 4660,4664 ****
reservation.</p>
! <p><a href="#reservationList.wsdl">Example 7-15</a> shows the
description of the Reservation List Web service. Note that is
contains operations to retrieve the entire list and to query for a
--- 4851,4855 ----
reservation.</p>
! <p><a href="#reservationList.wsdl">Example 7-17</a> shows the
description of the Reservation List Web service. Note that is
contains operations to retrieve the entire list and to query for a
***************
*** 4670,4674 ****
<p style="text-align: left" class="exampleHead"><a
id="reservationList.wsdl"
! name="reservationList.wsdl"></a><i><span>Example 7-15.</span> The
Reservation List Web Service Description:
reservationList.wsdl</i></p>
--- 4861,4865 ----
<p style="text-align: left" class="exampleHead"><a
id="reservationList.wsdl"
! name="reservationList.wsdl"></a><i><span>Example 7-17.</span> The
Reservation List Web Service Description:
reservationList.wsdl</i></p>
***************
*** 4763,4767 ****
</div>
! <p><a href="#reservationList.xsd">Example 7-16</a>Shows the schema
for the messages used in the Reservation List Web service.</p>
--- 4954,4958 ----
</div>
! <p><a href="#reservationList.xsd">Example 7-18</a>Shows the schema
for the messages used in the Reservation List Web service.</p>
***************
*** 4769,4773 ****
<p style="text-align: left" class="exampleHead"><a
id="reservationList.xsd"
! name="reservationList.xsd"></a><i><span>Example 7-16.</span> The
Reservation List Schema: reservationList.xsd</i></p>
--- 4960,4964 ----
<p style="text-align: left" class="exampleHead"><a
id="reservationList.xsd"
! name="reservationList.xsd"></a><i><span>Example 7-18.</span> The
Reservation List Schema: reservationList.xsd</i></p>
***************
*** 4833,4837 ****
<div class="div2">
<h3><a id="adv-xml-schema-examples"
! name="adv-xml-schema-examples"></a>7.12 XML Schema Examples</h3>
<p>[Add Paul Downey's contribution at
--- 5024,5028 ----
<div class="div2">
<h3><a id="adv-xml-schema-examples"
! name="adv-xml-schema-examples"></a>7.11 XML Schema Examples</h3>
<p>[Add Paul Downey's contribution at
***************
*** 4842,4846 ****
<div class="div2">
<h3><a id="adv-multiple-inline-schemas"
! name="adv-multiple-inline-schemas"></a>7.13 Multiple In-Line
Schemas</h3>
--- 5033,5037 ----
<div class="div2">
<h3><a id="adv-multiple-inline-schemas"
! name="adv-multiple-inline-schemas"></a>7.12 Multiple In-Line
Schemas</h3>
***************
*** 4878,4882 ****
<div class="div3">
! <h4>7.13.1 Schemas in Imported Documents</h4>
<p>In this example, we consider some GreatH Hotel Web services that
--- 5069,5073 ----
<div class="div3">
! <h4>7.12.1 Schemas in Imported Documents</h4>
<p>In this example, we consider some GreatH Hotel Web services that
***************
*** 4888,4892 ****
and schema definitions contained in the imported document.</p>
! <p><a href="#retrieveDetails.wsdl">Example 7-17</a> shows the
definition of the retrieval Web service in the
<code>http://greath.example.com/2004/services/retrieveDetails</code>
--- 5079,5083 ----
and schema definitions contained in the imported document.</p>
! <p><a href="#retrieveDetails.wsdl">Example 7-19</a> shows the
definition of the retrieval Web service in the
<code>http://greath.example.com/2004/services/retrieveDetails</code>
***************
*** 4902,4906 ****
<p style="text-align: left" class="exampleHead"><a
id="retrieveDetails.wsdl"
! name="retrieveDetails.wsdl"></a><i><span>Example 7-17.</span> The
Retrieve Reservation Details Web Service:
retrieveDetails.wsdl</i></p>
--- 5093,5097 ----
<p style="text-align: left" class="exampleHead"><a
id="retrieveDetails.wsdl"
! name="retrieveDetails.wsdl"></a><i><span>Example 7-19.</span> The
Retrieve Reservation Details Web Service:
retrieveDetails.wsdl</i></p>
***************
*** 4956,4960 ****
</div>
! <p><a href="#updateDetails.wsdl">Example 7-18</a> shows the
definition of the updating Web service in the
<code>http://greath.example.com/2004/services/updateDetails</code>
--- 5147,5151 ----
</div>
! <p><a href="#updateDetails.wsdl">Example 7-20</a> shows the
definition of the updating Web service in the
<code>http://greath.example.com/2004/services/updateDetails</code>
***************
*** 5001,5005 ****
<p style="text-align: left" class="exampleHead"><a
id="updateDetails.wsdl"
! name="updateDetails.wsdl"></a><i><span>Example 7-18.</span> The
Update Reservation Details Web Service: updateDetails.wsdl</i></p>
--- 5192,5196 ----
<p style="text-align: left" class="exampleHead"><a
id="updateDetails.wsdl"
! name="updateDetails.wsdl"></a><i><span>Example 7-20.</span> The
Update Reservation Details Web Service: updateDetails.wsdl</i></p>
***************
*** 5048,5052 ****
<div class="div3">
! <h4>7.13.2 Multiple Inline Schemas on One Document</h4>
<p>A WSDL document may define multiple inline schemas in its
--- 5239,5243 ----
<div class="div3">
! <h4>7.12.2 Multiple Inline Schemas on One Document</h4>
<p>A WSDL document may define multiple inline schemas in its
***************
*** 5065,5069 ****
<p>To illustrate this, consider <a
! href="#retrieveItems.wsdl">Example 7-19</a> which contains two
inline schemas. The
<code>http://greath.example.com/2004/schemas/reservationItems</code>
--- 5256,5260 ----
<p>To illustrate this, consider <a
! href="#retrieveItems.wsdl">Example 7-21</a> which contains two
inline schemas. The
<code>http://greath.example.com/2004/schemas/reservationItems</code>
***************
*** 5083,5087 ****
<p style="text-align: left" class="exampleHead"><a
id="retrieveItems.wsdl"
! name="retrieveItems.wsdl"></a><i><span>Example 7-19.</span>
Multiple Inline Schemas: retrieveItems.wsdl</i></p>
--- 5274,5278 ----
<p style="text-align: left" class="exampleHead"><a
id="retrieveItems.wsdl"
! name="retrieveItems.wsdl"></a><i><span>Example 7-21.</span>
Multiple Inline Schemas: retrieveItems.wsdl</i></p>
***************
*** 5152,5156 ****
<div class="div2">
! <h3><a id="adv-schema-location" name="adv-schema-location"></a>7.14
The schemaLocation Attribute</h3>
--- 5343,5347 ----
<div class="div2">
! <h3><a id="adv-schema-location" name="adv-schema-location"></a>7.13
The schemaLocation Attribute</h3>
***************
*** 5181,5188 ****
locating these schemas.</p>
! <p><a href="#updateDetails.wsdl">Example 7-18</a> shows how one
WSDL document imports a schema defined in another, i.e. <a
! href="#retrieveDetails.wsdl">Example 7-17</a>. Similarly, <a
! href="#retrieveItems.wsdl">Example 7-19</a> shows how one schema in
a WSDL document imports another schema defined in the same
document. In both of these examples, the
--- 5372,5379 ----
locating these schemas.</p>
! <p><a href="#updateDetails.wsdl">Example 7-20</a> shows how one
WSDL document imports a schema defined in another, i.e. <a
! href="#retrieveDetails.wsdl">Example 7-19</a>. Similarly, <a
! href="#retrieveItems.wsdl">Example 7-21</a> shows how one schema in
a WSDL document imports another schema defined in the same
document. In both of these examples, the
***************
*** 5199,5205 ****
<div class="div3">
! <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
--- 5390,5396 ----
<div class="div3">
! <h4>7.13.1 Using the id Attribute to Identify Inline Schemas</h4>
! <p><a href="#schemaIds.wsdl">Example 7-22</a> shows the use of the
<code>id</code> attribute. Both of the inline schemas have
<code>id</code> attributes. The id of the
***************
*** 5218,5222 ****
<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">
--- 5409,5413 ----
<p style="text-align: left" class="exampleHead"><a
id="schemaIds.wsdl" name="schemaIds.wsdl"></a><i><span>Example
! 7-22.</span> Using Ids in Inline Schemas: schemaIds.wsdl</i></p>
<div class="exampleInner">
***************
*** 5289,5298 ****
<div class="div2">
! <h3><a id="adv-rdf-mapping" name="adv-rdf-mapping"></a>7.15 Mapping
to RDF and Semantic Web</h3>
</div>
<div class="div2">
! <h3><a id="adv-notes-on-uris" name="adv-notes-on-uris"></a>7.16
Notes on URIs</h3>
--- 5480,5489 ----
<div class="div2">
! <h3><a id="adv-rdf-mapping" name="adv-rdf-mapping"></a>7.14 Mapping
to RDF and Semantic Web</h3>
</div>
<div class="div2">
! <h3><a id="adv-notes-on-uris" name="adv-notes-on-uris"></a>7.15
Notes on URIs</h3>
***************
*** 5303,5307 ****
<div class="div3">
<h4><a id="adv-namespaces-and-schema-locations"
! name="adv-namespaces-and-schema-locations"></a>7.16.1 XML
Namespaces and Schema Locations</h4>
--- 5494,5498 ----
<div class="div3">
<h4><a id="adv-namespaces-and-schema-locations"
! name="adv-namespaces-and-schema-locations"></a>7.15.1 XML
Namespaces and Schema Locations</h4>
***************
*** 5321,5325 ****
<div class="div3">
! <h4><a id="adv-relative-uris" name="adv-relative-uris"></a>7.16.2
Relative URIs</h4>
--- 5512,5516 ----
<div class="div3">
! <h4><a id="adv-relative-uris" name="adv-relative-uris"></a>7.15.2
Relative URIs</h4>
***************
*** 5334,5338 ****
<div class="div3">
<h4><a id="adv-generating-uris"
! name="adv-generating-uris"></a>7.16.3 Generating Temporary
URIs</h4>
--- 5525,5529 ----
<div class="div3">
<h4><a id="adv-generating-uris"
! name="adv-generating-uris"></a>7.15.3 Generating Temporary
URIs</h4>
Received on Sunday, 17 April 2005 23:17:20 UTC