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


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.html#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
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]