As to removing support for WSDL 2.0 from binding.ws

I understand that voting on a resolution was deferred on my behalf. 
For that, I that I must send out a thank you.

Having reviewed the assembly specification, the java specifications,
and the policy specification with respect to "remotable", and conferred
with my colleagues on the various TCs, I am satisfied with where the
bindings specification is now.  I'm also satisfied with the notion of
removing all references to WSDL 2.0 from the binding.ws specification.

Laurent mentions to me that in the call of last week, there was at
least one person that was insistent that "remotable" implies "maps to
WSDL portType".  (I've omitted names, in part because this knowledge is
hearsay, and therefore probably somewhat inaccurate, and also leaves
open the possibility that others might concur).

My review of the specifications does not show any such implication.  To
slightly oversimplify, my reading of the assembly spec is that an
interface is remotable if the interface says it is.  On top of that,
there is no stated expectation, normative or not, that any given
remotable interface can actual map to WSDL, either WSDL 1.1 or WSDL
2.0.  (If I've read the specs incorrectly, please advise.)

In case the implications of this are not clear, this means that it is
possible to define remotable interfaces that don't necessarily map to
WSDL - and consequently, although they are remotable, they probably
cannot be used with binding.ws.  Some examples that immediately occur
to me:

  
interface.java-rmi

  
interface.wsdl20

  
interface.rest

Now, not "mapping" to WSDL could be considered a somewhat squishy
limitation, in that it is at least always theoretically possible to add
arbitrary extension elements to WSDL 1.1 and have any number of
transformations, mappings, and whatnot implied such that you could at
least claim that a WSDL 1.1 mapping exists.  However, in the case of
WSDL 2.0, at least, it is pretty clear to me that WSDL 2.0 has
standardized some notions (particularly MEPs) that simply are not
standard with WSDL 1.1.  Forcing such an extension back into the WSDL
1.1 space is manifestly silly, given the availability of a perfectly
good replacement standard.  More generally, one point of using a new
"interface" description is most valuable precisely at the point where
that new interface description introduces new aspects that do not map
cleanly, or at all, to existing WSDL 1.1.

This limitation of the current specifications, that a remotable
interface may not map to WSDL 1.1, cleanly, if at all, seems very much
like a feature of the specifications.  My take is that interface
mapping of any kind to a transport - which also must map back to an
implementation of that interface in an arbitrary programming language,
is generally a complex problem with no easy solutions.  In other words,
it is a space ripe for vendor enhancement, and is premature for
standardization.

That's my perspective, and puts the context behind why I'm willing to
simply remove WSDL 2.0 support from binding.ws.

-Eric.

P.S. - My pet peeve of the Java to XML binding space, for example, is
that in Java, it is legal to have characters in a Java String object
that cannot legally be serialized to XML.  It is possible to define an
additional escaping mechanism that enables expressing the illegal
characters, but those escaping mechanisms are not standardized.  So
even in the space where we think the "mapping" problem has been
addressed, there are some subtle differences between "interface.java"
that happens to be remotable and maps to WSDL, and "interface.wsdl",
which clearly can work with binding.ws with no issues.  And yes, TIBCO
has definitely had customers that have run into these kinds of
limitations in a non-SCA context.