RE: TIBCO objects to last call (resend)

David (Hull), 
 
I am afraid that I am still a bit lost as to why there is an issue. You
claim we don't have a concrete description of how to handle another MEP
which is not covered in our WSDL binding document. 
 
We have extensibility to provide additional MEPs in WSDL 2.0  by design.
There is a nice pattern attribute (URI) that specifies the MEP in a WSDL
operation which is extensible. WSDL 2.0 provides extensibility with URIs
not only with MEPs but also for styles as well (which we have exploited
greatly in WSDL 2.0 and provided some styles of our own). It just means
that MEP is an open set, just like style and TIBCO is one of the editors
of this document ;-)

WSDL 2.0  does not define additional MEPs, but certainly HAS the
machinery to provide a reference (URI) which is going to be published by
"some other" specification.  WSDL can not define all the MEPs, but
allows additional MEPs to be referred to which will be specified by
other specification(s). 
 
Understanding a new MEP URI will let one understand how this new MEP may
require additional MAPs with WS-Addressing. I expect that when someone
publishes this new spec and the URI that "specifies" the new MEP, you
would also get information on how WS-Addressing may be used in
conjunction (if the new spec designer has done their job). We can only
define the interaction between MAPs, KNOWN WSDL MEPs and WS-Addresing
and SOAP binding(s), but I still fail to see what the Core is lacking
right now since we explicitly allow new MAPs to be defined if necessary.
We can not anticipate how many additional MAPs a new MEP may need, or
how the new MEP will utilize SOAP bindings. It is the responsibility of
the extension to define them. 
 
We can try to give some guidance in WSDL 2.0 Part 2 (Adjuncts) such that
when a new MEP is defined, it should also state that how the MEP may
interact with WS-Addressing, should describe new MAPs (as necessary),
new types of EPRs (if any),  as well as how it utilizes SOAP bindings
when WS-Addressing. Note that we are covering this ground  for the
existing WSDL MEPs in the async task force as well. I honestly do not
think that we can even give more guidance than that in Part 2 other than
pointing out that the new MEP spec is expected to provide these items
(if necessary).   It is the responsibility of the new MEP spec to define
these additional requirements as necessary.  Alternatively, we can put a
statement to the same effect in the WSDL binding document stating that
WSDL MEPs are imherently extensible (as in WSDL 2.0) and it is the
responsibility of the MEP author to specify the specific WS-Addressing
requirements. 
 
Therefore, I don't think we can provide more  guidance in the
WS-Addressing Core or SOAP binding or should do something else other
than status quo. Therefore, I really do not see it as a new issue for
the LC documents. I also observe that your arguments appear to be
analogous to requesting to abondon/redefine xs:any in XML Schema just
because you really do not know in advance what may additionally be
included to the existing content model by extensions and consequently
you may have to take additional constraints into account for
interpretating the content. AFAIK, extensions (typically with new
namespaces) define these restrictions/constraints, not xs:any.  
 
I guess I agree with Dave O and Gudge. 
 
--umit
 
 

  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] 
Sent: Thursday, Mar 24, 2005 12:58 PM
To: David Orchard
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: TIBCO objects to last call (resend)


David Orchard wrote: 

I'm not sure that there is a single correct way to specify new MEPs.  

Thus the existence of standards.  A standard that talks about composing
interactions from basic one-way messaging is explicitly playing in this
space.


Why would I want to prevent nodes from doing a variety of options isn't
clear to me.



I'm not prepared to go to more effort to prove something that I believe
in.  You think I (or somebody else) should prove the extensibility
works.  I think it's up to any issue raiser to prove there's an issue.

At this point there's a very obvious issue:  Despite repeated calls over
a period of weeks, no one has been able to produce a concrete
description of how to handle any MEP other than those described in the
WSDL binding document.  If you can't do it, I understand, not a problem.
If no one else in the group can do it either, I'm more concerned.  I
still find it hard to believe that no one here is able to produce such a
description, but the clear evidence of the last few weeks is that it's
not actually as easy as asserted.  Why else would no one have done it by
now?


  I don't think there is an issue.



I do think we now understand each other, and given that I'm not prepared
to do the work you want me to do, and you're not prepared to do the work
I want you to do, we're probably done.



I'm comfortable in taking a vote on going to LC next week.

If you're comfortable with leaving questions like "How does this spec
relate to other specs?", "How would extensibility work?" and "What does
the charter require?" open after last call, I don't suppose I can stop
you.

