[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
why do we need this extra wrapper with open content? ________________________________ From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Wed 7/28/2004 4:25 PM To: Francisco Curbera Cc: ygoland@bea.com; wsbpel@lists.oasis-open.org; Alex Yiu Subject: Re: [wsbpel] Issue - 152 - Clarification of usage of "reference-scheme" attribute of "service-ref" element 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. (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. 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 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> <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> <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> <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> <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 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]