RE: [wsbpel] Issue - 152 - Proposal to Vote

["Martin Chapman" <martin.chapman@oracle.com>]

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.