- From: Jonathan Marsh via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 20 Oct 2006 21:47:13 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv28091/wsdl20
Modified Files:
wsdl20-primer.xml wsdl20-primer.html
Log Message:
Recorded many issue responses 10/16.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.146
retrieving revision 1.147
diff -C 2 -d -r1.146 -r1.147
*** wsdl20-primer.xml 22 Mar 2006 18:26:58 -0000 1.146
--- wsdl20-primer.xml 20 Oct 2006 21:47:10 -0000 1.147
***************
*** 106,110 ****
<div2 id="UseIRI">
! <head>Use of URI and IRI</head>
<p>The core specification of WSDL 2.0 supports Internationalized Resource Identifiers or IRIs <bibref ref="RFC3987"/>. IRIs are a superset of URIs with added support for internationalization. The URI syntax <bibref ref="RFC3986"/> only allows the use of a small set of characters, including upper and lower case letters of the English alphabet, European numerals and a few symbols. IRIs allow the use of characters from a wider range of language scripts. </p>
--- 106,110 ----
<div2 id="UseIRI">
! <head>Use of URIs and IRIs</head>
<p>The core specification of WSDL 2.0 supports Internationalized Resource Identifiers or IRIs <bibref ref="RFC3987"/>. IRIs are a superset of URIs with added support for internationalization. The URI syntax <bibref ref="RFC3986"/> only allows the use of a small set of characters, including upper and lower case letters of the English alphabet, European numerals and a few symbols. IRIs allow the use of characters from a wider range of language scripts. </p>
***************
*** 138,143 ****
</div1>
! <!-- ****************WSL2.0 BASICS********************************* -->
! <!-- ****************WSL2.0 BASICS********************************* -->
<div1 id="basics">
<head>WSDL 2.0 Basics</head>
--- 138,142 ----
</div1>
! <!-- ****************WSDL2.0 BASICS********************************* -->
<div1 id="basics">
<head>WSDL 2.0 Basics</head>
***************
*** 146,150 ****
<p>This section introduces the basic concepts used in WSDL 2.0 through the description of a hypothetical hotel reservation service. We start with a simple scenario, and later add more requirements to illustrate how more advanced WSDL 2.0 features may be used. </p>
! <!-- ************************ GreatH *************************** --><div3 id="basics-greath-scenario"><head>Example Scenario: The GreatH Hotel Reservation Service</head><p>Hotel GreatH (a fictional hotel) is located in a remote island. It has been relying on fax and phone to provide room reservations. Even though the facilities and prices at GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH. After research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet. GreatH then hires us to build a reservation Web service with the following functionality: <ulist><item><p><emph>CheckAvailability</emph>. To check availability, the client must specify a check-in date, a check-out date, and room type. The Web service will return a room rate (a floating point number in USD$) if such a room is available, or a zero room rate if nt. If any input data is invalid, the service should return an error. Thus, the service will accept a <code>checkAvailability</code> message and return a <code>checkAvailabilityResponse</code> or <code>invalidDataFault</code> message.</p> </item><item><p><emph>MakeReservation</emph>. To make a reservation, a client must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is successful. The service will return an error message if the credit card number or any other data field is invalid. Thus, the service will accept a <code>makeReservation</code> message and return a <code>makeReservationResponse</code> or <code>invalidCreditCardFault</code> message.</p></item></ulist> We know that we will later need to build a complete system that supports transactions and secured transmission, but initially we will implement only minimal functionality. In fact, to simplify our first example, we will implement only the <emph>CheckAvailability</emph operation. </p><p>The next several sections proceed step-by-step through the process of developing a WSDL 2.0 document that describes the desired Web service. However, for those who can't wait to see a complete example, here is the WSDL 2.0 document that we'll be creating.</p><example id="example-initial">
<head>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</head>
<eg><![CDATA[
--- 145,150 ----
<p>This section introduces the basic concepts used in WSDL 2.0 through the description of a hypothetical hotel reservation service. We start with a simple scenario, and later add more requirements to illustrate how more advanced WSDL 2.0 features may be used. </p>
! <!-- ************************ GreatH *************************** -->
! <div3 id="basics-greath-scenario"><head>Example Scenario: The GreatH Hotel Reservation Service</head><p>Hotel GreatH (a fictional hotel) is located in a remote island. It has been relying on fax and phone to provide room reservations. Even though the facilities and prices at GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH. After research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet. GreatH then hires us to build a reservation Web service with the following functionality: <ulist><item><p><emph>CheckAvailability</emph>. To check availability, the client must specify a check-in date, a check-out date, and room type. The Web service will return a room rate (a floating point number in USD) if such a room is available, or a zero room rate if not. If any input data is invalid, the service should return an error. Thus, the service will accept a <code>checkAvailability</code> message and return a <code>checkAvailabilityResponse</code> or <code>invalidDataFault</code> message.</p> </item><item><p><emph>MakeReservation</emph>. To make a reservation, a client must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is successful. The service will return an error message if the credit card number or any other data field is invalid. Thus, the service will accept a <code>makeReservation</code> message and return a <code>makeReservationResponse</code> or <code>invalidCreditCardFault</code> message.</p></item></ulist> We know that we will later need to build a complete system that supports transactions and secured transmission, but initially we will implement only minimal functionality. In fact, to simplify our first example, we will implement only the <emph>CheckAvailability</emph> operation. </p><p>The next several sections proceed step-by-step trough the process of developing a WSDL 2.0 document that describes the desired Web service. However, for those who can't wait to see a complete example, here is the WSDL 2.0 document that we'll be creating.</p><example id="example-initial">
<head>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</head>
<eg><![CDATA[
***************
*** 510,514 ****
<div2 id="wsdl-xml-representation"><head>WSDL 2.0 Infoset, Schema and Component Model</head>
! <p>In computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a finite string of literal symbols or characters. A language specification must therefore define the set sentences in that language, and, to be useful, it should also indicate the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <emph>XML Infoset</emph> <bibref ref="XMLInfoSet"/>. Specifically, a <emph>WSDL 2.0 document</emph> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification.</p><p>Since an XML Infoset cn be created from more than one physical document, a WSDL 2.0 document does not necessarily correspond to a single <emph>physical</emph> document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. In such cases, the meaning of the including or importing document as a whole will depend (in part) on the meaning of the included or imported document.</p><p>The XML Infoset uses terms like "element information item" and "attribute information item". Unfortunately, those terms are rather lengthy to repeat often. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respectively.</p>
<div3 id="wsdl-infoset-diagram"><head>WSDL 2.0 Infoset</head>
--- 510,514 ----
<div2 id="wsdl-xml-representation"><head>WSDL 2.0 Infoset, Schema and Component Model</head>
! <p>In computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a finite string of literal symbols or characters. A language specification must therefore define the set of sentences in that language, and, to be useful, it should also indicate the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <emph>XML Infoset</emph> <bibref ref="XMLInfoSet"/>. Specifically, a <emph>WSDL 2.0 document</emph> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification.</p><p>Since an XML Infose can be created from more than one physical document, a WSDL 2.0 document does not necessarily correspond to a single <emph>physical</emph> document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. In such cases, the meaning of the including or importing document as a whole will depend (in part) on the meaning of the included or imported document.</p><p>The XML Infoset uses terms like "element information item" and "attribute information item". Unfortunately, those terms are rather lengthy to repeat often. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respectively.</p>
<div3 id="wsdl-infoset-diagram"><head>WSDL 2.0 Infoset</head>
***************
*** 529,533 ****
<p>This section gives an example of how WSDL 2.0 specification constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0 elements.</p>
! <p>Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> section "<xspecref href="&w3c-designation-part1;#Description_XMLRep">XML Representation of Description Component</xspecref>") clearly states a set of constraints about how the children elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, in spite of what the WSDL 2.0 schema says. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<eg xml:space="preserve">
--- 529,533 ----
<p>This section gives an example of how WSDL 2.0 specification constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0 elements.</p>
! <p>Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> section "<xspecref href="&w3c-designation-part1;#Description_XMLRep">XML Representation of Description Component</xspecref>") clearly states a set of constraints about how the child elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, even though the WSDL 2.0 schema does not capture this constraint. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<eg xml:space="preserve">
***************
*** 623,629 ****
<p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Service</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p>
! <p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!).
!
! </p>
<div4 id="import-component"><head>WSDL 2.0 Import and Include</head>
<p>
--- 623,627 ----
<p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Service</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p>
! <p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!)</p>
<div4 id="import-component"><head>WSDL 2.0 Import and Include</head>
<p>
***************
*** 803,807 ****
! <p>So far we have briefly covered both WSDL import/include and schema import/include. The following table summarizes the similarities and differences
between the WSDL 2.0 and XML Schema
<el>include</el> and <el>import</el> mechanisms. We will talk a lot more about importing mechanisms in <specref ref="adv-import-and-authoring"/> and <specref ref="adv-multiple-inline-schemas"/></p>
--- 801,805 ----
! <p>So far we have briefly covered both WSDL import and include and schema import and include. The following table summarizes the similarities and differences
between the WSDL 2.0 and XML Schema
<el>include</el> and <el>import</el> mechanisms. We will talk a lot more about importing mechanisms in <specref ref="adv-import-and-authoring"/> and <specref ref="adv-multiple-inline-schemas"/></p>
***************
*** 2073,2077 ****
<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 in a WSDL 2.0 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 th issue (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 2.0 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>requred</emph> extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by attribute <code>wsdl:required="true"</code>. If a WSDL 2.0 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 2.0 processor. </p></div3>
<!-- removed per minutes 5-12-2005 AI 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 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 -->
--- 2071,2075 ----
<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 in a WSDL 2.0 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 th issue (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 <code>wsdl:required="false"</code> or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). Thus, a WSDL 2.0 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</emph extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by <code>wsdl:required="true"</code>. If a WSDL 2.0 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 2.0 processor. </p></div3>
<!-- removed per minutes 5-12-2005 AI 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 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 -->
***************
*** 2165,2169 ****
<simpleType name="securityLevelConstraint">
<restriction base="xs:int">
! <min 3, max 7> <!-- check schema for syntax -->
</restriction>
</simpleType>
--- 2163,2168 ----
<simpleType name="securityLevelConstraint">
<restriction base="xs:int">
! <minInclusive value="3"/>
! <maxInclusive value="7"/>
</restriction>
</simpleType>
***************
*** 2571,2579 ****
<head>Enabling Easy Message Dispatch</head>
! <p>It is desirable for a message recipient to have the capability to uniquely identify a message in order to handle it correctly. The capability of identifying a message is typically used for dispatching purposes within an implementation of a web service. Therefore, WSDL authors are recommended to take disambiguating of messages that are defined in a description into consideration when they develop descriptions of their services. </p>
! <p>The context in which a Web service may be deployed plays an important role in choosing an appropriate way to disambiguate and identify messages. In a typical deployment, an endpoint address may host a single service that is described by a WSDL service element. In this case, when XSD is used, assigning unique qualified names of global element declarations as inputs within the interface that describes the service would be sufficient to disambiguate the messages that are received. However, when endpoint address hosts multiple services, in essence supports several WSDL descriptions, the desire to disambiguate messages should considered within the context of all the deployed services, not only within a single interface. </p>
! <p>As explained in <specref ref= "more-interfaces-op-attr"/>, when XSD is used as the type system, a few special tokens can be used for the <code>element</code> attributes. Uniquely identifying a message may become very difficult when:
<ulist>
--- 2570,2591 ----
<head>Enabling Easy Message Dispatch</head>
! <p>It is desirable for a message recipient to have the capability to uniquely identify a message
! type in order to handle it correctly. The capability of identifying a message type is typically
! used for dispatching purposes within an implementation of a web service. Therefore, WSDL authors
! are recommended to consider how to disambiguate message types when they develop their services.</p>
! <p>The context in which a Web service may be deployed plays an important role in choosing an
! appropriate way to disambiguate and identify message types. In a typical deployment, an endpoint
! address may host a single service that is described by a WSDL service element. In this case,
! when XSD is used, assigning unique qualified names of global element declarations as inputs
! within the interface that describes the service would be sufficient to disambiguate the types
! of the messages that are received. However, when endpoint address hosts multiple services,
! in essence supporting several WSDL descriptions, the desire to disambiguate message types
! should be considered within the context of all the deployed services, not only within a single
! interface.</p>
! <p>As explained in <specref ref= "more-interfaces-op-attr"/>, when XSD is used as the type
! system, a few special tokens can be used for the <code>element</code> attributes. Uniquely
! identifying a message type may become very difficult when:
<ulist>
***************
*** 2581,2585 ****
<p>
any of these input elements within an interface has a value
! of “#any”; or
</p>
</item>
--- 2593,2597 ----
<p>
any of these input elements within an interface has a value
! of "#any"; or
</p>
</item>
***************
*** 2587,2591 ****
<p>
more than one of these input elements (see below) has a
! value of “#none”; or
</p>
</item>
--- 2599,2603 ----
<p>
more than one of these input elements (see below) has a
! value of "#none"; or
</p>
</item>
***************
*** 2637,2641 ****
</ulist>
! <p>In addition, WS-Addressing [WS-Addressing] specification already provides a disambiguation mechanism. It defines a required [action] property whose value is always present in a message delivery. The value of the action property can be used to disambiguate the message by the receiver and there is a well defined way to associate actions to messages in WS-Addressing specifications. Further, WS-Addressing also provides an appropriate default action value that identifies each message uniquely. </p>
<!-- old text for this section, replaced by contribution from Umit
--- 2649,2659 ----
</ulist>
! <p>In addition, WS-Addressing [WS-Addressing] specification already provides a
! disambiguation mechanism. It defines a required [action] property whose value is
! always present in a message delivery. The value of the action property can be used
! to disambiguate the message by the receiver and there is a well defined way to
! associate actions to messages in WS-Addressing specifications. Further, WS-Addressing
! also provides an appropriate default action value that identifies each message type
! uniquely. </p>
<!-- old text for this section, replaced by contribution from Umit
***************
*** 2655,2659 ****
other messages beyond those described in a particular WSDL 2.0 document. Often
this circumstance occurs following an evolution of the client and/or service, and thus an evolution of the interaction language.</p><p>How best to manage the evolution (versioning) of Web based systems is,
! at the time of writing, the subject of a wide ranging debate. However,
there are three activities within the W3C that are directly relevant
to versioning of Web services description:</p>
--- 2673,2677 ----
other messages beyond those described in a particular WSDL 2.0 document. Often
this circumstance occurs following an evolution of the client and/or service, and thus an evolution of the interaction language.</p><p>How best to manage the evolution (versioning) of Web based systems is,
! at the time of writing, the subject of a wide-ranging debate. However,
there are three activities within the W3C that are directly relevant
to versioning of Web services description:</p>
***************
*** 3732,3736 ****
rdf:type statements (an interface will belong to the class
Interface and an operation within an interface will belong to
! the class InterfaceOperation, for example).</p></item><item><p>All relationships in WSDL 2.0 (like an Operation belonging to an
Interface and having a given operation style) are turned into
RDF statements using appropriate properties, such as <code>operation</code>
--- 3750,3754 ----
rdf:type statements (an interface will belong to the class
Interface and an operation within an interface will belong to
! the class InterfaceOperation, for example).</p></item><item><p>All relationships in WSDL 2.0 (like an Operation's belonging to an
Interface and having a given operation style) are turned into
RDF statements using appropriate properties, such as <code>operation</code>
***************
*** 3755,3759 ****
relative URIs is allowed and warranted in many
cases. For information on processing relative URIs, see
! <loc href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396</loc>.</p></div3><div3 id="adv-generating-uris"><head>Generating Temporary URIs</head><p>In general, when a WSDL 2.0 document is published for use by others, it should only contain URIs that are globally unique. This is usually done by allocating them under a domain name that is controlled by the issuer. For example, the W3C allocates namespace URIs under its base domain name, w3.org.</p><p>However, it is sometimes desirable to make
up a temporary URI for an entity, for use during development, but not make the URI globally unique
for all time and have it "mean" that version of the
--- 3773,3778 ----
relative URIs is allowed and warranted in many
cases. For information on processing relative URIs, see
! <loc href="http://www.ietf.org/rfc/rfc3986.txt">RFC3986</loc>.</p></div3>
! <div3 id="adv-generating-uris"><head>Generating Temporary URIs</head><p>In general, when a WSDL 2.0 document is published for use by others, it should only contain URIs that are globally unique. This is usually done by allocating them under a domain name that is controlled by the issuer. For example, the W3C allocates namespace URIs under its base domain name, w3.org.</p><p>However, it is sometimes desirable to make
up a temporary URI for an entity, for use during development, but not make the URI globally unique
for all time and have it "mean" that version of the
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.159
retrieving revision 1.160
diff -C 2 -d -r1.159 -r1.160
*** wsdl20-primer.html 19 Oct 2006 13:38:17 -0000 1.159
--- wsdl20-primer.html 20 Oct 2006 21:47:10 -0000 1.160
***************
*** 1,3 ****
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Description Language (WSDL) Version 2.0 Part 0: Primer</title><style type="text/css">
code { font-family: monospace; }
--- 1,3 ----
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Description Language (WSDL) Version 2.0 Part 0: Primer</title><style type="text/css">
code { font-family: monospace; }
***************
*** 91,97 ****
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#advanced-topic_ii">Advanced Topics I: Importing Mechanisms</a><br>4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility and Predefined Extensions</a><br>5. <a href="#advanced-topic_iv">Advanced Topics III: Miscellaneous</a><br>6. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br> 1.1 <a href="#Prerequisites">Prerequisites</a><br> 1.2 <a href="#PrimerStructure">Structure of this Primer</a><br> 1.3 <a href="#UseIRI">Use of URI and IRI</a><br> 1.4 <a href="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basic-example">Getting Started: The GreatH Hotel Example</a><br> 2.1.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.1.2 <a href="#basics-getting-started">Defining a WSDL 2.0 Target Namespace</a><br> 2.1.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br>   2.1.3 <a href="#basics-types">Defining Message Types</a><br> 2.1.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.1.4 <a href="#basics-interface">Defining an Interface</a><br> 2.1.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.1.5 <a href="#basics-binding">Defining a Binding</a><br> 2.1.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.1.6 <a href="#basics-service">Defining a Service</a><br> 2.1.6.1 <a href="#example-initial-service-explanation">Explanationof Example</a><br> 2.1.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.1.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br> 2.2 <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 2.2.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> 2.2.2 <a href="#wsdl-schema">WSDL 2.0 Schema</a><br> 2.2.2.1 <a href="#element-order">WSDL 2.0 Element Ordering</a><br> 2.2.3 <a href="#component-model">WSDL 2.0 Component Model</a><br> 2.2.3.1 <a href="#import-component">WSDL 2.0 Import and Include</a><br>  2.3 <a href="#more-types">More on Message Types</a><br> 2.3.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 2.3.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 2.3.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br> 2.4 <a href="#more-interfaces">More on Interfaces</a><br> 2.4.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 2.4.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 2.4.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 2.4.4 <a href="#more-interfaces-operations">Interface Operations</a><br> &nbp; 2.4.4.1 <a href="#more-interfaces-op-attr">Operation Attributes</a><br> 2.4.4.2 <a href="#N109D0">Operation Message References</a><br> 2.4.4.2.1 <a href="#N109ED">The messageLabel Attribute</a><br> 2.4.4.2.2 <a href="#N10A05">The element Attribute</a><br> 2.4.4.2.3 <a href="#N10A56">Multiple infault or outfault Elements</a><br> 2.4.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br> 2.5 <a href="#more-bindings">More on Bindings</a><br> &nsp; 2.5.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 2.5.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 2.5.3 <a href="#more-bindings-faults">Binding Faults</a><br> 2.5.4 <a href="#bindingOperations">Binding Operations</a><br> 2.5.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 2.5.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 2.5.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 2.5.6.1 <a href="#N10C24">Explanation of
! Example</a><br> 2.5.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>3. <a href="#advanced-topic_ii">Advanced Topics I: Importing Mechanisms</a><br> 3.1 <a href="#adv-import-and-authoring">Importing WSDL</a><br> 3.2 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 3.2.1 <a href="#N10D74">Schemas in Imported Documents</a><br> 3.2.2 <a href="#N10DFF">Multiple Inline Schemas in One Document</a><br> 3.2.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 3.2.3.1 <a href="#N10E5F">Using the id Attribute to Identify Inline
! Schemas</a><br>4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility and Predefined Extensions</a><br> 4.1 <a href="#adv-extensibility">Extensibility</a><br> 4.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 4.2 <a href="#adv-FP">Features and Properties</a><br> 4.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 4.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 4.2.3 <a href="#adv-fp-properties">Properties</a><br> 4.3 <a href="#adv-MEP">Defining New MEPs</a><br> 4.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 4.4 <a href="#adv-RPCstyle">RPC Style</a><br> 4.5 <a href"#adv-MTOM">MTOM and Attachments Support</a><br>5. <a href="#advanced-topic_iv">Advanced Topics III: Miscellaneous</a><br> 5.1 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 5.2 <a href="#adv-versioning">Web Service Versioning</a><br> 5.2.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 5.2.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 5.2.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 5.2.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 5.2.5 <a href="#adv-versioning-examples">Examples of Versioning and Extending a Service</a><br> 5.2.5.1 <a href="#N1123F">Additional Opional Elements Added in Content</a><br> 5.2.5.2 <a href="#N11256">Additional Optional Elements Added to a Header</a><br> 5.2.5.3 <a href="#N1126D">Additional Mandatory Elements in Content</a><br> 5.2.5.4 <a href="#N11284">Additional Optional Operation Added to Interface</a><br> 5.2.5.5 <a href="#N11290">Additional Mandatory Operation Added to Interface</a><br> 5.2.5.6 <a href="#N112AA">Indicating Incompatibility by Changing the Endpoint URI</a><br> 5.2.5.7 <a href="#N112B3">Indicating Incompatibility by Changing the SOAP Action</a><br> &bsp; 5.2.5.8 <a href="#N112CA">Indicating Incompatibility by Changing the Element Content</a><br> 5.3 <a href="#adv-service-references">
Describing Web Service Messages That Refer to Other Web
Services
--- 91,97 ----
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#advanced-topic_ii">Advanced Topics I: Importing Mechanisms</a><br>4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility and Predefined Extensions</a><br>5. <a href="#advanced-topic_iv">Advanced Topics III: Miscellaneous</a><br>6. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br> 1.1 <a href="#Prerequisites">Prerequisites</a><br> 1.2 <a href="#PrimerStructure">Structure of this Primer</a><br> 1.3 <a href="#UseIRI">Use of URIs and IRIs</a><br> 1.4 <a href="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basic-example">Getting Started: The GreatH Hotel Example</a><br> 2.1.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.1.2 <a href="#basics-getting-started">Defining a WSDL 2.0 Target Namespace</a><br> 2.1.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br> &nbp; 2.1.3 <a href="#basics-types">Defining Message Types</a><br> 2.1.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.1.4 <a href="#basics-interface">Defining an Interface</a><br> 2.1.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.1.5 <a href="#basics-binding">Defining a Binding</a><br> 2.1.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.1.6 <a href="#basics-service">Defining a Service</a><br> 2.1.6.1 <a href="#example-initial-service-explanation">Explanatin of Example</a><br> 2.1.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.1.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br> 2.2 <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 2.2.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> 2.2.2 <a href="#wsdl-schema">WSDL 2.0 Schema</a><br> 2.2.2.1 <a href="#element-order">WSDL 2.0 Element Ordering</a><br> 2.2.3 <a href="#component-model">WSDL 2.0 Component Model</a><br> 2.2.3.1 <a href="#import-component">WSDL 2.0 Import and Include</a><br>&nbp; 2.3 <a href="#more-types">More on Message Types</a><br> 2.3.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 2.3.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 2.3.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br> 2.4 <a href="#more-interfaces">More on Interfaces</a><br> 2.4.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 2.4.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 2.4.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 2.4.4 <a href="#more-interfaces-operations">Interface Operations</a><br> &bsp; 2.4.4.1 <a href="#more-interfaces-op-attr">Operation Attributes</a><br> 2.4.4.2 <a href="#N109CF">Operation Message References</a><br> 2.4.4.2.1 <a href="#N109EC">The messageLabel Attribute</a><br> 2.4.4.2.2 <a href="#N10A04">The element Attribute</a><br> 2.4.4.2.3 <a href="#N10A55">Multiple infault or outfault Elements</a><br> 2.4.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br> 2.5 <a href="#more-bindings">More on Bindings</a><br> nbsp; 2.5.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 2.5.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 2.5.3 <a href="#more-bindings-faults">Binding Faults</a><br> 2.5.4 <a href="#bindingOperations">Binding Operations</a><br> 2.5.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 2.5.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 2.5.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 2.5.6.1 <a href="#N10C23">Explanation of
! Example</a><br> 2.5.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>3. <a href="#advanced-topic_ii">Advanced Topics I: Importing Mechanisms</a><br> 3.1 <a href="#adv-import-and-authoring">Importing WSDL</a><br> 3.2 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 3.2.1 <a href="#N10D73">Schemas in Imported Documents</a><br> 3.2.2 <a href="#N10DFE">Multiple Inline Schemas in One Document</a><br> 3.2.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 3.2.3.1 <a href="#N10E5E">Using the id Attribute to Identify Inline
! Schemas</a><br>4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility and Predefined Extensions</a><br> 4.1 <a href="#adv-extensibility">Extensibility</a><br> 4.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 4.2 <a href="#adv-FP">Features and Properties</a><br> 4.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 4.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 4.2.3 <a href="#adv-fp-properties">Properties</a><br> 4.3 <a href="#adv-MEP">Defining New MEPs</a><br> 4.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 4.4 <a href="#adv-RPCstyle">RPC Style</a><br> 4.5 <a href"#adv-MTOM">MTOM and Attachments Support</a><br>5. <a href="#advanced-topic_iv">Advanced Topics III: Miscellaneous</a><br> 5.1 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 5.2 <a href="#adv-versioning">Web Service Versioning</a><br> 5.2.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 5.2.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 5.2.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 5.2.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 5.2.5 <a href="#adv-versioning-examples">Examples of Versioning and Extending a Service</a><br> 5.2.5.1 <a href="#N1123E">Additional Opional Elements Added in Content</a><br> 5.2.5.2 <a href="#N11255">Additional Optional Elements Added to a Header</a><br> 5.2.5.3 <a href="#N1126C">Additional Mandatory Elements in Content</a><br> 5.2.5.4 <a href="#N11283">Additional Optional Operation Added to Interface</a><br> 5.2.5.5 <a href="#N1128F">Additional Mandatory Operation Added to Interface</a><br> 5.2.5.6 <a href="#N112A9">Indicating Incompatibility by Changing the Endpoint URI</a><br> 5.2.5.7 <a href="#N112B2">Indicating Incompatibility by Changing the SOAP Action</a><br> &bsp; 5.2.5.8 <a href="#N112C9">Indicating Incompatibility by Changing the Element Content</a><br> 5.3 <a href="#adv-service-references">
Describing Web Service Messages That Refer to Other Web
Services
***************
*** 133,137 ****
<div class="div2">
! <h3><a name="UseIRI"></a>1.3 Use of URI and IRI</h3>
<p>The core specification of WSDL 2.0 supports Internationalized Resource Identifiers or IRIs [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]. IRIs are a superset of URIs with added support for internationalization. The URI syntax [<cite><a href="#RFC3986">IETF RFC 3986</a></cite>] only allows the use of a small set of characters, including upper and lower case letters of the English alphabet, European numerals and a few symbols. IRIs allow the use of characters from a wider range of language scripts. </p>
--- 133,137 ----
<div class="div2">
! <h3><a name="UseIRI"></a>1.3 Use of URIs and IRIs</h3>
<p>The core specification of WSDL 2.0 supports Internationalized Resource Identifiers or IRIs [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]. IRIs are a superset of URIs with added support for internationalization. The URI syntax [<cite><a href="#RFC3986">IETF RFC 3986</a></cite>] only allows the use of a small set of characters, including upper and lower case letters of the English alphabet, European numerals and a few symbols. IRIs allow the use of characters from a wider range of language scripts. </p>
***************
*** 167,171 ****
-
<div class="div1">
--- 167,170 ----
***************
*** 176,181 ****
<p>This section introduces the basic concepts used in WSDL 2.0 through the description of a hypothetical hotel reservation service. We start with a simple scenario, and later add more requirements to illustrate how more advanced WSDL 2.0 features may be used. </p>
<div class="div3">
! <h4><a name="basics-greath-scenario"></a>2.1.1 Example Scenario: The GreatH Hotel Reservation Service</h4><p>Hotel GreatH (a fictional hotel) is located in a remote island. It has been relying on fax and phone to provide room reservations. Even though the facilities and prices at GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH. After research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet. GreatH then hires us to build a reservation Web service with the following functionality: <ul><li><p><em>CheckAvailability</em>. To check availability, the client must specify a check-in date, a check-out date, and room type. The Web service will return a room rate (a floating point number in USD$) if such a room is available, or a zero room rate if not. If any input data is invalid, the service should return an error. Thus the service will accept a <code>checkAvailability</code> message and return a <code>checkAvailabilityResponse</code> or <code>invalidDataFault</code> message.</p> </li><li><p><em>MakeReservation</em>. To make a reservation, a client must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is successful. The service will return an error message if the credit card number or any other data field is invalid. Thus, the service will accept a <code>makeReservation</code> message and return a <code>makeReservationResponse</code> or <code>invalidCreditCardFault</code> message.</p></li></ul> We know that we will later need to build a complete system that supports transactions and secured transmission, but initially we will implement only minimal functionality. In fact, to simplify our first example, we will implement only the <em>CheckAvailability</em> operation. </p><p>The next several sections proceed step-by-step through the process of dveloping a WSDL 2.0 document that describes the desired Web service. However, for those who can't wait to see a complete example, here is the WSDL 2.0 document that we'll be creating.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-initial"></a><i><span>Example 2-1. </span>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</i></p>
<div class="exampleInner"><pre>
--- 175,181 ----
<p>This section introduces the basic concepts used in WSDL 2.0 through the description of a hypothetical hotel reservation service. We start with a simple scenario, and later add more requirements to illustrate how more advanced WSDL 2.0 features may be used. </p>
+
<div class="div3">
! <h4><a name="basics-greath-scenario"></a>2.1.1 Example Scenario: The GreatH Hotel Reservation Service</h4><p>Hotel GreatH (a fictional hotel) is located in a remote island. It has been relying on fax and phone to provide room reservations. Even though the facilities and prices at GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH. After research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet. GreatH then hires us to build a reservation Web service with the following functionality: <ul><li><p><em>CheckAvailability</em>. To check availability, the client must specify a check-in date, a check-out date, and room type. The Web service will return a room rate (a floating point number in USD) if such a room is available, or a zero room rate if not. If any input data is invalid, the service should return an error. Thus,the service will accept a <code>checkAvailability</code> message and return a <code>checkAvailabilityResponse</code> or <code>invalidDataFault</code> message.</p> </li><li><p><em>MakeReservation</em>. To make a reservation, a client must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is successful. The service will return an error message if the credit card number or any other data field is invalid. Thus, the service will accept a <code>makeReservation</code> message and return a <code>makeReservationResponse</code> or <code>invalidCreditCardFault</code> message.</p></li></ul> We know that we will later need to build a complete system that supports transactions and secured transmission, but initially we will implement only minimal functionality. In fact, to simplify our first example, we will implement only the <em>CheckAvailability</em> operation. </p><p>The next several sections proceed step-by-step through the process of deeloping a WSDL 2.0 document that describes the desired Web service. However, for those who can't wait to see a complete example, here is the WSDL 2.0 document that we'll be creating.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-initial"></a><i><span>Example 2-1. </span>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</i></p>
<div class="exampleInner"><pre>
***************
*** 554,558 ****
<h3><a name="wsdl-xml-representation"></a>2.2 WSDL 2.0 Infoset, Schema and Component Model</h3>
! <p>In computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a finite string of literal symbols or characters. A language specification must therefore define the set sentences in that language, and, to be useful, it should also indicate the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <em>XML Infoset</em> [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically, a <em>WSDL 2.0 document</em> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification.</p<p>Since an XML Infoset can be created from more than one physical document, a WSDL 2.0 document does not necessarily correspond to a single <em>physical</em> document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. In such cases, the meaning of the including or importing document as a whole will depend (in part) on the meaning of the included or imported document.</p><p>The XML Infoset uses terms like "element information item" and "attribute information item". Unfortunately, those terms are rather lengthy to repeat often. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respectvely.</p>
<div class="div3">
--- 554,558 ----
<h3><a name="wsdl-xml-representation"></a>2.2 WSDL 2.0 Infoset, Schema and Component Model</h3>
! <p>In computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a finite string of literal symbols or characters. A language specification must therefore define the set of sentences in that language, and, to be useful, it should also indicate the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <em>XML Infoset</em> [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically, a <em>WSDL 2.0 document</em> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification./p><p>Since an XML Infoset can be created from more than one physical document, a WSDL 2.0 document does not necessarily correspond to a single <em>physical</em> document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. In such cases, the meaning of the including or importing document as a whole will depend (in part) on the meaning of the included or imported document.</p><p>The XML Infoset uses terms like "element information item" and "attribute information item". Unfortunately, those terms are rather lengthy to repeat often. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respctively.</p>
<div class="div3">
***************
*** 576,580 ****
<p>This section gives an example of how WSDL 2.0 specification constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0 elements.</p>
! <p>Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] section "<a href="wsdl20.html#Description_XMLRep">XML Representation of Description Component</a>") clearly states a set of constraints about how the children elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, in spite of what the WSDL 2.0 schema says. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<div class="exampleInner"><pre>
--- 576,580 ----
<p>This section gives an example of how WSDL 2.0 specification constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0 elements.</p>
! <p>Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] section "<a href="wsdl20.html#Description_XMLRep">XML Representation of Description Component</a>") clearly states a set of constraints about how the child elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, even though the WSDL 2.0 schema does not capture this constraint. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<div class="exampleInner"><pre>
***************
*** 671,677 ****
<p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <em>Description</em>, <em>Interface</em>, <em>Binding</em>, <em>Service</em> and <em>Endpoint</em> <em>components</em> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p>
! <p>Furthermore, each of these components has <em>properties</em> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!).
!
! </p>
<div class="div4">
<h5><a name="import-component"></a>2.2.3.1 WSDL 2.0 Import and Include</h5>
--- 671,675 ----
<p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <em>Description</em>, <em>Interface</em>, <em>Binding</em>, <em>Service</em> and <em>Endpoint</em> <em>components</em> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p>
! <p>Furthermore, each of these components has <em>properties</em> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!)</p>
<div class="div4">
<h5><a name="import-component"></a>2.2.3.1 WSDL 2.0 Import and Include</h5>
***************
*** 855,859 ****
! <p>So far we have briefly covered both WSDL import/include and schema import/include. The following table summarizes the similarities and differences
between the WSDL 2.0 and XML Schema
<code>include</code> and <code>import</code> mechanisms. We will talk a lot more about importing mechanisms in <a href="#adv-import-and-authoring"><b>3.1 Importing WSDL</b></a> and <a href="#adv-multiple-inline-schemas"><b>3.2 Importing Schemas</b></a></p>
--- 853,857 ----
! <p>So far we have briefly covered both WSDL import and include and schema import and include. The following table summarizes the similarities and differences
between the WSDL 2.0 and XML Schema
<code>include</code> and <code>import</code> mechanisms. We will talk a lot more about importing mechanisms in <a href="#adv-import-and-authoring"><b>3.1 Importing WSDL</b></a> and <a href="#adv-multiple-inline-schemas"><b>3.2 Importing Schemas</b></a></p>
***************
*** 1173,1180 ****
</div><div class="div4">
! <h5><a name="N109D0"></a>2.4.4.2 Operation Message References</h5><p>An <code>operation</code> will also have <code>input</code>, <code>output</code>,<code>infault</code>, and/or <code>outfault</code> element children that specify the ordinary and fault message types to be used by that operation. The MEP specified by the <code>pattern</code> attribute determines which of these elements should be included, since each MEP has placeholders for the message types involved in its pattern. </p><p>Since operations were already discussed in <a href="#basics-interface"><b>2.1.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div5">
! <h6><a name="N109ED"></a>2.4.4.2.1 The messageLabel Attribute</h6>
<p>
The
--- 1171,1178 ----
</div><div class="div4">
! <h5><a name="N109CF"></a>2.4.4.2 Operation Message References</h5><p>An <code>operation</code> will also have <code>input</code>, <code>output</code>,<code>infault</code>, and/or <code>outfault</code> element children that specify the ordinary and fault message types to be used by that operation. The MEP specified by the <code>pattern</code> attribute determines which of these elements should be included, since each MEP has placeholders for the message types involved in its pattern. </p><p>Since operations were already discussed in <a href="#basics-interface"><b>2.1.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div5">
! <h6><a name="N109EC"></a>2.4.4.2.1 The messageLabel Attribute</h6>
<p>
The
***************
*** 1196,1200 ****
<div class="div5">
! <h6><a name="N10A05"></a>2.4.4.2.2 The element Attribute</h6>
<p>
The
--- 1194,1198 ----
<div class="div5">
! <h6><a name="N10A04"></a>2.4.4.2.2 The element Attribute</h6>
<p>
The
***************
*** 1257,1261 ****
</div>
<div class="div5">
! <h6><a name="N10A56"></a>2.4.4.2.3 Multiple infault or outfault Elements</h6><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div></div>
--- 1255,1259 ----
</div>
<div class="div5">
! <h6><a name="N10A55"></a>2.4.4.2.3 Multiple infault or outfault Elements</h6><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div></div>
***************
*** 1479,1483 ****
</div>
<div class="div4">
! <h5><a name="N10C24"></a>2.5.6.1 Explanation of
Example</h5>
--- 1477,1481 ----
</div>
<div class="div4">
! <h5><a name="N10C23"></a>2.5.6.1 Explanation of
Example</h5>
***************
*** 1725,1729 ****
<div class="div3">
! <h4><a name="N10D74"></a>3.2.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
--- 1723,1727 ----
<div class="div3">
! <h4><a name="N10D73"></a>3.2.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
***************
*** 1932,1936 ****
<div class="div3">
! <h4><a name="N10DFF"></a>3.2.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
--- 1930,1934 ----
<div class="div3">
! <h4><a name="N10DFE"></a>3.2.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
***************
*** 2066,2070 ****
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer (see [<cite><a href="#XPTR">XPointer Framework</a></cite>]) can also be used.
</p><div class="div4">
! <h5><a name="N10E5F"></a>3.2.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 3-6</a>
--- 2064,2068 ----
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer (see [<cite><a href="#XPTR">XPointer Framework</a></cite>]) can also be used.
</p><div class="div4">
! <h5><a name="N10E5E"></a>3.2.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 3-6</a>
***************
*** 2155,2159 ****
<h3><a name="adv-extensibility"></a>4.1 Extensibility</h3>
<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 in a WSDL 2.0 document; and <a href="wsdl20.html#Feature">Features</a> and <a href="wsdl20.html#Property">Properties</a>. 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 <a href="http://www.w3.org/2001/tag/">W3C TAG</a> has been discussing the issue (see TAG issue <a href="http://www.w3.org/2001/tg/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</a>) and is likely to provide guidance at some point.</p><div class="div3">
! <h4><a name="adv-optional-versus-required"></a>4.1.1 Optional Versus Required Extensions</h4><p>Extensions can either be required or optional.</p><p>An <em>optional</em> 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 2.0 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 <em>client</em> -- not the service. A service must support all optional and required extensions that it advertises in its WSDL 2.0 document. </p><p>A <em>required</em> extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by attribute <code>wsdl:required="true"<code>. If a WSDL 2.0 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 2.0 processor. </p></div>
--- 2153,2157 ----
<h3><a name="adv-extensibility"></a>4.1 Extensibility</h3>
<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 in a WSDL 2.0 document; and <a href="wsdl20.html#Feature">Features</a> and <a href="wsdl20.html#Property">Properties</a>. 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 <a href="http://www.w3.org/2001/tag/">W3C TAG</a> has been discussing the issue (see TAG issue <a href="http://www.w3.org/2001/tg/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</a>) and is likely to provide guidance at some point.</p><div class="div3">
! <h4><a name="adv-optional-versus-required"></a>4.1.1 Optional Versus Required Extensions</h4><p>Extensions can either be required or optional.</p><p>An <em>optional</em> extension is one that the client may either engage or ignore, entirely at its discretion, and is signaled by <code>wsdl:required="false"</code> or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). Thus, a WSDL 2.0 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 <em>client</em> -- not the service. A service must support all optional and required extensions that it advertises in its WSDL 2.0 document. </p><p>A <em>required</em> extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by <code>wsdl:required="true"</code>. If a WSDL .0 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 2.0 processor. </p></div>
***************
*** 2247,2251 ****
<simpleType name="securityLevelConstraint">
<restriction base="xs:int">
! <min 3, max 7> <!-- check schema for syntax -->
</restriction>
</simpleType>
--- 2245,2250 ----
<simpleType name="securityLevelConstraint">
<restriction base="xs:int">
! <minInclusive value="3"/>
! <maxInclusive value="7"/>
</restriction>
</simpleType>
***************
*** 2659,2667 ****
<h3><a name="adv-message-dispatch"></a>5.1 Enabling Easy Message Dispatch</h3>
! <p>It is desirable for a message recipient to have the capability to uniquely identify a message in order to handle it correctly. The capability of identifying a message is typically used for dispatching purposes within an implementation of a web service. Therefore, WSDL authors are recommended to take disambiguating of messages that are defined in a description into consideration when they develop descriptions of their services. </p>
! <p>The context in which a Web service may be deployed plays an important role in choosing an appropriate way to disambiguate and identify messages. In a typical deployment, an endpoint address may host a single service that is described by a WSDL service element. In this case, when XSD is used, assigning unique qualified names of global element declarations as inputs within the interface that describes the service would be sufficient to disambiguate the messages that are received. However, when endpoint address hosts multiple services, in essence supports several WSDL descriptions, the desire to disambiguate messages should considered within the context of all the deployed services, not only within a single interface. </p>
! <p>As explained in <a href="#more-interfaces-op-attr"><b>2.4.4.1 Operation Attributes</b></a>, when XSD is used as the type system, a few special tokens can be used for the <code>element</code> attributes. Uniquely identifying a message may become very difficult when:
<ul>
--- 2658,2679 ----
<h3><a name="adv-message-dispatch"></a>5.1 Enabling Easy Message Dispatch</h3>
! <p>It is desirable for a message recipient to have the capability to uniquely identify a message
! type in order to handle it correctly. The capability of identifying a message type is typically
! used for dispatching purposes within an implementation of a web service. Therefore, WSDL authors
! are recommended to consider how to disambiguate message types when they develop their services.</p>
! <p>The context in which a Web service may be deployed plays an important role in choosing an
! appropriate way to disambiguate and identify message types. In a typical deployment, an endpoint
! address may host a single service that is described by a WSDL service element. In this case,
! when XSD is used, assigning unique qualified names of global element declarations as inputs
! within the interface that describes the service would be sufficient to disambiguate the types
! of the messages that are received. However, when endpoint address hosts multiple services,
! in essence supporting several WSDL descriptions, the desire to disambiguate message types
! should be considered within the context of all the deployed services, not only within a single
! interface.</p>
! <p>As explained in <a href="#more-interfaces-op-attr"><b>2.4.4.1 Operation Attributes</b></a>, when XSD is used as the type
! system, a few special tokens can be used for the <code>element</code> attributes. Uniquely
! identifying a message type may become very difficult when:
<ul>
***************
*** 2669,2673 ****
<p>
any of these input elements within an interface has a value
! of “#any”; or
</p>
</li>
--- 2681,2685 ----
<p>
any of these input elements within an interface has a value
! of "#any"; or
</p>
</li>
***************
*** 2675,2679 ****
<p>
more than one of these input elements (see below) has a
! value of “#none”; or
</p>
</li>
--- 2687,2691 ----
<p>
more than one of these input elements (see below) has a
! value of "#none"; or
</p>
</li>
***************
*** 2725,2729 ****
</ul>
! <p>In addition, WS-Addressing [WS-Addressing] specification already provides a disambiguation mechanism. It defines a required [action] property whose value is always present in a message delivery. The value of the action property can be used to disambiguate the message by the receiver and there is a well defined way to associate actions to messages in WS-Addressing specifications. Further, WS-Addressing also provides an appropriate default action value that identifies each message uniquely. </p>
--- 2737,2747 ----
</ul>
! <p>In addition, WS-Addressing [WS-Addressing] specification already provides a
! disambiguation mechanism. It defines a required [action] property whose value is
! always present in a message delivery. The value of the action property can be used
! to disambiguate the message by the receiver and there is a well defined way to
! associate actions to messages in WS-Addressing specifications. Further, WS-Addressing
! also provides an appropriate default action value that identifies each message type
! uniquely. </p>
***************
*** 2738,2742 ****
other messages beyond those described in a particular WSDL 2.0 document. Often
this circumstance occurs following an evolution of the client and/or service, and thus an evolution of the interaction language.</p><p>How best to manage the evolution (versioning) of Web based systems is,
! at the time of writing, the subject of a wide ranging debate. However,
there are three activities within the W3C that are directly relevant
to versioning of Web services description:</p>
--- 2756,2760 ----
other messages beyond those described in a particular WSDL 2.0 document. Often
this circumstance occurs following an evolution of the client and/or service, and thus an evolution of the interaction language.</p><p>How best to manage the evolution (versioning) of Web based systems is,
! at the time of writing, the subject of a wide-ranging debate. However,
there are three activities within the W3C that are directly relevant
to versioning of Web services description:</p>
***************
*** 2843,2847 ****
<div class="div4">
! <h5><a name="N1123F"></a>5.2.5.1 Additional Optional Elements Added in Content</h5>
<p> The following example demonstrates how content may be extended with
additional content. The reservation service is changed to a newer version that can accept an optional
--- 2861,2865 ----
<div class="div4">
! <h5><a name="N1123E"></a>5.2.5.1 Additional Optional Elements Added in Content</h5>
<p> The following example demonstrates how content may be extended with
additional content. The reservation service is changed to a newer version that can accept an optional
***************
*** 2872,2876 ****
<div class="div4">
! <h5><a name="N11256"></a>5.2.5.2 Additional Optional Elements Added to a Header</h5>
<p> Another option is to add the extension as a header block. This is
accomplished by defining an element for the extension and adding a
--- 2890,2894 ----
<div class="div4">
! <h5><a name="N11255"></a>5.2.5.2 Additional Optional Elements Added to a Header</h5>
<p> Another option is to add the extension as a header block. This is
accomplished by defining an element for the extension and adding a
***************
*** 2907,2911 ****
<div class="div4">
! <h5><a name="N1126D"></a>5.2.5.3 Additional Mandatory Elements in Content</h5>
<p> This following example demonstrates an extension with additional
content. The reservation service requires a number of guests parameter.
--- 2925,2929 ----
<div class="div4">
! <h5><a name="N1126C"></a>5.2.5.3 Additional Mandatory Elements in Content</h5>
<p> This following example demonstrates an extension with additional
content. The reservation service requires a number of guests parameter.
***************
*** 2935,2939 ****
<div class="div4">
! <h5><a name="N11284"></a>5.2.5.4 Additional Optional Operation Added to Interface</h5>
<p> Section <a href="#more-interfaces-inheritance"><b>2.4.2 Interface Inheritance</b></a> shows another type
of versioning or extension, where the reservationInterface extends the
--- 2953,2957 ----
<div class="div4">
! <h5><a name="N11283"></a>5.2.5.4 Additional Optional Operation Added to Interface</h5>
<p> Section <a href="#more-interfaces-inheritance"><b>2.4.2 Interface Inheritance</b></a> shows another type
of versioning or extension, where the reservationInterface extends the
***************
*** 2944,2948 ****
<div class="div4">
! <h5><a name="N11290"></a>5.2.5.5 Additional Mandatory Operation Added to Interface</h5>
<p> Often mandatory operations are added to an interface. The Hotel service
decides to add an operation to the reservation service which is a
--- 2962,2966 ----
<div class="div4">
! <h5><a name="N1128F"></a>5.2.5.5 Additional Mandatory Operation Added to Interface</h5>
<p> Often mandatory operations are added to an interface. The Hotel service
decides to add an operation to the reservation service which is a
***************
*** 2987,2991 ****
<div class="div4">
! <h5><a name="N112AA"></a>5.2.5.6 Indicating Incompatibility by Changing the Endpoint URI</h5>
<p> To indicate incompatibility, the URI of the Hotel Endpoint can be
changed and messages send to the old Endpoint return a Fault.</p>
--- 3005,3009 ----
<div class="div4">
! <h5><a name="N112A9"></a>5.2.5.6 Indicating Incompatibility by Changing the Endpoint URI</h5>
<p> To indicate incompatibility, the URI of the Hotel Endpoint can be
changed and messages send to the old Endpoint return a Fault.</p>
***************
*** 2993,2997 ****
<div class="div4">
! <h5><a name="N112B3"></a>5.2.5.7 Indicating Incompatibility by Changing the SOAP Action</h5>
<p> The SOAP Action can be set for the makeReservation request, and making
it different than the earlier version should indicate incompatibility.</p>
--- 3011,3015 ----
<div class="div4">
! <h5><a name="N112B2"></a>5.2.5.7 Indicating Incompatibility by Changing the SOAP Action</h5>
<p> The SOAP Action can be set for the makeReservation request, and making
it different than the earlier version should indicate incompatibility.</p>
***************
*** 3014,3018 ****
<div class="div4">
! <h5><a name="N112CA"></a>5.2.5.8 Indicating Incompatibility by Changing the Element Content</h5>
<p> The namespace or name of the makeReservation element can be changed, and
then the interface and bindings changed. To indicate incompatibility,
--- 3032,3036 ----
<div class="div4">
! <h5><a name="N112C9"></a>5.2.5.8 Indicating Incompatibility by Changing the Element Content</h5>
<p> The namespace or name of the makeReservation element can be changed, and
then the interface and bindings changed. To indicate incompatibility,
***************
*** 3830,3834 ****
rdf:type statements (an interface will belong to the class
Interface and an operation within an interface will belong to
! the class InterfaceOperation, for example).</p></li><li><p>All relationships in WSDL 2.0 (like an Operation belonging to an
Interface and having a given operation style) are turned into
RDF statements using appropriate properties, such as <code>operation</code>
--- 3848,3852 ----
rdf:type statements (an interface will belong to the class
Interface and an operation within an interface will belong to
! the class InterfaceOperation, for example).</p></li><li><p>All relationships in WSDL 2.0 (like an Operation's belonging to an
Interface and having a given operation style) are turned into
RDF statements using appropriate properties, such as <code>operation</code>
***************
*** 3856,3860 ****
relative URIs is allowed and warranted in many
cases. For information on processing relative URIs, see
! <a href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396</a>.</p></div><div class="div3">
<h4><a name="adv-generating-uris"></a>5.6.3 Generating Temporary URIs</h4><p>In general, when a WSDL 2.0 document is published for use by others, it should only contain URIs that are globally unique. This is usually done by allocating them under a domain name that is controlled by the issuer. For example, the W3C allocates namespace URIs under its base domain name, w3.org.</p><p>However, it is sometimes desirable to make
up a temporary URI for an entity, for use during development, but not make the URI globally unique
--- 3874,3879 ----
relative URIs is allowed and warranted in many
cases. For information on processing relative URIs, see
! <a href="http://www.ietf.org/rfc/rfc3986.txt">RFC3986</a>.</p></div>
! <div class="div3">
<h4><a name="adv-generating-uris"></a>5.6.3 Generating Temporary URIs</h4><p>In general, when a WSDL 2.0 document is published for use by others, it should only contain URIs that are globally unique. This is usually done by allocating them under a domain name that is controlled by the issuer. For example, the W3C allocates namespace URIs under its base domain name, w3.org.</p><p>However, it is sometimes desirable to make
up a temporary URI for an entity, for use during development, but not make the URI globally unique
Received on Friday, 20 October 2006 21:47:25 UTC