Per the issues process that we agreed on, during the last f2f:
A new issue will not be discussed till it is assigned a number. Once it
is assigned a number that number will be included in the subject so that
we can search for discussion on a particular issue. I would prefer that
when the issues editor assigns a number he would reply to the 'NEW
ISSUE' email with the issue number and a modified subject containing the
issue number.
Given that we haven't figured out issue mgmt (JIRA) yet, this is not
possible right now. Which is a little frustrating.
Martin: do you know if we have any resolution from the OASIS admin regd.
JIRA?
Thanks.
-Anish
--
Alex Yiu wrote:
>
> Hi, Danny,
>
> The way that I read that section is: the logic there is quite
> deterministic already:
>
> If a partnerLink can be determined as a service,
> then that is a service ...
> If _not_,
> if reference case#1, then ...
> if _not_ #1 and if #2, then ...
> if _not_ #1 or #2 and if #3, then ..
> if _not_ #1, #2, #3, then ...
>
>
> Let me give you an example. If a partnerLink is used in both invoke and
> receive activities without any logical ordering enforced in the process
> definition, _it will go into the reference case_. Because, the static
> analysis CANNOT determine the partnerLink is a service.
>
> My thought is: if different implementation come out a different
> componentType definition after static analysis of the same process, it
> sounds to me that it is more like a bug in an implementation, not the
> case of the spec being unclear. (unless you can give me a concrete
> example of our existing rules are not sufficient)
>
> And, I think if users do not want to rely on static analysis of a BPEL
> process to calculate the componentType, it may be a better idea to ask
> users to supply an explicit componentType artifact. (That is an issue
> raised by Anish.)
>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
> Danny van der Rijn wrote:
>> TARGET: SCA C+I WS-BPEL spec, General
>>
>> DESCRIPTION: Section 2.1 currently states "If a static analysis of the
>> process determines that it is possible that the first message for a
>> partner link will be received in a <receive> activity, the <onMessage>
>> element of a <pick> activity or the <onEvent> element of an event
>> handler then the partner link has a corresponding SCA service in the
>> component type."
>> I have concerns that this will leave cases where one vendor can make
>> such determination, where another vendor, with a less sophisticated
>> static analysis can not. This will leave the algorithm
>> implementation-dependent. The goal of the algorithm is to produce a
>> component type from a BPEL file in a deterministic way, with no
>> external dependencies.
>>
>>
>> PROPOSAL: none
>>
>
