Re: [wsbpel] Issue - 99 - Some proposed wording

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

+1

Alex Yiu wrote:

> 
> Hi all,
> 
> I am again thinking out loud here ... :-)
> 
> If we want to have a good schema validation of Abstract Process vs 
> Executable Process, we may  want to have have different two different 
> QNAMEs or two different namespace for Abstract vs Executeable Process. 
> (That is basically issue 24).
> 
> Judging from one of emails from Satish on Issue 24,
> (http://lists.oasis-open.org/archives/wsbpel/200312/msg00140.html)
> I guess he also prefers having two namespaces.
> 
> If we have two different namespaces, Yaron's three-value attribute of 
> abstractProcess will be reduced back to a two-value / boolean attribute. 
> Here is a suggestion:
> fragment="yes"|"*no*" or  complete="*yes*"|"no"
> 
> Issue 24 execution has been in the "kitchen" sink for a while. I would 
> suggest the editing subgroup (including myself) to make a small 
> incremental change first to the spec in the coming few weeks to reflect 
> the desire of having two namespaces.
> 
> After voting on issue 99, 107 and etc, we will work the remaining 
> details for Issue 24, i.e. separating those 2 schemas while keeping some 
> linkage in using XML Schema construct.
> 
> 
> What do you guys think?
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> Yaron Y. Goland wrote:
> 
>> I am thinking of putting the following up for vote as a resolution to 
>> issue 99. What do y'all think?
>>
>>     Yaron
>>
>> The introductory sentence in section 15 shall be amended to read 
>> "These are extensions for the business protocol usage pattern."
>>
>> The following text or a variant adopted at the discretion of the 
>> editor's group which only differs in non-normative ways where changes 
>> are made for editorial purposes shall be inserted into section 15:
>>
>> ------------------------------
>>
>> 15.X Abstract Process Fragments
>>
>> An abstract process that chooses not to specify how it is initiated is 
>> referred to as an abstract process fragment. An abstract process 
>> fragment follows all the same syntactic and semantic rules as other 
>> abstract processes with the exception that they do not specify how 
>> they are initiated and therefore do not contain start activities. An 
>> abstract process fragment MUST set the value of the abstractProcess 
>> attribute on the process element to 'abstactFragment'. If an abstract 
>> process does not contain start activities and the abstractProcess 
>> attribute value is not set to 'abstractFragment' then the abstract 
>> process definition is invalid.
>>
>> ------------------------------
>>
>> The first reference to the abstractProcess attribute in section 6.2 
>> shall be amended to include the option 'abstractFragment'. The second 
>> reference shall be amended to read 'This attribute specifies whether 
>> the process being defined is abstract, an abstract fragment or 
>> executable. The default for this attribute is "no".'
>>
>> The definition of the abstractProcess attribute in the schema shall be 
>> changed so as to allow for the values of 'yes', 'no' and 
>> 'abstractFragment'.
>>
>> 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. 
>>
>>
>