[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]