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

["Satish Thatte" <satisht@microsoft.com>]

+1
 
Since EPRs are completely opaque they will need "prior engine knowledge" of the actual EPR schemas in use to provide their semantics in any case.  We don't need to add BPEL-specific magic URIs to provide semantics to the underlying EPR schemas since they will aleady have to be meaningful outside BPEL on their own.
 
Satish

________________________________

From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Wed 7/28/2004 9:25 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 152 - Clarification of usage of "reference-scheme" attribute of "service-ref" element



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 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.