rania -
while i understand the objection that you and satish have to my
thoughts, i understand. i am just worried, as i attempted to say, that
we are tailoring a syntax that serves an immature technology.
rkhalaf wrote:
> Hi Danny,
>
> Thanks for your doc.
>
> Regarding conformance, we make it very clear that there are many
> different possible conformance relations that may define them in a
> paraallel effort as you suggest - but if we have a good way to define
> a useful one that covers important cases, I think it's useful to have
> the definition there. If you look at the bottom of the doc you can see
> that one of the issues was whether to allow one to relate two
> processes together given a defined relation. This would be too early I
> think for this version but it shows the direction of the thinking.
>
> The def is not supposed to yield an algorithm directly, but to clearly
> and intuitively explain what this compliance def is checking for. The
> algorithm one may use to check "observable compliance" should not a
> brute force one from the def, and that's quite obvious to tell (you
> could have infinitely many minimum-no-fault-...-completions). Also,
> the definition is still being clarified.
>
> Also, the doc is clear that it allows many uses for abstract processes.
>
> Regarding partially defined processes as you describe them, my view is
> like I explained at the F2F - which is pretty much what Satish's
> e-mail says. I'm strongly against this because it hurts the
> usefulness of abstract processes.
>
> regards,
> Rania
>
> Danny van der Rijn wrote:
>
>> that is very close to the conclusion that i came to as well. except
>> that i would prefer that different communities be able to define
>> their own standard outside of the core spec. with conformance being
>> one of those communities. i just don't get why conformance has
>> special standing, especially given its infancy.
>>
>> Satish Thatte wrote:
>>
>>> What I heard before is that your customers want to omit anything ?
>>> which is almost like an editor?s intermediate storage
>>> representation. We don?t need to standardize that because it
>>> doesn?t need to have any semantics beyond editing.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> From: Danny van der Rijn [mailto:]
>>> Sent: Friday, September 24, 2004 12:19 PM
>>> To: Satish Thatte
>>> Cc:
>>> Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman]
>>>
>>>
>>>
>>> that's what we're doing right now, isn't it?
>>>
>>> Satish Thatte wrote:
>>>
>>> So then please describe what you have in mind so we can see the precise
>>>
>>> differences.
>>>
>>>
>>>
>>> -----Original Message-----
>>>
>>> From: Danny van der Rijn [mailto:]
>>> Sent: Friday, September 24, 2004 8:44 AM
>>>
>>> To: Satish Thatte;
>>> <mailto:>
>>>
>>> Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman]
>>>
>>>
>>>
>>> btw, the templating that was in the paper didn't really match the
>>> templating that i'm describing which is why i called it out.
>>>
>>>
>>>
>>> Danny van der Rijn wrote:
>>>
>>>
>>>
>>>
>>>
>>>> i was hoping that i misunderstood the intent. i bothered to be so
>>>> detailed so someone could point out the error in my misunderstanding.
>>>>
>>>>
>>>>
>>>> as far as a list of features, no i don't have one. they are just
>>>> omitting what they please and providing what they find to be usefully
>>>> portable. but a concrete example of that that i do know is that they
>>>> are leaving out specifics of the WSDLs. "you receive an order here,
>>>> and you send a confirmation response." that's all that you need to
>>>> know at that point. not what a line item looks like. not even what
>>>> an order looks like.
>>>>
>>>>
>>>>
>>>> Satish Thatte wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Danny,
>>>>>
>>>>>
>>>>>
>>>>> I think your description of the challenge response metaphor for
>>>>> proving conformance represents a misunderstanding of the intent
>>>>> (brute force search among lots of randomly generated possibilities
>>>>> was not the idea). Moreover, the templating case is explicitly
>>>>> supported in Rania's paper I believe. Rania and I will address that
>>>>> separately.
>>>>>
>>>>>
>>>>>
>>>>> But I am very curious about the specific details your customers would
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>> want to omit while still preserving the meaningfulness of the
>>>>> "process IP" they would be selling. Do you have a list of features
>>>>> that ought to be allowed for omission?
>>>>>
>>>>>
>>>>>
>>>>> Satish
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>>
>>>>> From: Danny van der Rijn [mailto:]
>>>>>
>>>>> Sent: Thu 9/23/2004 8:57 PM
>>>>>
>>>>> To: <mailto:>;
>>>>> <mailto:>;
>>>>>
>>>>> <mailto:>
>>>>>
>>>>> Subject: [Fwd: Re: [wsbpel] abstract process strawman]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> you don't see that every day. i remembered the attachment, but
>>>>> forgot the inline text.
>>>>>
>>>>>
>>>>>
>>>>> the enclosed document is my quick reaction to the abstract
>>>>> presentation from yesterday.
>>>>>
>>>>>
>>>>>
>>>>> -------- Original Message -------- Subject: Re: [wsbpel] abstract
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>> process strawman
>>>>> Date: Thu, 23 Sep 2004 20:52:21 -0700
>>>>> From: Danny van der Rijn <>
>>>>> <mailto:>
>>>>> <mailto:>
>>>>> To: <mailto:>
>>>>> CC:
>>>>> <mailto:>,
>>>>>
>>>>> <mailto:>
>>>>> References: <>
>>>>> <">mailto:>
>>>>> <">mailto:>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> rkhalaf wrote:
>>>>>
>>>>> Hi everyone,
>>>>> As promised, here is the abstract process strawman document I
>>>>> have been putting together. This work aspired to define a consistent
>>>>> view of abstract processes and their use as the basis for continuted
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>> discussion and concrete proposals/resolutions.
>>>>> According to the Agenda, tomorrow or Thursday will be when the
>>>>> abstract proc stuff will be discussed.
>>>>> Regards, Rania
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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/leave_workgr
>>>
>>>
>>> oup.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/leave_workgr
>>>
>>>
>>> oup.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/leave_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/leave_workgroup.php.
>>
>
>
>
>
