RE: [wsbpel] Issue - 152 - New Proposal to Vote

["Martin Chapman" <martin.chapman@oracle.com>]

You think it's a bug, we think it's a feature!
We are going to have to agree to disagree, but it certainly is not a
burden to implement!

Martin.

>-----Original Message-----
>From: Francisco Curbera [mailto:curbera@us.ibm.com] 
>Sent: 03 September 2004 17:38
>To: Ron Ten-Hove
>Cc: wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote
>
>
>
>
>
>
>Hi Ron,
>
>I think I understand the argument: WS-MD has an issue with how 
>it reflects (or doesn't reflect) spec version information in 
>the epr. There are many different ways to solve that problem; 
>what is not fair, I think, is to ask BPEL to patch over these 
>problems and burden every BPEL engine with this sirt of of 
>ad-hoc patches. This in my view would be nothing but a 
>(stealth) dependency on an external spec, and one of a 
>particularly unfortunate kind since it results in nothing but 
>clutter and inefficiency for every compliant implementation.
>
>Paco
>
>
>
>                                                               
>                                                               
>          
>                      Ron Ten-Hove                             
>                                                               
>          
>                      <Ronald.Ten-Hove@        To:       
>Francisco Curbera/Watson/IBM@IBMUS                             
>                
>                      Sun.COM>                 cc:       
>wsbpel@lists.oasis-open.org                                    
>                
>                                               Subject:  Re: 
>[wsbpel] Issue - 152 - New Proposal to Vote                    
>            
>                      09/02/2004 04:49                         
>                                                               
>          
>                      PM                                       
>                                                               
>          
>                                                               
>                                                               
>          
>
>
>
>
>Paco,
>
>    I'm not sure if you've seen the main argument for having 
>the reference-scheme attribute (optional or not). Suppose we 
>had a service reference like the following:
>
>    <ServiceRefType>
>       <wsdl:port name="MyNotificationPort" ...
>    </ServiceRefType>
>
>The addressing schema to apply is less than clear. If my BPEL 
>run-time is clever, it might guess that WS-Message Delivery is 
>implied, but it will be at a loss to figure out which version 
>of WS-MD to use. Also, it is reasonable to assume that other 
>specifications, trodding the same ground as WS-MD, will take a 
>similar approach, using wsdl 1.1 ports and wsdl 2.0 endpoints.
>
>    It is for these cases, where the QName of the element 
>enclosed by the <ServiceRefType> is not sufficient to resolve 
>the endpoint reference scheme in use, that the 
>reference-scheme attribute is needed.
>
>    If we adopt the proposed resolution to the issue 152 
>(below), how are we to address the above problem?
>
>Best regards,
>-Ron
>
>Francisco Curbera wrote:
>
>>
>>
>>Following up on yesterday's discussion I am proposing an alternative 
>>resolution to issue 152. The aim, as it was discussed, is to 
>eliminate 
>>unnecessary and redundant syntax:
>>
>>The "reference-scheme" attribute will be removed from the 
>>"bpws:service-ref" element wrapper. The schema definition for the 
>>wrapper will thus be changed to the following:
>>
>><xs:element name="service-ref" type= tns:ServiceRefType /> 
>><xs:complexType name="ServiceRefType">
>>    <xs:sequence>
>>        <xs:any namespace="##other" processContents="lax" 
>minOccurs="1" 
>>maxOccurs="1"/>
>>    </xs:sequence>
>></xs:complexType>
>>
>>
>>Paco
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster 
>>of
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/lea
ve_workgroup.php
.
>
>
>


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php
.




To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.