[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 99 - Some proposed wording
+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. >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]