Re: Agenda, 5 June 2003 WS Desc telcon

I have reviewed Umit's proposal for an alternate approach to R085 and have 
the following comments.

1. Umit's proposal includes the case of dynamic Web services references. 
This is the case where the type of reference is not known at description 
time. The type information is sent along with the endpoint URI. This is 
beyond the scope of R085, which addresses the static case only, i.e. when 
the type of the service is known at design time. Also, the solution Umit 
proposes is a duplication of the WS-Addressing proposal [1]. The WG should 
decide how to handle the proposal. I will therefore confine my further 
remarks to the R085 case.

[1] http://www-106.ibm.com/developerworks/webservices/library/ws-add/

2. Umit's approach is motivated by a desire to "get rid of XPath" and 
replace it with an approach based on XSD. I don't fully understand why the 
WG thinks this is a good idea. XPath was specifically designed to identify 
parts of an XML instance document and so it is directly applicable to 
identify the position of endpoint URIs or other complex types that contain 
addressing information.

On the other hand, XSD was intended to define grammars for XML 
vocabularies. XSD allows an XML parser to determine if the sequence of 
characters that comprises a document is a valid instance with respect to a 
schema, e.g. a parser can determine if a sequence of characters is a valid 
URI as defined by the simple type xsd:anyURI. A parser has no way of 
telling what that URI points to. XSD does allow application specific 
information to be associated with parts of a schema by means of the 
elements xsd:annotation and xsd:appInfo, but this is not a widely used 
practice.

Umit's preferred approach is to introduce a new simple type 
wsdl:ws-reference-uri which is simply a wrapped version of xsd:anyURI. All 
endpoint URI should derive from this and define a new wrapper type for 
each WSDL interface that is referenced. Umit describes other approaches 
which I will not discuss since this is her preferred approach.
For example, suppose a service returns a reference to a service that 
implements the WSDL interface p:partInterface. In Umit's proposal we have 
the standard WSDL definition:

<xsd:simpleType name="ws-reference-uri">
    <xsd:restriction base="xsd:anyURI"/>
</xsd:simpleType>

and the service specific definition

<xsd:simpleType name="PartReference">
    <xsd:restriction base="wsdl:ws-reference-uri">
</xsd:simpleType>

In my example, the endpoint reference interface definition is:

<endpoint name="partURI" part="return" interface="tns:partInterface" 
xpath="/p:Parts/Part/@reference"/>

In Umit's proposal, the p:Part complex type is rewritten to use 
p:PartReference and the endpoint definition becomes:

<endpoint name="partURI" part="return" interface="tns:partInterface" 
type="p:PartReference"/>

3. I'd now like to focus on the differences in these approaches. 

3.1 XPath Approach

In the XPath approach there is no coupling between XSD and WSDL. The XSD 
can be written independently of the WSDL. In many organizations, the XSD 
is written first and then used in WSDL. Often, the XSD and WSDL are 
written by different individuals or departments. The XPath approach allows 
standard XSD definitions to be reused in different Web services. For 
example, a Person document could include a URI to a Department. However, 
the Web service associated with the Department might depend on the 
application, e.g. Human Resources, Real Estate, Project Management. 

The XPath approach also allows the endpoint definition to be based on 
instance data in the message. For example, suppose a Department document 
contained a list of Person elements, each containing a job code attribute 
("manager" or "employee") and a URI to a Web service for the Person. The 
following is possible with XPath but not XSD:

<endpoint name="managerURI" part="return" interface="tns:managerInterface" 
xpath="/Department/Person[@jobCode='manager']"/>
<endpoint name="employeeURI" part="return" 
interface="tns:employeeInterface" 
xpath="/Department/Person[@jobCode='employee']"/>

which allows message instances like:

<Department id="NEWS">
    <Person 
jobCode="manager">http://www.wjm-tv.com/people/LouGrant</Person>
    <Person 
jobCode="employee">http://www.wjm-tv.com/people/MaryRichards</Person>
    <Person 
jobCode="employee">http://www.wjm-tv.com/people/TedBaxter</Person>
</Department>

In this example, Lou Grant's URI implements the managerInterface, but Mary 
Richards and Ted Baxter implement the employeeInterface.

The ability to have interface depend on instance data seems very powerful. 
Is it too powerful? 

The downside is that a WSDL author and processor must understand XPath 
which is a further complication. However, XPath is a relatively simple 
syntax and XPath processors are widely available.

3.2 XSD Approach

The XSD approach couples XSD and WSDL so the messages must be defined at 
the same time as the Web service. Also, the message must reference the 
WSDL namespace to pick up the 
wsd:ws-reference-uri type. This seems unwise. WSDL should be able to 
describe services, not dictate how they are defined. This means existing 
services cannot be described. The XSD must be redefined to use 
wsdl:ws-reference-uri and the dervied types based on it. What happens when 
a new WSDL version is released? Will services have to be redeployed?

The XSD approach requires the definition of wrapper types, which is an 
additional authoring burden and which adds bulk to the description.

4. Summary

The XPath approach decouples XSD and WSDL, allows independent authoring of 
messages and services, and permits greater flexibility in Web service 
design. However, it introduces another spec, XPath, and may be too 
powerful.

The XSD approach couples XSD and WSDL, requires coordinated authoring of 
messages and services, and restricts the design of Web services. However, 
it introduces no new specs and may be good enough for 80% of the cases.

-- Arthur Ryman