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

["Yaron Y. Goland" <ygoland@bea.com>]

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