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

["Yaron Y. Goland" <ygoland@bea.com>]

Alex,

In my opinion this proposal requires too many assumptions. First one has 
to assume that disambiguation will need to occur above the EPR layer. 
Then one has to assume that if such a disambiguation is necessary and 
needs to occur above the EPR layer then a single attribute will be 
sufficient.

I think both assumptions are based on facts not in evidence.

I think the real test is the language we would have to put in the spec. 
It would have to read something to the effect of "Well here is this URL 
and um... well.. we really don't know what it means. It will be used in 
some undefined way to enable some undefined EPRs to somehow 
differentiate each other in some undefined manner."

In any case, I think that both of us are just repeating our arguments to 
each other. This convinces me that we are probably not going to agree 
and that the best thing to do is to just have a vote.

I would request that if you do put up a proposal for vote on this issue 
that you include the text you would like to see in the spec. Only in 
that way can we finally settle exactly what you intend the semantics of 
the attribute to be.

	Thanks,

		Yaron

Alex Yiu wrote:

> 
> 
> Hi,
>  
> Let me try to re-iterate a bit on what the optional attribute is for and
> what the extra wrapper means.
> The optional attribute can be used to provide a mechanism to denote
> different interpretations based on the same (open) content.
> 
> E.g.
> <bpws:service-ref reference-scheme="http://foo.com";>
> <wsdl:service>...</wsdl:service>
> </bpws:service-ref>
> vs
> <bpws:service-ref reference-scheme="http://bar.com";>
> <wsdl:service>...</wsdl:service>
> </bpws:service-ref>
> 
> If we don't have the optional attrbute, the same example would become:
> <bpws:service-ref>
> <foo:xyz><wsdl:service>...</wsdl:service></foo:xyz>
> </bpws:service-ref>
> vs
> <bpws:service-ref>
> <bar:xyz><wsdl:service>...</wsdl:service></bar:xyz>
> </bpws:service-ref>.
> Hence the extra wrapper is  introduced.
> 
> The wrapper approach is relatively clumsy. The decision on whether to
> use a particular disambiguating interpretation scheme will require
> people to actually change the infoset of the open content. On the other
> hand, the attribute approach just seems much simpler.  The attribute
> usage is optional. If people does not need extra disambiguation, then
> they won't bother about that attribute. And, this URI attribute pattern
> happens occurs around us a number of times already in other XML design
> also. e.g. xsd:appInfo. Unless there is a clear advantage of dropping
> the attribute (that forces users to add an extra layer of wrapper),
> let's stick with this attribute approach.
> 
> Regarding to whether a single URI is enough to provide a disambiguating
> interpretation, there might be some advanced cases that we need more
> than a URI. However, for usability, I would prefer keeping simple logic
> simple while making it possible for people to achieve complicated logics.
> 
> That is: when a single URI is enough for disambiguation, then use a URI.
> When people want to have complicated semantics on top of certain content
> (e.g. <wsdl:service>) then people can still add whatever extra content
> on top (of <wsdl:service>).
> 
> I guess we don't want concerns of advanced cases (or over-generic cases)
> kills the simplicity of the common simple cases. (And, I am still really
> wondering what are actually % of cases where a single URI is not enough.
> An concrete example would help.)
> 
> 
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Yaron Y. Goland wrote:
> 
>  > 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 
> 
>  >>>
>  >>> .
>  >>>
>  >>> 
>  >>>
>  >>
> 
>