I'll repeat that if we do go directly to Last Call, TIBCO Software, Inc
will formally object on the basis of i054, inviting other participants
to join in the objection. TIBCO Software, Inc may also file objections
on other grounds.  We would prefer not to see this specification in last
call multiple times, and so would prefer to see issues addressed before
it enters last call the first time.  Moving to Last Call with serious
open issues raised by members of the working group seems, to us,
pointless and contrary to the intent of Last Call.






Cheers,

Dave




  _____  


From: David Hull [mailto:dmh@tibco.com] 
Sent: Thursday, March 24, 2005 11:59 AM
To: David Orchard
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: TIBCO objects to last call (resend)



David Orchard wrote: 

David,



I really do think we are coming at this from different points of view.  



I assert that extensibility exists with the existing MAPs.  I assert
this understanding the SOAP extensibility model and the lack of
constraints on re-using MAPs.

This is actually part of the problem, not the solution.

Spec A needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use <ourns:MepEndpoint> as a header for EPRs active
in our MEPs and an ourns:MepEndpoint@role attribute on the header to say
what role it's playing"

Spec B needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use <ourns:MepEndpoint> as a header for EPRs active
in our MEPs and an @role attribute in the EPR to say what role it's
playing"

Spec C needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's use whatever header names we like for EPRs active in
our MEPs and use an @ourns:isMepEndpoint attribute on the header to say
that it belongs to us"

Spec D needs to define some new MEPs.  Its committee looks at our spec
and says "EPRs are useful.  <ReplyTo> is an EPR header.  We don't know
exactly what endpoints we'll want to support and people may want to add
their own, so let's just assume that every header that's an EPR is an
endpoint active in our MEPs."

This is just the kind of interoperability nightmare that standards are
meant to prevent.  A, B, and C might play together, at the expense of
bespoke logic for each of their schemes, but D won't play nicely with
anyone.  By refusing to take on extensibility and actively inviting
people to roll their own, we invite just this sort of  scenario.




You are effectively demanding that I prove something that I believe in, 

I sure am.  I'm not inclined to share your your belief otherwise.



and you are not offering any proof that my belief is mistaken.



Do you agree with my rough assessment of the points of view and
expectations we have on burden of proof?   



Can you see why I think that you need to provide some proof that the
extensible assertion is invalid, especially given that I know you are
intimately familiar with WS-A extensibility and other forms of MEPs?



Cheers,

Dave




  _____  


From: David Hull [mailto:dmh@tibco.com] 
Sent: Thursday, March 24, 2005 11:06 AM
To: David Orchard
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: TIBCO objects to last call (resend)



There is a basic and somewhat long-standing disconnect here that I'm
still trying to understand.

To me, and I suspect you may agree, WSN and WSE are not extending MAPs
in any way.  They are simply using EPRs.  They would work equally well
if section 3 were deleted from WSA entirely.  "You can build things with
EPRs" -- a true and useful statement as far as I can tell -- is not the
same as "you can extend MAPs".  Neither is the same as the pertinent
question of "can we support MEPs beyond request/reply as easily as we
support request/reply?"

Section 3 contains specific support for request/reply and we reference
this directly in the WSDL binding document.  This creates a presumption
that specific support for MEPs is required in the MAPs.  There are
several ways to get beyond this:

1.	Remove special mention of reply and fault from the MAPs and
re-do the WSDL document accordingly.  This would show that no specific
support is needed, request/reply serving as an example.  I'm currently
leaning toward this, provided that someone will sign up to helping re-do
the WSDL binding.  I'm told -- and I'm not being facetious here -- that
it wouldn't be hard. 

2.	Provide general support in the MAPs for all kinds of endpoints
and re-do the WSDL document accordingly.  The proposals 1 and 4 we voted
on, along with a couple of others that have appeared, are aimed at this.
This would also show that no specific support is needed, request/reply
again serving as an example. 

3.	Keep the status quo, but provide specific examples of MEPs that
do not rely on the pre-defined reply and fault endpoints, then verify
that these are no harder to produce or use than the current
request/reply.  I don't think this would be optimal, but it would be
good enough.  If we want to keep the status quo, there is a burden to
prove that it will work in cases other than those it is specifically
tailored to. 

