OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 152 - Clarification of usage of "reference-scheme"attribute of "service-ref" element


Please see below

Alex Yiu wrote:

> 
> Well ... I guess you guys won't be surprised that I prefer keeping that 
> attribute and make that attribute optional. Right? :-)
> 
> Reasons are:
> (a) As mentioned in previous emails, given the same content EII, 
> different reference schemes can treat content differently when 
> supplemented with different URI values used in that attribute. For 
> example, different treatments of wsdl:service element based on the 
> attribute.

In which case when that EPR type is added to BPEL it should be added 
with its own wrapper that provides whatever disambiguation information 
is needed.

I am especially concerned by the assumption that a single URI value may 
be sufficient to enable the desired disambiguation. I can't find a 
compelling reason to believe that in the generic case (which is all that 
we can address) a single value would be enough. For all we know a whole 
set of values may be needed.

Therefore it seems the most reasonable way forward is to tell those who 
standardize how to use a particular type of EPR in BPEL that if their 
EPR has problems in expressing its semantics that requires additional 
information then the EPR should only be used in BPEL with a wrapper that 
provides whatever additional data is required.

> (b) If we don't have this optional attribute, then we will need to 
> introduce another element to manage around the content EII.
> (E.g. 
> <bpws:service-ref><foo:bar><wsdl:service>...</wsdl:service></foo:bar></bpws:service-ref>)
> That extra wrapper seems quite unnecessary.
> 

The wrapper is only unnecessary if your assumption that all that is 
needed is a single URI is correct. But in non-trivial scenarios much 
more than a single URI may be needed and so the additional wrapper would 
be justified. I personally have trouble justifying introducing a single 
attribute with ambiguous semantics to cover a case that it looks like 
may very well require much more.

We have already defined a container, which can hold substantially richer 
semantics than an attribute, into which people can poor their EPR 
specific data, this seems more than enough to me.

> Thoughts for your consideration.
> Thanks!
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Francisco Curbera wrote:
> 
>>
>>+1
>>
>>Paco
>>
>>
>>
>>                                                                                                                                        
>>                      "Yaron Y. Goland"                                                                                                 
>>                      <ygoland@bea.com> <mailto:ygoland@bea.com>        To:       wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>                                                    
>>                                               cc:                                                                                      
>>                      07/28/2004 12:25         Subject:  Re: [wsbpel] Issue - 152 - Clarification of usage of "reference-scheme"        
>>                      PM                        attribute of "service-ref" element                                                      
>>                      Please respond to                                                                                                 
>>                      ygoland                                                                                                           
>>                                                                                                                                        
>>
>>
>>
>>
>>I'd like to propose a 3rd option - remove reference-scheme all together.
>>
>>The definition of reference-scheme and how it should be used with
>>various EPRs is ambiguous at best. I don't believe we can usefully
>>reduce the ambiguity without also becoming a lot more specific than any
>>of us want to in regards to EPRs.
>>
>>But EPR's ambiguity means that the reference-scheme's utility as a
>>generic handle onto EPRs is questionable. Therefore why don't we just
>>get rid of the reference-scheme attribute? If an EPR needs some kind of
>>higher level disambiguator then let a URI be defined as an attribute on
>>the EPR's root element by the EPR author themselves. Let's keep BPEL out
>>of it.
>>
>>                         Just a thought,
>>
>>                                     Yaron
>>
>>ws-bpel issues list editor wrote:
>>
>>  
>>
>>>This issue has been added to the wsbpel issue list. The issues list is
>>>posted as a Technical Committee document to the OASIS WSBPEL TC pages
>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular
>>>basis. The current edition, as a TC document, is the most recent version
>>>of the document entitled ** in the "Issues" folder of the WSBPEL TC
>>>document list
>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> -
>>>the next posting as a TC document will include this issue. The list
>>>editor's working copy, which will normally include an issue when it is
>>>announced, is available at this constant URL
>>><http://www.choreology.com/external/WS_BPEL_issues_list.html>.
>>>
>>>
>>>    Issue - 152 - Clarification of usage of "reference-scheme" attribute
>>>    of "service-ref" element
>>>
>>>*Status:* open
>>>*Categories:* Syntax and validation <#category_syntax_and_validation>
>>>*Date added:* 27 Jul 2004
>>>*Submitter:* Alex Yiu <mailto:alex.yiu@oracle.com>
>>>*Date submitted:* 26 July 2004
>>>*Description:* This is a follow-up issue for Issue 34, which we passed
>>>to introduce a "bpws:service-ref" element wrapper to contain details of
>>>the EPR used by partnerLink. There was some discussion on how to use the
>>>"reference-scheme" attribute of the "bpws:service-ref" wrapper element.
>>>
>>>Here are some suggested usage:
>>>
>>>(A) Keep it required as mentioned in original proposal of Issue 34:
>>>
>>>The “bpws:service-ref” has a required attribute called
>>>“reference-scheme” to denote the URI of the reference interpretation
>>>scheme of service endpoint, which is the child element of
>>>bpws:service-ref. Most likely, the URI of reference scheme will have the
>>>same value for the namespace URI of the child element of
>>>bpws:service-ref. But they are not necessarily the same.
>>>
>>>    * When the BPEL container fails to interpret the combination of the
>>>      "reference-scheme" attribute and the content element OR just the
>>>      content element alone, a standard fault
>>>      "bpws:UnsupportedReference" must be thrown.
>>>
>>>(B) Make it optional:
>>>
>>>The “bpws:service-ref” has an optional attribute called
>>>“reference-scheme” to to denote the URI of the reference interpretation
>>>scheme of service endpoint, which is the child element of
>>>    
>>>
>>bpws:service-ref.
>>  
>>
>>>Most likely, the URI of reference scheme and the namespace URI of the
>>>child element of bpws:service-ref are not necessarily the same.
>>>Typically, this optional attribute is used ONLY when the child element
>>>of the “bpws:service-ref” is ambiguous by itself. The optional attribute
>>>supplies further information to disambiguate the usage of the content.
>>>
>>>Example: different treatments of wsdl:service element
>>>
>>>    * If that attribute is not specified, use the namespace URI of the
>>>      content element within the wrapper to determine the reference
>>>      scheme of service endpoint.
>>>
>>>    * if the attribute is specified, use the URI as the reference scheme
>>>      of service endpoint and treat the content element within the
>>>      wrapper accordingly.
>>>          o When the "reference-scheme" attribute is specified, the URI
>>>            value is MOST LIKELY different from the namespace URI of the
>>>            content element for EPR.
>>>    * When the BPEL container fails to interpret the combination of the
>>>      "reference-scheme" attribute and the content element OR just the
>>>      content element alone, a standard fault
>>>      "bpws:UnsupportedReference" must be thrown.
>>>
>>>
>>>*Submitter's proposal:*
>>>
>>>I personally prefer (B) over (A).
>>>*Changes:* 27 Jul 2004 - new issue
>>>
>>>To comment on this issue, please follow-up to this announcement on the
>>>wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> list (replying to this message should
>>>automatically send your message to that list), or ensure the subject
>>>line as you send it *starts* "Issue - 152 - [anything]" or is a reply to
>>>such a message. If you want to formally propose a resolution, please
>>>start the subject line "Issue - 152 - Proposed resolution", without any
>>>Re: or similar.
>>>
>>>To add a new issue, see the issues procedures document (but the address
>>>for new issue submission is the sender of this announcement).
>>>
>>>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_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_workgroup.php
>>.
>>
>>  
>>
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]