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




Both the child element and optional "reference" URI constitutes the open 
content of "service-ref".
Very clear. Very simple. It is just like other open-content model (e.g. 
XML Schema itself).
No twists and turns. No undefined semantics.

:-)

I think the current text (option B) in the issue description is quite 
clear already.
Still, I would send out an email later as a formal proposal to vote.


Regards,
Alex Yiu


Yaron Y. Goland wrote:

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