2002/ws/desc/wsdl20 wsdl20-primer.xml,1.58,1.59 wsdl20-primer.html,1.39,1.40

Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv5663

Modified Files:
	wsdl20-primer.xml wsdl20-primer.html 
Log Message:
Further tweaked the "Multiple interfaces for the same service" section to sound more positive.

Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.58
retrieving revision 1.59
diff -C2 -d -r1.58 -r1.59
*** wsdl20-primer.xml	18 Apr 2005 08:46:40 -0000	1.58
--- wsdl20-primer.xml	18 Apr 2005 14:08:29 -0000	1.59
***************
*** 1370,1375 ****
  			</div2><div2 id="adv-multiple-docs-describing-same-service">
  				<head>Multiple Interfaces for the Same Service</head>
! 				<p>Suppose a Web service wishes to expose two different interfaces: a customer interface for its regular users, and a management interface for its operator.  WSDL 2.0 limits a wsdl:service to a single wsdl:interface, and does not provide any mechanisms to formally indicate this kind of relationship between interfaces.   How can service providers indicate a relationship between services?  Conventions outside of the WSDL 2.0 language can be used, but since they are outside of the WSDL 2.0 language (and therefore neither endorsed nor forbidden by the WSDL 2.0 specification) the WSDL 2.0 specification cannot define or standardize their semantics.  With that caveat in mind, potential strategies include:<ulist><item><p><b>Declare both interfaces in the same wsdl:description element.</b>  Although WSDL 2.0 does not ascribe any particular significance to the fact that two wsdl:services are declared within the same wsdl:description, an application or toolkit could interpret this to mean that they are related i some way.</p></item><item><p><b>Declare both interfaces in the same wsdl:targetNamespace.</b>  Again, although WSDL 2.0 does not ascribe any particular significance to the fact that two wsdl:services are declared within the same wsdl:targetNamespace, an application or toolkit could interpret this to mean that they are related in some way.
! </p></item><item><p><b>Add an extension to WSDL 2.0</b> that links together all services that are related in this way.  WSDL 2.0's open content model permits extension elements from other namespaces to appear in a WSDL 2.0 document.</p></item><item><p><b>Declare them in completely separate WSDL documents, but use the same endpoint address for both.</b>  I.e., declare a wsdl:interface and wsdl:service for the customer interface in one WSDL document, and a wsdl:interface and wsdl:service for the management interface in a different WSDL document, but use the same endpoint address for both.  (By "different WSDL document" we mean that both documents are never included or imported into the same WSDL 2.0 descriptions component.)  Although this approach may work in some circumstances, it means that the same endpoint address would be used for two different purposes, which is apt to cause confusion or ambiguity.  Furthermore, it is contrary to the Web architectural principle that different URIs should be used to idntify different Web resources. (See the Web Architecture <bibref ref="webarch"/> section on <xspecref href="http://www.w3.org/TR/webarch/#URI-collision">URI collision</xspecref>.)</p></item><item><p><b>Use inheritance to combine the customer interface and management interface</b> into a single, larger wsdl:interface.  Of course, this reduces modularity and means that the management interface becomes exposed to the customers, which is not good. </p></item></ulist></p><p>The desire to express relationships between services is also relevant to Web service versioning, discussed next.</p>
  			</div2><div2 id="adv-versioning">
  				<head>Web Service Versioning</head>
--- 1370,1375 ----
  			</div2><div2 id="adv-multiple-docs-describing-same-service">
  				<head>Multiple Interfaces for the Same Service</head>
