Features issue summary

Amy's action item on summarizing the state of the features discussion.

The following is an attempt to summarize the current state of the discussion
of support for features and properties in the next version of WSDL.  It
contains a summary, a discussion of the positions presented in the summary
with examples of proposed syntax, and a list of questions offered as a
possible agenda for resolution of outstanding issues.  Since every reporter
is to some degree biased, the final section contains this reporter's current
opinions on the proposed agenda items, in the interests of clarifying where
the foregoing exposition may have fallen short.

Additions and corrections to this summary are welcome.

Summary
-------

At the last face to face, it was formally agreed that WSDL should support
features and properties (in fact, it is required that WSDL support at least
SOAP features and properties).  Some syntax was agreed upon, notably the
soap:module proposal, although it appears that soap:header was preserved
anyway.

It is generally agreed that a syntax is needed to describe concrete binding
of features and properties.  The location of these concrete bindings is
under dispute: some suggest <binding>, some suggest splitting binding into
<messageBinding> and <protocolBinding>, some suggest <service>.  Opinions
also differ on the syntax of the extensions: should they be specific to a
given feature or general (in the WSDL namespace)?  Preferred names and
content models are also disputed, with several candidates.  The suggestion
has also been made that concrete bindings belong in the <service> tree.

Several members of the working group also advocate the addition of syntax
allowing a WSDL author to require features and properties at the abstract
level (that is, inside portType).  This has been less discussed, but the
issues here are similar: what namespace?  What syntax?  Where in the tree?
And particular to this topic, if a requirement can be made in the abstract
description, is the WSDL in error if the concrete implementation does not
provide a concrete binding?

Proposals
---------

Work began following submission of a proposal by Glen Daniels.  This
proposal introduced the soap:feature element as a child of portType, and
soap:properties as a child of portType/operation, which allows the abstract
part of a WSDL to specify required features/properties.  The concrete
binding syntax proposed added soap:properties and soap:modules as children
of binding.  Child elements of these proposed elements were namespaced and
named per-feature or per-module.

A counterproposal from Amy Lewis (author of the present summary as well)
suggested that a more general solution (one not SOAP-specific) would be
preferable.  The proposed syntax was quite complex.

An informal task force then formed to discuss proposals.  The result of
these discussions was a drastically simplified syntax.  The proposed syntax
did not address the issue of feature requirements inside portType.  The
concrete syntax for binding relied on URI references to external documents,
providing a given service with the ability to further constrain properties
defined by a feature.  The basic syntax introduced was to add a wsdl:feature
element, which could appear as the child of binding or of binding/portType.
Its children were wsdl:property elements, which could carry further
constraints.

Jean-Jacques and Youenn Fablet made strong arguments in favor of
establishing a syntax for abstractly requiring features/properties.  Robin
Berjon provided several use cases for the ability to constrain the
permissible values of a property in a WSDL.

At the last face-to-face, the issue was given most of a day.  In the morning
session, it was agreed in principle that support for features, properties,
and constraints was required, at least in the concrete binding.  The
question of abstract requirements was not so cleanly resolved.  In the
afternoon session, a syntax for soap:module very similar to Glen's original
proposal was adopted, as a means of addressing known shortcomings of the
exisitng soap:header element.  Thereafter, the discussion fell apart.

The syntax proposals on the table at this point were for
soap:module/soap:feature/soap:properties and wsdl:feature/wsdl:property.  A
proposal that the wsdl:binding element be split into wsdl:messageBinding and
wsdl:protocolBinding was set forward.  As objection, it was pointed out that
a feature might bind some properties to the underlying protocol, others to a
header in the message (that is, the clean separation of message and protocol
binding might not be so clean, feature by feature).  An alternate proposal
suggested that the bindings be placed in the wsdl:service tree.

Despite revisiting the topic in teleconference since the face to face,
little further progress has since been made, so the issue currently stands
more or less as it was left at the end of the face to face meeting.
Questions are of scope (provide syntax for soap only, and let others take
care of themselves, or provide a general syntax?), of concrete binding
(where, what), and of abstract binding (whether, what, and whether it
creates a validation requirement).

Agenda
------

1. Scope
   1a. Should WSDL support only description of SOAP features and properties,
or features and properties more generally?
   1b. If only SOAP features and properties, should the namespace be the
WSDL SOAP namespace, or the WSDL namespace?
   1c. If features and properties generally, should WSDL propose a universal
syntax, or let each feature definition mandate its own?

2. Concrete Binding
   2a. Should the current <binding> tree be separated into <messageBinding>
and <protocolBinding> trees?
   2b. Should the concrete binding syntax live in <binding>,
<messageBinding>, <protocolBinding>, or <service>?
   2c. Where, exactly, in the preferred subtree may the new syntactic
elements appear?
   2d. What are the new syntactic elements?

3. Abstract Binding
   3a. Should it be possible to specify required features and/or properties
in the <portType> tree?
   3b. If so, where in the tree may these requirements appear? (portType,
operation, individual messages)
   3c. If so, should consistency checks be performed to ensure that a
binding that claims to implement a portType contains concrete bindings for
required features/properties?
   3d. What are the new syntactic elements?

Disclosure
----------

The author's current opinions on the issues listed in the agenda:

1a. Support features and properties generally.
1b. n/a
1c. Use a universal syntax, in the WSDL namespace.

2a. Don't split the binding tree.
2b. Place concrete binding in the <binding> tree.
2c. Immediate child of binding or operation, but not of individual messages.
2d. <wsdl:feature> with complex content.

3a. Probably a good idea, but not critical.
3b. Same as decided for concrete binding.
3c. Require the check, or do not implement abstract feature requirements.
3d. Use a simplified version of the concrete syntax.


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 17 January 2003 14:15:07 UTC