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