! 				<p>Suppose a Web service wishes to expose two different interfaces: a customer interface for its regular users, and a management interface for its operator.  A wsdl:service specifies only one wsdl:interface, so to achieve the desired effect the service provider would somehow need to indicate a relationship between two services.    How can a service provider indicate a relationship between services?  Potential strategies include:<ulist><item><p><b>Declare both interfaces in the same wsdl:description element.</b>  Although WSDL 2.0 does not ascribe any particular significance to the fact that two wsdl:services are declared within the same wsdl:description, an application or toolkit could interpret this to mean that they are related in some way.</p></item><item><p><b>Declare both interfaces in the same wsdl:targetNamespace.</b>  Again, although WSDL 2.0 does not ascribe any particular significance to the fact that two wsdl:services are declared within the same wsdl:targetNamespace, an application or toolit could interpret this to mean that they are related in some way.
! </p></item><item><p><b>Add an extension to WSDL 2.0</b> that links together all services that are related in this way.  WSDL 2.0's open content model permits extension elements from other namespaces to appear in a WSDL 2.0 document.</p></item><item><p><b>Declare them in completely separate WSDL documents, but use the same endpoint address for both.</b>  I.e., declare a wsdl:interface and wsdl:service for the customer interface in one WSDL document, and a wsdl:interface and wsdl:service for the management interface in a different WSDL document, but use the same endpoint address for both.  (By "different WSDL document" we mean that both documents are never included or imported into the same WSDL 2.0 descriptions component.)  Although this approach may work in some circumstances, it means that the same endpoint address would be used for two different purposes, which is apt to cause confusion or ambiguity.  Furthermore, it is contrary to the Web architectural principle that different URIs should be used to idntify different Web resources. (See the Web Architecture <bibref ref="webarch"/> section on <xspecref href="http://www.w3.org/TR/webarch/#URI-collision">URI collision</xspecref>.)</p></item><item><p><b>Use inheritance to combine the customer interface and management interface</b> into a single, larger wsdl:interface.  Of course, this reduces modularity and means that the management interface becomes exposed to the customers, which is not good. </p></item></ulist></p><p>Bear in mind that since the above strategies step outside of the WSDL 2.0 language specifies (and are therefore neither endorsed nor forbidden by the WSDL 2.0 specification) the WSDL 2.0 specification cannot define or standardize their semantics.  </p><p>The desire to express relationships between services is also relevant to Web service versioning, discussed next.</p>
  			</div2><div2 id="adv-versioning">
  				<head>Web Service Versioning</head>

Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.39
retrieving revision 1.40
diff -C2 -d -r1.39 -r1.40
*** wsdl20-primer.html	18 Apr 2005 08:46:40 -0000	1.39
--- wsdl20-primer.html	18 Apr 2005 14:08:29 -0000	1.40
***************
*** 366,376 ****
  href="#adv-multiple-inline-schemas">Importing Schemas</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.1 <a
! href="#id5213403">Schemas in Imported Documents</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.2 <a
! href="#id5213708">Multiple Inline Schemas in One Document</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.3 <a
  href="#adv-schema-location">The schemaLocation Attribute</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.3.1
! <a href="#id5213891">Using the id Attribute to Identify Inline
  Schemas</a><br />
  &#160;&#160;&#160;&#160;7.11 <a href="#adv-rdf-mapping">Mapping to
--- 366,376 ----
  href="#adv-multiple-inline-schemas">Importing Schemas</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.1 <a
! href="#id5213392">Schemas in Imported Documents</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.2 <a
! href="#id5213696">Multiple Inline Schemas in One Document</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.3 <a
  href="#adv-schema-location">The schemaLocation Attribute</a><br />
  &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;7.10.3.1
! <a href="#id5213880">Using the id Attribute to Identify Inline
  Schemas</a><br />
  &#160;&#160;&#160;&#160;7.11 <a href="#adv-rdf-mapping">Mapping to
***************
*** 3947,3959 ****
  <p>Suppose a Web service wishes to expose two different interfaces:
  a customer interface for its regular users, and a management
! interface for its operator. WSDL 2.0 limits a wsdl:service to a
! single wsdl:interface, and does not provide any mechanisms to
! formally indicate this kind of relationship between interfaces. How
! can service providers indicate a relationship between services?
! Conventions outside of the WSDL 2.0 language can be used, but since
! they are outside of the WSDL 2.0 language (and therefore neither
! endorsed nor forbidden by the WSDL 2.0 specification) the WSDL 2.0
! specification cannot define or standardize their semantics. With
! that caveat in mind, potential strategies include:</p>
  
  <ul>
--- 3947,3955 ----
  <p>Suppose a Web service wishes to expose two different interfaces:
  a customer interface for its regular users, and a management
! interface for its operator. A wsdl:service specifies only one
! wsdl:interface, so to achieve the desired effect the service
! provider would somehow need to indicate a relationship between two
! services. How can a service provider indicate a relationship
! between services? Potential strategies include:</p>
  
  <ul>
***************
*** 4010,4013 ****
--- 4006,4014 ----
  <br />
  <br />
+ <p>Bear in mind that since the above strategies step outside of the
+ WSDL 2.0 language specifies (and are therefore neither endorsed nor
+ forbidden by the WSDL 2.0 specification) the WSDL 2.0 specification
+ cannot define or standardize their semantics.</p>
+ 
  <p>The desire to express relationships between services is also
  relevant to Web service versioning, discussed next.</p>

Received on Monday, 18 April 2005 14:08:32 UTC