W3C home > Mailing lists > Public > public-ws-pnf-tf@w3.org > February 2003

Concrete syntax proposal [Was: Re: Description of scenarios]

From: Amelia A. Lewis <alewis@tibco.com>
Date: Wed, 26 Feb 2003 16:09:23 -0500
To: "Amelia A. Lewis" <alewis@tibco.com>
Cc: gdaniels@macromedia.com, public-ws-pnf-tf@w3.org
Message-Id: <20030226160923.7741a3a5.alewis@tibco.com>

Following up to myself.

Here's some WSDL 1.1-style pseudo-schema stuff, for discussion.

<wsdl:feature uri="anyURI" required="boolean" />

<wsdl:property uri="anyURI" required="boolean" />

<wsdl:propertyValue uri="anyURI">list of string</wsdl:propertyValue>

<wsdl:propertyConstraint uri="anyURI">QName</wsdl:propertyConstraint>

Using the attribute-normal form more common in WSDL 1.1 and 1.2, the text nodes in propertyConstraint and propertyValue could be replaced with "value" and "type" attributes.  Or "property" could be generalized:

<wsdl:property uri="anyURI" required="boolean"? type="QName"? value="list of string"? />

The additional constraint, not easy (not possible?) to express in schema: only one of the three attributes required, type, and value may appear.

Note that the list of string for value is a convenience, such that simple enumerations are possible without creating a type to do it, since this is likely to be a common case.  If the convenience is unwanted, then it could be a simple string instead (although it would actually be an anySimpleType, possibly).

These would be placed as follows:

<wsdl:portType>
  <wsdl:feature />*
  <wsdl:property />*
  <wsdl:propertyValue />*
  <wsdl:propertyConstraint />*
  <wsdl:operation>
    <wsdl:feature />*
    <wsdl:property />*
    <wsdl:propertyValue />*
    <wsdl:propertyConstraint />*
  </wsdl:operation>*
</wsdl:portType>

<wsdl:binding>
  <wsdl:feature />*
  <wsdl:property />*
  <wsdl:propertyValue />*
  <wsdl:propertyConstraint />*
  <wsdl:operation>
    <wsdl:feature />*
    <wsdl:property />*
    <wsdl:propertyValue />*
    <wsdl:propertyConstraint />*
  </wsdl:operation>*
</wsdl:binding>

<wsdl:service>
  <wsdl:port>
    <wsdl:feature />*
    <wsdl:property />*
    <wsdl:propertyValue />*
    <wsdl:propertyConstraint />*
  </wsdl:port>
</wsdl:service>

Possibly feature, and property if it only has the "required" attribute, should be restricted to the abstract hierarchy?  If so, possibly propertyValue and propertyConstraint (or the type and value attributes of property) might be restricted to appear only in binding and service/port?  And would it be useful to have elements in service, at a level above port?

Amy!
On Wed, 26 Feb 2003 14:53:15 -0500
"Amelia A. Lewis" <alewis@tibco.com> wrote:

> 
> Glen,
> 
> This looks pretty good.  I like the description of how a feature as a whole is required.  I do have some questions, though.
> 
> 1) Suppose that a feature contains a number of properties, and the WSDL author wants to express the fact that a certain property is required?  There is no coordination showing here between the feature element and the propertyValue element.  That's fine, but isn't it possible to require a property?
> 
> 2) Is it possible to show propertyConstraint as well as propertyValue?
> 
> 3) In general, I'd really like to see the whole proposed syntax, and then the examples of use.
> 
> Amy!
> On Wed, 26 Feb 2003 11:54:55 -0500
> Glen Daniels <gdaniels@macromedia.com> wrote:
> 
> > 
> > 
> > Here are descriptions/quick notes of the scenarios we decided to introduce on Monday at the F2F.  If folks could take these and perhaps expand on them a bit, that would be great.  The syntax proposed is simply meant to be illustrative.
> > 
> > I. Security feature
> > 
> > This example illustrates an "on/off" feature which has no explicit properties.  We simply want to indicate that security (either in binding form or via a SOAP module) is either required or offered.
> > 
> > A simple way to do this for a required feature might be as follows:
> > 
> > <wsdl:feature uri="http://example.com/secure-channel/" required="true"/>
> > 
> > This abstractly states "the secure-channel feature must be engaged".  It could live in a <portType>, a particular <operation>, a <service>, or even an <input>/<output>.
> > 
> > It is up to the software doing the actual interaction to determine how such an abstract feature requirement will be met.  As an example, if the SOAP underlying transport binding in use is HTTPS, the binding specification may specify that it natively provides the "secure-channel" feature.  The software would know this (since one would assume they implemented the binding from the spec), and realize the requirement was met.  Alternately, the service may indicate that a SOAP module is available via something like this:
> > 
> > <soap:module uri="http://example.com/modules/SOAPSecureChannel"/>
> > 
> > Again, if the software at the client had an implementation of this module around, it would know that the module implemented the desired feature and realize the requirement was satisfied.
> > 
> > II. WebMethod feature
> > 
> > This is an almost trivial example of setting a property associated with a feature.  We use the SOAP 1.2 WebMethod feature, and probably specify the value for the "Method" property like this:
> > 
> > <propertyValue uri="http://www.w3.org/2002/12/soap/features/web-method/Method">
> >   GET
> > </propertyValue>
> > 
> > This could be in the <portType>, in an <operation>, or inside a <service> or <binding>.  The SOAP HTTP binding automatically provides the WebMethod feature, and would use the value described above to determine what method to send down the wire.
> > 
> > A SOAP-specific version of this might look like this:
> > 
> > <soap:binding>
> >   <soap:webMethod>GET</soap:webMethod>
> >   ...
> > 
> > One of the bonuses to doing it with explicit features/properties outside the SOAP binding is that other WSDL bindings (i.e. the WSDL HTTP binding) could use the same property to indicate which HTTP method should be used.  Along those same lines, expressing it as a property in a standard "bag" of URI-tagged values allows any other feature/extension to refer to the value in a standard way, without needing to know the specific WSDL binding (i.e. <soap:webMethod>).  As feature specs proliferate, it is better to have one way to refer to the properties (which incidentally matches the way they are defined in the specs, by URI) than a separate WSDL extensibility element for each new spec.
> > 
> > How's that for starters?
> > 
> > --Glen
> > 
> 
> 
> -- 
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Wednesday, 26 February 2003 16:09:51 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:44 GMT