4.	Remove MAPs from WSA entirely in favor of discussing MEPs
directly in terms of EPRs, message IDs and such.  No MAPs, no MAP
extensibility issue.  Extensibility comes directly from SOAP, which we
all agree to be extensible.  Once again, request/reply serves as an
example. 

5.	Keep the status quo and make it as explicit as possible that we
have not really addressed how to cover non request/reply MEPs, and hope
no one minds.  Proposals 2 and 3 that we voted on are steps in this
direction. 


I'm frankly puzzled by the notion -- as I understand it -- that it's
enough to simply assert extensibility without providing any example of
how it would work.

David Orchard wrote: 

David,



I am sympathetic to your concerns.  I have a particular interest in
ensuring that extensibility by 3rd parties is enabled for a large
variety of scenarios.  I respect the amount of work that you have done
in articulating the concerns you have.



However, I think that you have not done the right work in this regard.
To me, the "smoking gun" for not going to last call is a scenario where
the MAPs are not extensible.  You have listed a variety of scenarios,
but you haven't proven that a single one of those cannot be covered with
WS-A + extensibility.  As you are a smart fellow, this seems surprising
to me.  



I don't think that the burden of proof should be upon people like myself
to prove that the MAPs are extensible.  I'm pretty convinced they are,
as we have used these in other specifications like WS-ReliableMessaging
and WS-Eventing, and I'm sure you have in WS-Notification.  Given that
there is existent use of WS-A in broader MEPs, I really do think that a
"smoking gun" is required to hold up last call.  



If you had provided a concrete scenario that extends the MAPs and showed
how the spec was not extensible/broken, I would be totally with you in
not going to LC.  



As it stands, your comments are specific and worthy questions, but do
not show to me anything that should prevent us from saying "Dear Larger
Community (pun on LC), we think we are done, did we goof up anywhere?".



Cheers,

Dave




  _____  


From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, March 23, 2005 4:52 PM
To: public-ws-addressing@w3.org
Cc: Mark Nottingham
Subject: TIBCO objects to last call (resend)



This message details TIBCO's reasons for objecting to the WS-Addressing
core and SOAP binding documents going to last call.  There are several
specific reasons, all of which center around the Message Addressing
Properties (hereafter referred to as MAPs), and particularly around
issues i050 and i054, which we consider to have been closed hastily.  We
have no objection to the current formulation of EPRs and indeed believe
that WS-Addressing would provide considerable value on the basis of EPRs
alone.

We have made our opposition to the current resolution of i054 known and
have formally voted against this resolution.  We are prepared to
formally object to the core and SOAP binding specifications as they
currently stand on the basis of this issue.  We also note that a new
proposed resolution for this putatively closed issue has appeared since
the vote concerning last call was taken.  

Whatever the final resolution of i050 and i054, there currently remain
significant questions as to the meaning of MAPs in the specification.
Many such questions, including those relating to the objections above,
have been raised in public discussion over the past two weeks but have
so far gone unanswered.  It is our opinion that several of these
questions are of such a nature that if there is any significant doubt
concerning them the specification is not sufficiently well-defined to be
useful.  We do not claim that none of them can be answered, and in fact
we hope that many of them can be answered quickly.  However, until they
are, we cannot consider the discussion of the specification to be
materially complete and cannot recommend putting the document out for
public comment.

These questions include

*	Whether the MAPs are considered to contain only those properties
defined in the WS-Addressing specifications or whether other
specifications may amend them 

*	If other specifications can amend this set, in what sense may it
be said to be specified by WS-Addressing 

*	Exactly how a future specification requiring endpoints beyond
the presently defined reply and fault endpoints should define these 

*	In particular whether such a specification would have to define
a new SOAP module to hold properties parallel to those defined in the
MAPs 

*	How the current definition of MAPs as mandatory properties would
apply to existing SOAP/HTTP interactions which have no notion of such
properties 

*	Whether existing specifications would need to be amended to
mention MAPs and/or their corresponding headers in order to leverage the
asynchronous request/reply pattern to which the MAPs are evidently
tailored, as suggested by the explicit mention of ReplyTo and other
headers in specifications such as WS-Transfer and WS-Enumeration 

*	What level of MAP extensibility is actually required by the
WS-Addressing charter. 

Please consider this listing as a request to open these outstanding
questions as formal issues.

While we understand and indeed share the desire of the group to get to
last call as quickly as reasonably possible, given the current state of
the specification and the discussion around it, we regret to say that we
cannot support the documents going to last call at this point, and so
must object.