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