Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)

[Danny van der Rijn <dannyv@tibco.com>]

+1

Rania Khalaf wrote:

> Hi Alex,
>
> I think going with the second point, that it doesn't make much sense 
> to split the namespaces. Especially, as Yuzo had mentioned, that most 
> tools don't support advanced XSD features and as Danny also said if 
> there's no really compelling reason to manage several XSDs and changes 
> we should try to keep it simple.
>
> As for cut and paste, the ns decl is up top anyway, so in many cases a 
> cut and paste is just that and people will be able to copy bits with 
> opaque in them.
>
> my .02.
> rania
>
> Alex Yiu wrote:
>
>>
>> Hi all,
>>
>> I think we should still have distinct namespaces between Abstract and 
>> Executable BPEL, after most of 82.* got resolved. Major reasons are:
>>
>>     *  There are _significant amount of syntax differences_ between an
>>       Abstract Process with _opacityOmissionUsed="yes"_ and Exec
>>       Process. (I am talking about the Abstract base, not AP11 profile;
>>       essentially all compulsory element and attributes becomes 
>> optional.).
>>     * On the other hand, there are _moderate amount of syntax
>>       differences_ between an between an Abstract Process with
>>       _opacityOmissionUsed="no"_ and Exec Process. (I already capture
>>       those differences in my previous email).
>>     * I am worrying people uses _copy-and-paste and mix-and-match
>>       between Abstract and Executable BPEL_. (e.g. copying a fragment of
>>       empty <scope> from an Abstract BPEL into Exec BPEL). If we use the
>>       same namespace for both kinds of BPEL, it would be difficult for
>>       us to tell that users are doing this kind of mistakes. If we use
>>       different namespace, if people use an XML-aware tool to do such a
>>       copy-and-paste, we can detect that kind of mistakes more easily.
>>     * With both AP11 and Template profiles, I tend to forseee people
>>       would create the Executable Process based on Abstract Process with
>>       sometool help, given with constraints specified in the profile.
>>       Even when people want to create an Executable BPEL based on
>>       Abstract BPEL with just emacs/notepad. People just need to 
>> following:
>>          1. copy the BPEL file
>>          2. _make one-line of change_: changing XMLNS declaration from
>>             Abstract to Exec BPEL.
>>          3. add extra BPEL constructs for Execution Completion.
>>
>>             Having two distinct namespace will allow us to _validate the
>>             Exec BPEL code during step (3) by using XSD_. Hence, having
>>             multiple NS gives us more tool to do BPEL validation, while
>>             collapsing Abstract and Executable do not yield any user
>>             benefits.
>>
>>
>> Thanks!
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>>
>> Peter Furniss wrote:
>>
>>> I thought we said (or maybe it was just me) that we should revisit 24
>>> once we had sorted out (in 82.*) just how much difference there was
>>> between syntax e and syntax a. When issue 24 was resolved we were
>>> anticipating a quite different scale of differences.  I had to drop out
>>> of active involvement in 82 soon after that, I do think we should
>>> consider rescinding 24 (sorry Diane)
>>>
>>> Peter
>>>
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com] Sent: 22 
>>>> November 2005 16:28
>>>> To: Alex Yiu
>>>> Cc: wsbpeltc; Rania Khalaf; Danny van der Rijn; Ron Ten-Hove; 
>>>> 'Monica J. Martin'
>>>> Subject: Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)
>>>>
>>>>
>>>> Hi guys,
>>>>
>>>> If we agree about the schema of abstract will only add the opaque 
>>>> tokens then I don't see any motivation any more for 24's resolution .
>>>>
>>>> Is it really worth all the pain of xsd:redefine and managing three 
>>>> schemas instead of just saying in the text that you can only use 
>>>> abstract tokens in AP ?
>>>>
>>>> regards,
>>>> Rania
>>>>
>>>>   
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>