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

Amy,

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

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 
QName)
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 
attribute
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
namespaces.

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 
URI.

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.

e.g.

<wsdl:feature name="NCName" uri="xs:anyURI">
  <wsdl:documentation>burble</wsdl:documentation>?
  <wsdl:properties>
    <!-- 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:properties>
  <wsdl:featureBinding feature="QName" protocol="xs:anyURI">
    <choice>
      <wsdl:simpleProperty property="QName" locationType="QName" 
        use="required|optional|prohibited">location</wsdl:simpleProperty>
      <wsdl:complexProperty property="QName" locationType="QName" 
        use="required|optional|prohibited">location</wsdl:complexProperty>
      <wsdl:propertyChoice property="QName" 
use="required|optional|prohibited">
        <choice>
          <wsdl:simpleProperty/>
          <wsdl:complexProperty/>
        </choice>+
      </wsdl:propertyChoice>
    </choice>+
  </wsdl:featureBinding>+
</wsdl:feature>+

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

Thus, a binding could simply reference the set of features it uses by 
either
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 
wsdl:featureBinding/@protocol.

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
representation.

e.g. 
        mid:1035577985.4183.28.camel@xerom
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 
me
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).

Cheers,

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

[1] 
http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/att-0128/01-property-binding.html__charset_ISO-8859-1
[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 
Ferris/Waltham/IBM]