- From: Hugo Haas via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 03 May 2005 12:38:32 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20 In directory homer:/tmp/cvs-serv29979 Modified Files: wsdl20-primer.xml Log Message: Using entity for Part 1 refs Index: wsdl20-primer.xml =================================================================== RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v retrieving revision 1.82 retrieving revision 1.83 diff -C2 -d -r1.82 -r1.83 *** wsdl20-primer.xml 3 May 2005 12:35:14 -0000 1.82 --- wsdl20-primer.xml 3 May 2005 12:38:30 -0000 1.83 *************** *** 76,80 **** </langusage> <revisiondesc> ! <p>Last Modif"Editor"Edit"Editors' copy $Date$</p> </revisiondesc> </header> --- 76,80 ---- </langusage> <revisiondesc> ! <p>Last Modif"Editor"Edit"Edi"Editors' copy $Date$</p> </revisiondesc> </header> *************** *** 499,503 **** </ednote> ! 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"/> "<xspecref href="http://www.w3.org/TR/wsdl20-primer#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"> --- 499,503 ---- </ednote> ! 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"/> "<xspecref href="&part1.latest;#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"> *************** *** 601,605 **** <div1 id="more-types"><head>More on Message Types</head> <p>The WSDL 2.0 <code>types</code> element provides a mechanism for enclosing message schemas in a WSDL 2.0 document. Because WSDL 2.0 directly supports schemas written in XML Schema ! <bibref ref="XMLSchemaP1"/>, we will focus here on the use of XML Schema to define message types. Schemas written in other type definition languages must be defined using a WSDL 2.0 language extension. For examples of other schema languages, see WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> Appendix E "<xspecref href="http://www.w3.org/TR/wsdl20-primer#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</xspecref>". <ednote><name>dbooth</name><date>2005-04-13</date><edtext>ToDo: Update the above reference to appendix E, as the WG decided to move it to a separate document.</edtext></ednote></p> --- 601,605 ---- <div1 id="more-types"><head>More on Message Types</head> <p>The WSDL 2.0 <code>types</code> element provides a mechanism for enclosing message schemas in a WSDL 2.0 document. Because WSDL 2.0 directly supports schemas written in XML Schema ! <bibref ref="XMLSchemaP1"/>, we will focus here on the use of XML Schema to define message types. Schemas written in other type definition languages must be defined using a WSDL 2.0 language extension. For examples of other schema languages, see WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> Appendix E "<xspecref href="&part1.latest;#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</xspecref>". <ednote><name>dbooth</name><date>2005-04-13</date><edtext>ToDo: Update the above reference to appendix E, as the WG decided to move it to a separate document.</edtext></ednote></p> *************** *** 624,628 **** <head>Embedding XML Schema</head> <p>We have already seen an example of using embedded schema definitions in section <specref ref="basics-types"/>, so we will merely add a few additional points here. </p><p>When XML Schema is embedded directly in a WSDL 2.0 document, it uses the existing top-level <code>xs:schema</code> element defined by XML Schema <bibref ref="XMLSchemaP1"/> to do so, as though the schema had been copied and pasted into the <code>types</code> element. The schema components defined in the embedded schema are then available to ! WSDL for reference by QName (see WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="http://www.w3.org/TR/wsdl20-primer#qnameres">QName Resolution</xspecref>"). </p> <p>Although WSDL 2.0 provides a <code>wsdl:import</code> mechanism (described in the next section), an embedded XML schema may also use XML Schema's native <code>xs:import</code> and <code>xs:include</code> elements to refer to schemas either in separate files or embedded in the same --- 624,628 ---- <head>Embedding XML Schema</head> <p>We have already seen an example of using embedded schema definitions in section <specref ref="basics-types"/>, so we will merely add a few additional points here. </p><p>When XML Schema is embedded directly in a WSDL 2.0 document, it uses the existing top-level <code>xs:schema</code> element defined by XML Schema <bibref ref="XMLSchemaP1"/> to do so, as though the schema had been copied and pasted into the <code>types</code> element. The schema components defined in the embedded schema are then available to ! WSDL for reference by QName (see WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="&part1.latest;#qnameres">QName Resolution</xspecref>"). </p> <p>Although WSDL 2.0 provides a <code>wsdl:import</code> mechanism (described in the next section), an embedded XML schema may also use XML Schema's native <code>xs:import</code> and <code>xs:include</code> elements to refer to schemas either in separate files or embedded in the same *************** *** 727,736 **** </eg> ! <p>The <code>interface</code> element has two optional attributes: <att>styleDefault</att> and <att>extends</att>. The <att>styleDefault</att> attribute can be used to define a default value for the <att>style</att> attributes of all operations under this interface (see WSDL 2.0 Part 1 "<xspecref href="http://www.w3.org/TR/wsdl20-primer#Interface_styleDefault_attribute">styleDefault attribute information item</xspecref>"). The <att>extends</att> attribute is for inheritance, and is explained next. </p> </div2> <div2 id="more-interfaces-inheritance"> <head>Interface Inheritance</head> ! <p>The optional <att>extends</att> attribute allows an interface to extend or inherit from one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines directly. Two things about extending interfaces deserve some attention. </p><p>First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given interface extends MUST NOT themselves extend that interface either directly or indirectly. </p><p>Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="http://www.w3.org/TR/wsdl20-primer#compequiv">Equivalence of Components</xspecref>") then they are considered to b the same operation, i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendents.) In the second case, if two operations have the same name in the same WSDL target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely. </p><p>Finally, since faults, features and properties can also be defined as children of the <code>interface</code> element (as described in the following sections), the same name-collision rules apply to those constructs. </p> <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service, the content of of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p> --- 727,736 ---- </eg> ! <p>The <code>interface</code> element has two optional attributes: <att>styleDefault</att> and <att>extends</att>. The <att>styleDefault</att> attribute can be used to define a default value for the <att>style</att> attributes of all operations under this interface (see WSDL 2.0 Part 1 "<xspecref href="&part1.latest;#Interface_styleDefault_attribute">styleDefault attribute information item</xspecref>"). The <att>extends</att> attribute is for inheritance, and is explained next. </p> </div2> <div2 id="more-interfaces-inheritance"> <head>Interface Inheritance</head> ! <p>The optional <att>extends</att> attribute allows an interface to extend or inherit from one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines directly. Two things about extending interfaces deserve some attention. </p><p>First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given interface extends MUST NOT themselves extend that interface either directly or indirectly. </p><p>Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="&part1.latest;#compequiv">Equivalence of Components</xspecref>") then they are considered to be the same operation i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendents.) In the second case, if two operations have the same name in the same WSDL target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely. </p><p>Finally, since faults, features and properties can also be defined as children of the <code>interface</code> element (as described in the following sections), the same name-collision rules apply to those constructs. </p> <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service, the content of of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p>
Received on Tuesday, 3 May 2005 12:38:44 UTC