OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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]