- From: Roberto Chinnici via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 24 Feb 2005 01:57:16 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv2173
Modified Files:
wsdl20.html wsdl20.xml wsdl20.xsd xmlspec.dtd
Log Message:
Fixed validation problem.
Implemented LC5h, LC8, LC30, LC35, LC41, LC46.
Index: wsdl20.xsd
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20.xsd,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** wsdl20.xsd 26 Nov 2004 18:31:24 -0000 1.20
--- wsdl20.xsd 24 Feb 2005 01:57:14 -0000 1.21
***************
*** 286,289 ****
--- 286,290 ----
</xs:choice>
<xs:attribute name='name' type='xs:NCName' use='required' />
+ <xs:attribute name='type' type='xs:anyURI' use='required' />
<xs:attribute name='interface' type='xs:QName' use='optional' />
</xs:extension>
Index: xmlspec.dtd
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/xmlspec.dtd,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** xmlspec.dtd 11 Feb 2005 16:06:08 -0000 1.6
--- xmlspec.dtd 24 Feb 2005 01:57:14 -0000 1.7
***************
*** 2698,2699 ****
--- 2698,2700 ----
<!ELEMENT iff ANY>
<!ELEMENT neq ANY>
+ <!ELEMENT theta ANY>
Index: wsdl20.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20.html,v
retrieving revision 1.151
retrieving revision 1.152
diff -C2 -d -r1.151 -r1.152
*** wsdl20.html 22 Feb 2005 02:30:18 -0000 1.151
--- wsdl20.html 24 Feb 2005 01:57:14 -0000 1.152
***************
*** 1,4 ****
! <!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 1: Core Language</title><style type="text/css">
code { font-family: monospace; }
--- 1,15 ----
! <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
! <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
! <head>
! <meta name="generator" content=
[...18174 lines suppressed...]
! <td rowspan="1" colspan="1">Removed Jeffrey from authors :-( Added
! Gudge :-)</td>
! </tr>
! <tr>
! <td rowspan="1" colspan="1">20020620</td>
! <td rowspan="1" colspan="1">SW</td>
! <td rowspan="1" colspan="1">Started adding abstract model</td>
! </tr>
! <tr>
! <td rowspan="1" colspan="1">20020406</td>
! <td rowspan="1" colspan="1">SW</td>
! <td rowspan="1" colspan="1">Created document from WSDL 1.1</td>
! </tr>
! </tbody>
! </table>
! <br /></div>
! </div>
! </div>
! </body>
! </html>
Index: wsdl20.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20.xml,v
retrieving revision 1.177
retrieving revision 1.178
diff -C2 -d -r1.177 -r1.178
*** wsdl20.xml 22 Feb 2005 02:30:18 -0000 1.177
--- wsdl20.xml 24 Feb 2005 01:57:14 -0000 1.178
***************
*** 1181,1186 ****
<p>Note that it is RECOMMENDED that the value of the
! <att>targetNamespace</att> &AII; SHOULD be a dereferencible
! URI and that it resolve to a WSDL document which provides
service description information for that namespace.</p>
--- 1181,1186 ----
<p>Note that it is RECOMMENDED that the value of the
! <att>targetNamespace</att> &AII; be a dereferencible
! URI and that it resolves to a WSDL document which provides
service description information for that namespace.</p>
***************
*** 1401,1405 ****
<p>
The type of the <att>targetNamespace</att> &AII; is
! <emph>xs:anyURI</emph>.
</p>
--- 1401,1406 ----
<p>
The type of the <att>targetNamespace</att> &AII; is
! <emph>xs:anyURI</emph>. The value of the <att>targetNamespace</att>
! &AII; MUST be an absolute URI (see <bibref ref="RFC3986"/>).
</p>
***************
*** 1719,1775 ****
</z:notation>
- <p>Additionally, an Interface component MUST satisfy the Operation Name
- Mapping requirement, as defined below. This requirement is intended
- to ensure that a received message can be uniquely mapped to a
- corresponding wsdl:operation.
- </p>
-
- <div4 id="Interface_OperationName">
- <head>Operation Name Mapping Requirement</head>
-
- <p>Consider all Interface Operation components specified in the
- {operations} property of an Interface component. Further, consider
- all Message Reference components specified in the {message references}
- properties of said Interface Operation components. Further, consider
- all said Message Reference components that have the same value for
- their {direction} property (i.e., either the token <emph>in</emph>
- or the token <emph>out</emph>). If the {message content model}
- property of any of these Message Reference components has a value
- of “#any”, or if more than one of these Message Reference components
- has a value of “#none”, or if the qualified names of the global
- element declarations specified by the values of the {element}
- properties of these Message Reference components are not unique
- when considered together, then either one of the following two
- conditions MUST apply:
- </p>
- <olist>
- <item><p>the {features} property of the Interface component MUST
- contain a Feature component, having a {required} property with
- a value of <emph>true</emph>, that unambiguously identifies the mechanism
- that a message sender is required to support in order to enable
- the message recipient to unambiguously determine the name of the
- Interface Operation component that is intended to be associated
- with the received message; or
- </p>
- </item>
- <item><p>the &EII; for the Interface component
- MUST contain an extension element (i.e., an element that is not
- in the &wsdl-ns; namespace), having a wsdl:required &AII; with
- a value of <attval>true</attval>, that unambiguously identifies
- the mechanism that a message sender is required to support in
- order to enable the message recipient to unambiguously determine
- the name of the Interface Operation component that is intended
- to be associated with the received message.
- </p>
- </item>
- </olist>
-
- <p>WS-Addressing <bibref ref="ws-addr-core"/> provides a mechanism for implementing the
- Operation Name Mapping Requirment.
- The WS-Addressing [action] property embeds a value in each message that
- can be used to associate the message with a particular operation.
- </p>
-
- </div4>
</div3>
--- 1720,1723 ----
***************
*** 2377,2382 ****
interaction with the service consisting of a set (ordinary and
fault) messages exchanged between the service and the other
! roles involved in the interaction, in particular the service
! requester. The sequencing and cardinality of the messages
involved in a particular interaction is governed by the
<emph>message exchange pattern</emph> used by the operation
--- 2325,2330 ----
interaction with the service consisting of a set (ordinary and
fault) messages exchanged between the service and the other
! roles involved in the interaction, in particular the client.
! The sequencing and cardinality of the messages
involved in a particular interaction is governed by the
<emph>message exchange pattern</emph> used by the operation
***************
*** 2628,2632 ****
<head><att>wrpc:signature</att> Extension</head>
! <p>The <att>wrpc:signature</att> extension AII MAY be be used in conjunction with
the RPC style to describe the exact signature of the function represented
by an operation that uses the RPC style.</p>
--- 2576,2580 ----
<head><att>wrpc:signature</att> Extension</head>
! <p>The <att>wrpc:signature</att> extension &AII; MAY be used in conjunction with
the RPC style to describe the exact signature of the function represented
by an operation that uses the RPC style.</p>
***************
*** 2978,2982 ****
<p>The <att>safe</att> &AII; indicates whether the operation
! is <emph>safe</emph> or not.</p>
<p> The <att>safe</att> &AII; has the following
--- 2926,2930 ----
<p>The <att>safe</att> &AII; indicates whether the operation
! is declared to be <emph>safe</emph> or not.</p>
<p> The <att>safe</att> &AII; has the following
***************
*** 3683,3687 ****
</ulist>
<p>
! The type of the <att>fault</att> &AII; is
<emph>xs:QName</emph>.
</p>
--- 3631,3635 ----
</ulist>
<p>
! The type of the <att>ref</att> &AII; is
<emph>xs:QName</emph>.
</p>
***************
*** 3801,3805 ****
“routing”. The presence of a feature component in a WSDL description
indicates that the service supports the feature and may require a
! requester agent that interacts with the service to use that feature.
Each Feature is identified by its URI.</p>
--- 3749,3753 ----
“routing”. The presence of a feature component in a WSDL description
indicates that the service supports the feature and may require a
! client that interacts with the service to use that feature.
Each Feature is identified by its URI.</p>
***************
*** 3814,3822 ****
<item><p>{required} REQUIRED. An <emph>xs:boolean</emph>.
If the value of this property is <emph>true</emph>,
! then the requester agent MUST use the Feature that is identified
! by the {name} URI. Otherwise, the requester agent MAY use the
Feature that is identified by the {name} URI. In either case,
! if the requester agent does use the Feature that is identified
! by the {name} URI, then the requester agent MUST obey all semantics
implied by the definition of that Feature.</p></item>
</ulist>
--- 3762,3770 ----
<item><p>{required} REQUIRED. An <emph>xs:boolean</emph>.
If the value of this property is <emph>true</emph>,
! then the client MUST use the Feature that is identified
! by the {name} URI. Otherwise, the client MAY use the
Feature that is identified by the {name} URI. In either case,
! if the client does use the Feature that is identified
! by the {name} URI, then the client MUST obey all semantics
implied by the definition of that Feature.</p></item>
</ulist>
***************
*** 3861,3868 ****
The {features} property contains a subset of Feature components that are declared directly
in the given component.
! We refer to these as the <em>declared features</em> of the component.
Furthermore, the {features} property is itself a subset of Feature components that are required
or available for the given component.
! We refer to these as the <em>in-scope features</em> of the component.
</p>
--- 3809,3816 ----
The {features} property contains a subset of Feature components that are declared directly
in the given component.
! We refer to these as the <emph>declared features</emph> of the component.
Furthermore, the {features} property is itself a subset of Feature components that are required
or available for the given component.
! We refer to these as the <emph>in-scope features</emph> of the component.
</p>
***************
*** 3955,3958 ****
--- 3903,3907 ----
<eg xml:space="preserve"><description targetNamespace="http://example.com/bank"
+ xmlns=&wsdl-ns;
xmlns:ns1="http://example.com/bank">
<interface name="ns1:Bank">
***************
*** 4164,4172 ****
<item><p>{required} REQUIRED. An <emph>xs:boolean</emph> value.
If the {required} property is <emph>true</emph>,
! then the requester agent MUST use the Property that is identified
! by the {name} URI. Otherwise, the requester agent MAY use the
Property that is identified by the {name} URI. In either case,
! if the requester agent does use the Property that is identified
! by the {name} URI, then the requester agent MUST obey all semantics
implied by the definition of that Property.</p></item>
<item><p>{value constraint} OPTIONAL. A type definition constraining the
--- 4113,4121 ----
<item><p>{required} REQUIRED. An <emph>xs:boolean</emph> value.
If the {required} property is <emph>true</emph>,
! then the client MUST use the Property that is identified
! by the {name} URI. Otherwise, the client MAY use the
Property that is identified by the {name} URI. In either case,
! if the client does use the Property that is identified
! by the {name} URI, then the client MUST obey all semantics
implied by the definition of that Property.</p></item>
<item><p>{value constraint} OPTIONAL. A type definition constraining the
***************
*** 4297,4304 ****
The {properties} property contains a subset of Property components that are declared directly
in the given component.
! We refer to these as the <em>declared properties</em> of the component.
Furthermore, the {properties} property is itself a subset of Property components that are required
or available for the given component.
! We refer to these as the <em>in-scope properties</em> of the component.
</p>
--- 4246,4253 ----
The {properties} property contains a subset of Property components that are declared directly
in the given component.
! We refer to these as the <emph>declared properties</emph> of the component.
Furthermore, the {properties} property is itself a subset of Property components that are required
or available for the given component.
! We refer to these as the <emph>in-scope properties</emph> of the component.
</p>
***************
*** 5794,5797 ****
--- 5743,5802 ----
<p> For each Service component in the {services} property of a
description container, the {name} property MUST be unique. </p>
+
+ <p>Additionally, the Interface component that is the value of
+ the {interface} property of a Service component MUST satisfy the Operation
+ Name Mapping requirement, as defined below. This requirement is intended
+ to ensure that a received message can be uniquely mapped to a
+ corresponding wsdl:operation.
+ </p>
+
+ <div4 id="Service_OperationName">
+ <head>Operation Name Mapping Requirement</head>
+
+ <p>Consider the Interface component specified in the {interface}
+ property of a Service component. Further, consider all Interface Operation
+ components specified in the {operations} property of that Interface
+ component. Further, consider all Message Reference components specified
+ in the {message references} properties of said Interface Operation
+ components. Further, consider all said Message Reference components that
+ have the same value for their {direction} property (i.e., either the token
+ <emph>in</emph> or the token <emph>out</emph>). If the {message content
+ model} property of any of these Message Reference components has a value
+ of “#any”, or if more than one of these Message Reference
+ components has a value of “#none”, or if the qualified names of
+ the global element declarations specified by the values of the {element}
+ properties of these Message Reference components are not unique
+ when considered together, then either one of the following two
+ conditions MUST apply:
+ </p>
+ <olist>
+ <item><p>the {features} property of the Service or Interface components
+ MUST contain a Feature component, having a {required} property with
+ a value of <emph>true</emph>, that unambiguously identifies the
+ mechanism that a message sender is required to support in order to
+ enable the message recipient to unambiguously determine the name of the
+ Interface Operation component that is intended to be associated
+ with the received message; or
+ </p>
+ </item>
+ <item><p>the &EII; for the Interface component
+ MUST contain an extension element (i.e., an element that is not
+ in the &wsdl-ns; namespace), having a wsdl:required &AII; with
+ a value of <attval>true</attval>, that unambiguously identifies
+ the mechanism that a message sender is required to support in
+ order to enable the message recipient to unambiguously determine
+ the name of the Interface Operation component that is intended
+ to be associated with the received message.
+ </p>
+ </item>
+ </olist>
+
+ <p>WS-Addressing <bibref ref="ws-addr-core"/> provides a mechanism for
+ implementing the Operation Name Mapping Requirment.
+ The WS-Addressing [action] property embeds a value in each message that
+ can be used to associate the message with a particular operation.
+ </p>
+
+ </div4>
</div3>
***************
*** 6753,6757 ****
&EII;s MAY be used to refer to other XML schemas embedded in the same
WSDL description, provided that an appropriate value is specified for
! their <el>schemaLocation</el> &AII;s. The semantics of such &EII;s are
governed solely by the XML Schema specification <bibref ref='XMLSchemaP1'/>.</p>
<p>Note: It is NOT an error to import two or more schemas from the same
--- 6758,6763 ----
&EII;s MAY be used to refer to other XML schemas embedded in the same
WSDL description, provided that an appropriate value is specified for
! their <el>schemaLocation</el> &AII;s, such as a fragment identifier
! (see <bibref ref='XMLSchemaP1'/> 4.3.1). The semantics of such &EII;s are
governed solely by the XML Schema specification <bibref ref='XMLSchemaP1'/>.</p>
<p>Note: It is NOT an error to import two or more schemas from the same
***************
*** 7279,7285 ****
<p>
If a WSDL document declares an extension, Feature or Property as optional
! (i.e., NON-mandatory), then the provider agent MUST NOT assume that the
! requester agent supports that extension, Feature or Property, <emph>unless</emph> the
! provider agent knows (through some other means) that the requester agent
has in fact elected to engage and support that extension, Feature or
Property.
--- 7285,7291 ----
<p>
If a WSDL document declares an extension, Feature or Property as optional
! (i.e., NON-mandatory), then the Web service MUST NOT assume that the
! client supports that extension, Feature or Property, <emph>unless</emph> the
! Web service knows (through some other means) that the client
has in fact elected to engage and support that extension, Feature or
Property.
***************
*** 7287,7293 ****
<p>
! On the other hand, a requester agent MAY engage an extension, Feature or
Property that is declared as optional in the WSDL document. Therefore, the
! provider agent MUST support every extension, Feature or Property that is
declared as optional in the WSDL document, in addition to supporting every
extension, Feature or Property that is declared as mandatory.
--- 7293,7299 ----
<p>
! On the other hand, a client MAY engage an extension, Feature or
Property that is declared as optional in the WSDL document. Therefore, the
! Web service MUST support every extension, Feature or Property that is
declared as optional in the WSDL document, in addition to supporting every
extension, Feature or Property that is declared as mandatory.
***************
*** 7298,7302 ****
If finer-grain, direction-sensitive control of extensions, Features or
Properties is desired, then such extensions, Features or Properties may be
! designed in a direction-sensitive manner (from requester or from provider)
so that either direction may be separately marked required or
optional. For example, instead of defining a single extension that governs
--- 7304,7309 ----
If finer-grain, direction-sensitive control of extensions, Features or
Properties is desired, then such extensions, Features or Properties may be
! designed in a direction-sensitive manner (from the client or from the Web
! service)
so that either direction may be separately marked required or
optional. For example, instead of defining a single extension that governs
***************
*** 7538,7555 ****
<p>A conformant WSDL processor MAY safely ignore a
NON-mandatory extension or feature that it does not
! recognize or that it does not choose to implement.
</p>
<note><p>If a WSDL document declares an extension or feature
as optional, then if that extension or feature could apply
! to messages sent by the provider agent as well, then the
! provider agent MUST NOT send any messages that requires the
! requester agent to support that extension or feature. The
! requestor, on the othe hand, MAY engage that extension or
! feature in messages it sends to the provider.</p>
<p>If finer-grain control of extensions and features is
desired then such extensions and features must be designed
! in a direction (from requestor or from provider) sensitive
manner so that any direction may be marked required or
optional.</p></note>
--- 7545,7562 ----
<p>A conformant WSDL processor MAY safely ignore a
NON-mandatory extension or feature that it does not
! recognize or that it does not implement.
</p>
<note><p>If a WSDL document declares an extension or feature
as optional, then if that extension or feature could apply
! to messages sent by the Web service as well, then the
! Web service MUST NOT send any messages that require the
! client to support that extension or feature. The
! client, on the other hand, MAY engage that extension or
! feature in messages it sends to the Web service.</p>
<p>If finer-grain control of extensions and features is
desired then such extensions and features must be designed
! in a direction (from client or from Web service) sensitive
manner so that any direction may be marked required or
optional.</p></note>
***************
*** 7848,7865 ****
</bibl>
- <bibl key="WSDL 2.0 RDF Mapping"
- href="&w3c-designation-part2;"
- id="WSDL-PART4">
- <titleref>Web Services Description (WSDL) Version 2.0:
- RDF Mapping</titleref>, XYZ,
- Editors. World Wide Web Consortium, &draft.day;
- &draft.month; &draft.year;. This version of the "Web Services
- Description Version 2.0: RDF Mapping" Specification is available
- at &w3c-designation-part2;. The <loc
- href="&part2.latest;">latest version of "Web Services
- Description Version 2.0: RDF Mapping"</loc> is available at
- &part2.latest;.
- </bibl>
-
<bibl id="CHARMOD" key="Character Model for the WWW"
href="http://www.w3.org/TR/charmod/">
--- 7855,7858 ----
***************
*** 8062,8065 ****
--- 8055,8072 ----
</bibl>
+ <bibl key="WSDL 2.0 RDF Mapping"
+ href="&w3c-designation-part2;"
+ id="WSDL-PART4">
+ <titleref>Web Services Description (WSDL) Version 2.0:
+ RDF Mapping</titleref>, XYZ,
+ Editors. World Wide Web Consortium, &draft.day;
+ &draft.month; &draft.year;. This version of the "Web Services
+ Description Version 2.0: RDF Mapping" Specification is available
+ at &w3c-designation-part2;. The <loc
+ href="&part2.latest;">latest version of "Web Services
+ Description Version 2.0: RDF Mapping"</loc> is available at
+ &part2.latest;.
+ </bibl>
+
<bibl key="XPointer Framework"
href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"
***************
*** 8213,8223 ****
<head>Security considerations</head>
- <ednote>
- <name>JJM</name>
- <date>20021107</date>
- <edtext>Are there any security considerations other than the standard
- ones.</edtext>
- </ednote>
-
<p>This media type uses the <attval>+xml</attval> convention, it shares
the same security considerations as described in
--- 8220,8223 ----
***************
*** 8522,8528 ****
<div2 id='mig_ops'>
<head>Operation Overloading</head>
! <p>WSDL 1.1 supported operation overloading and WSDL 2.0 removes
! it. This section will provide some rationale for it and provide
! hints on how to work around some scenarios.</p>
</div2>
--- 8522,8527 ----
<div2 id='mig_ops'>
<head>Operation Overloading</head>
! <p>WSDL 1.1 supported operation overloading, whereas WSDL 2.0 does not.
! </p>
</div2>
***************
*** 8769,8772 ****
--- 8768,8788 ----
<tr>
+ <td>20050218</td>
+ <td>RRC</td>
+ <td>Replaced "provider agent" with "Web service" and "requester agent"
+ with "client" (resolution of LC30).</td>
+ </tr>
+ <tr>
+ <td>20050218</td>
+ <td>RRC</td>
+ <td>Moved section on the operation name mapping requirement to section
+ 2.13 (resolution of LC8).</td>
+ </tr>
+ <tr>
+ <td>20050218</td>
+ <td>RRC</td>
+ <td>Implemented resolution of LC5h.</td>
+ </tr>
+ <tr>
<td>20050220</td>
<td>AGR</td>
Received on Thursday, 24 February 2005 01:57:19 UTC