[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 152 - Proposal to Vote
The example only shows the contents on the any (open content), and you are right it could show a complete example. Looking at the thread I think mine and alex's treminology are in line; service-ref is the epr strucure and reference-scheme is an attribute of servive-ref. There are cases where the namespace URI of the EPR may not be the same at the uri of the referncing spec. In these cases you need the reference-scheme attribute, but it should be optional to elimiate redundancy. Martin. >-----Original Message----- >From: Yaron Y. Goland [mailto:ygoland@bea.com] >Sent: 26 August 2004 19:29 >To: Martin Chapman >Cc: 'Alex Yiu'; 'Francisco Curbera'; wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Issue - 152 - Proposal to Vote > > >The namespace URI of the EPR is the namespace on the root >element. What >purposes is served by defining it twice? > >Also, the example seems incomplete since it doesn't actually use a >reference-schema URI. I am assuming, btw, that what WS-Context is >calling reference-scheme is what Alex's proposal means by service-ref? > > Thanks, > > Yaron > >Martin Chapman wrote: > >> Here is the text from the WS-Context spec that at least carifies the >> intent for me. Does this help at all? >> >> The reference-scheme is the namespace URI for the >referenced addressing specification. For >> example, the value for WSRef defined in the >WS-MessageDelivery specification [4] would be >> http://www.w3.org/2004/04/ws-messagedelivery. >> The contents of the xs:any element contain a service >reference as defined by the referenced >> specfication. For example, a WSRef to a Context Manager >service would appear as shown in >> Figure 2. >> >> <wsdl11:service name="MyContextService" >wsmd:portType="ctx:ContextManager"> >> <wsdl11:port name="myCtxPort" >binding="ex:ctxServiceBinding"> <soapbind:address >> >location="http://example.com/wsdl-example1/impl"/> </wsdl11:port> >> </wsdl11:service> >> >> Figure 2, WSRef to a Context Manager service. >> >> >>>-----Original Message----- >>>From: Yaron Y. Goland [mailto:ygoland@bea.com] >>>Sent: 13 August 2004 18:44 >>>To: Alex Yiu >>>Cc: Francisco Curbera; wsbpel@lists.oasis-open.org >>>Subject: Re: [wsbpel] Issue - 152 - Proposal to Vote >>> >>> >>>Alex, >>> >>>I am not a XML schema expert so I apologize in advance if my >>>understanding of the source attribute on the appinfo element >is wrong. >>>But in so far as I understand matters the source attribute >is used to >>>provide a pointer to a definition of additional information >regarding >>>the semantics of the content in the appinfo element. But the source >>>attribute has absolutely no affect on the processing of the appinfo >>>element what so ever. >>> >>>As explicitly defined in section 3.13.1 of XML Schema Part: >1 "In both >>>cases, provision is made for an optional URI reference to >>>supplement the >>>local information, as the value of the source attribute of the >>>respective element information items. ***·Validation· does >not involve >>>dereferencing these URIs, when present.***" (emphasis mine) >>> >>>In other words, the source attribute is purely informative and has >>>absolutely no affect on the processing of the schema. The same >>>cannot be >>>said for the service-ref attribute. >>> >>>I therefore do not believe that this example provides a precedent for >>>service-ref. >>> >>>Similarly I cannot find any examples, use cases or arguments >>>made in the >>>current proposal demonstrating that service-ref is A) >Necessary and B) >>>Sufficient. So I'm confused by your assertion below that such >>>arguments >>>have been made. >>> >>>In any case what I think we can agree on is that we are probably not >>>going to agree on this topic. Therefore I would propose that we move >>>this issue to a vote with three options: >>> >>>A) Keep the service-ref attribute as mandatory >>>B) Make the service-ref attribute optional >>>C) Remove the service-ref attribute all together >>> >>>Work for you? >>> >>> Thanks, >>> >>> Yaron >>> >>>Alex Yiu wrote: >>> >>> >>>>Hi, >>>> >>>>Just one brief reply for consideration: >>>>This similar pattern design already exists in XSD schema language. >>>>=========================== <appinfo >>>> source = anyURI >>>> >>> >>><http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.h >>>tml#anyURI>> >>> >>>>/ Content: /(/{any}/)* >>>></appinfo> >>>>=========================== >>>>[3.13.2 XML Representation of Annotation Schema Components] >>>> >>>>One can consider both the child content and URI attribute value of >>>><service-ref> together as one unit of open content. >>>> >>>>In the WSDL 1.1 or 2.0, (implicit) extensible attributes >are allowed >>>>everywhere. >>>> >>>>IMHO, the option (B) proposal text already has said much more on how >>>>to >>>>handle and interpret the URI attribute and the child >>> >>>content, compared >>> >>>>with XSD and WSDL. >>>>(Of course, you may say "XML Schema sucks". ;-) ) >>>> >>>>Thanks! >>>> >>>> >>>>Regards, >>>>Alex Yiu >>>> >>>> >>>>Yaron Y. Goland wrote: >>>> >>>> >>>>>Please see below >>>>> >>>>>Alex Yiu wrote: >>>>> >>>>> >>>>>>Option (B) : Make the "reference-scheme" attribute of of >>>>>>"service-ref" element 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. >>>>>> >>>>> >>>>>What is a reference interpretation scheme? I've never heard >>> >>>of such a >>> >>>>>term. I did a Google search and all that came up was your original >>>>>posting on the issue. >>>>> >>>>> >>>>>>Both the child element and optional "reference" URI >constitutes the >>>>>>open content of "service-ref". The semantics is just like other >>>>>>open-content model (e.g >>> >>>XML Schema). >>> >>>>>An open content model as used in the context of XML means >>> >>>the ability >>> >>>>>to insert new elements into an XML instance without having >>> >>>to change >>> >>>>>the schema. Schemas that use an open content model have >>> >>>well defined >>> >>>>>rules for how to ignore the additional elements. XML Schema >>> >>>does not >>> >>>>>have an open content model. This has caused enormous >>> >>>problems and is >>> >>>>>an issue I recently addressed on my blog - >>>>><http://www.goland.org/Tech/xmlschemabackwardscompat.htm>. >>>>> >>>>>What you are proposing, as near as I can understand it, seems >>>>>unrelated to the concepts of an open content model. >>>>> >>>>>Could you please define exactly what you mean by open >>> >>>content in this >>> >>>>>context? >>>>> >>>>> >>>>>>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. >>> >>>>>Can you supply evidence that in the vast majority of cases >a single >>>>>URI will be sufficient to provide the disambiguation you >>> >>>request here? >>> >>>>>Can you supply evidence that in the vast majority of cases such >>>>>disambiguation is even necessary? >>>>> >>>>> >>>>>>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. >>>>> >>>>> >>>>>Essentially what the reference-scheme ends up meaning is "Whatever >>>>>the >>>>>semantics are that are associated with the root element of the EPR >>>>>override them in some undefined way with this single URL." >>>>> >>>>>Given that the BPEL spec cannot say anything useful about what the >>>>>semantics of the URL are and how it relates to the EPR I >>> >>>don't see any >>> >>>>>compelling reason to include the attribute in our EPR >>> >>>description. The >>> >>>>>attribute is just magic, it has no semantics on its own other than >>>>>somehow, in a completely undefined way, redefining the >>> >>>EPR's meaning. >>> >>>>>The whole point of agreeing to make EPRs opaque was to keep >>> >>>the magic >>> >>>>>out of BPEL. We just say 'EPRs go here' and no more. This attribute >>>>>violates that agreement. Either EPRs are opaque or they are not. I >>>>>believe they should be opaque and I believe that requires >>> >>>removing the >>> >>>>>attribute. >>>>> >>>>> >>>>> >>>>>> * 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. >>>>>> >>>>> >>>>>Even this requirement cannot be fully supported. After all, >>> >>>given the >>> >>>>>completely undefined semantics of the attribute it is certainly >>>>>possible that the attribute by itself may provide enough >>> >>>information >>> >>>>>that a BPEL engine could process the rest of the EPR without >>>>>understanding the EPR's elements elements. For example, the >>> >>>URL could >>> >>>>>have an EPR embedded inside of it. That is the kind of magic the >>>>>attribute opens up and this is the kind of magic I think we >>> >>>shouldn't >>> >>>>>have in BPEL. >>>>> >>>>>I'm sorry Alex but your proposal uses terms I either don't >recognize >>>>>or don't understand in this context and involves semantics >>> >>>that range >>> >>>>>between unproven (as in is disambiguation necessary and if >>> >>>so is one >>> >>>>>attribute enough?) to undefined (the exact relationship between the >>>>>attribute and the EPR). >>>>> >>>>>I look forward to reading your clarification on the meaning of the >>>>>terms used above that I didn't recognize. Perhaps that will >>> >>>provide me >>> >>>>>with the understanding I need to support your proposal. But >>> >>>for now I >>> >>>>>move that we remove the reference-scheme attribute from BPEL all >>>>>together. >>>>> >>>>> Thanks, >>>>> >>>>> Yaron >>>> >>>> >>>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/lea >> >> ve_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/lea ve_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]