W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2002

Re: A proposal for supporting property binding (SOAP and others) in WSDL

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Sun, 27 Oct 2002 20:31:06 -0500
To: Amelia A Lewis <alewis@tibco.com>
Cc: "'www-ws-desc@w3.org'" <www-ws-desc@w3.org>
Message-ID: <OF247D66E5.2E26E2D2-ON85256C5F.004F4E1D-85256C60.00083682@rchland.ibm.com>

This is quite interesting work (both the property binding and alternate 
email binding

Some comments on the property binding proposal[1]:

1) Why have you chosen xs:string for the type of the algorithm/@name 
attribute? I would
think that a QName would be preferable so as to avoid potential for name 
collision. Also,
it might be useful to replace algorithm/@name with algorithm/@xsi:type (a 
such that it could reference a schema defined type that defined the 
constraints on the
content of the algorithm element (which would be declared as abstract in 
the schema definition
and as a restriction of xs:string).

This latter approach would allow the content of the algorithm element to 
be validated
against the constraints (such as restricting the xs:pattern facet) 
stipulated in the schema 
definition of that algorithm type.

2) The use of an open-ended enum for the wsdl:*Property/@locationType 
suggests to me that rather than define this as an enum, that it be defined 
as a QName
and that the "built-in" or WSDL defined locationTypes be bound to the WSDL 
namespace. If
other bindings define their own locationTypes, then they would be bound to 
their respective

3) While having such a formal algebra for mapping the unbound abstract 
properties of
a feature is IMO, quite useful, it does not seem to me to be appropriate 
that a WSDL description
apply these for *each* binding defined in a WSDL description. I think that 
it increases the
complexity of a given wsdl:binding unnecessarily. Rather, I see this 
formal notation/algebra
as being quite useful for mapping a feature(s) to a protocol binding that 
is implied by the
choice of binding namespace (e.g. http://www.w3.org/@@@@/@@/wsdl/soap)
and the association of chosen features, by reference to their assigned 

In other words, I think that it would be useful to be able to define a 
feature and its associated
properties and property references, and then, for each defined protocol 
binding, define the
mapping/binding of the abstract features in a manner such as you have 
proposed. This need
only be defined once, and then simply referenced.


<wsdl:feature name="NCName" uri="xs:anyURI">
    <!-- enumerate the referenced set of properties used by the feature. 
These may come from multiple
    namespaces, not just the targetNamespace -->
    <wsdl:propertyRef property="QName"/>+
  <wsdl:featureBinding feature="QName" protocol="xs:anyURI">
      <wsdl:simpleProperty property="QName" locationType="QName" 
      <wsdl:complexProperty property="QName" locationType="QName" 
      <wsdl:propertyChoice property="QName" 

<!-- define the set of properties bound to the targetNamespace of this 
WSDL document -->
<wsdl:property name="NCName" type="QName">

Thus, a binding could simply reference the set of features it uses by 
the feature's URI or by its QName. The binding-specific property mapping 
is then
determined by matching the protocol URI with the value of 

Comments on the alternate email binding proposal[2]:

4) Why is the message-id property a xs:string? Seems to me that requiring 
it be a xs:anyURI
would be "a good thing(tm)" IMO. Again, this is just the property, not a 
binding location's value.
A property binding could provide an algorithm that converted the URI the 
an appropriate

maps to:
        Message-Id: <1035577985.4183.28.camel@xerom>

5) The feature for MIME composite messages should be (IMO) a realization 
of/binding to 
the SOAP1.2 Attachment Feature[3]. I believe that this (MIME Composite) 
isn't a feature as much 
as a feature-specific binding.

6) Why have you chosen to separate out the Failure Destination feature 
from the Message
Address feature? Message Address has a response-address property. Seems to 
that the fdest:failure-destination sh/could be incorporated into the set 
of address properties
and that in some cases, the failure-destination would simply be a 
reference to the response-address
property (which itself might be a (defaulted) reference to the 
original-source property).


Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

[2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0126.html
[3] http://www.w3.org/TR/soap12-af/

Amelia A Lewis wrote on 10/25/2002 04:33:05 PM:

> Heyas ...
> After doing some work to try to use the various proposed frameworks,
> I've come up with the following proposal to place on the table as well. 
> This work is based on the information in the SOAP 1.2 email binding
> proposal, which went out earlier today.  I realize that we're loading
> all youse guys down with stuff to read on your otherwise delightful
> weekends, but hey ... we had to *write* it.  So there!  *laugh*
> The attached is a proposal for defining, specifically, how a service may
> bind abstract properties within the context of a particular protocol
> binding.  Feedback and responses welcome.
> Amy!
> -- 
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
> [attachment "property-binding.html" deleted by Christopher B 
Received on Sunday, 27 October 2002 20:31:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:40 UTC