RE: [wsbpel] Issue - 111 - Proposal For Vote

Hi Alex,

I realized that the schema suggestion was the same as empty. However the intent is different and can rely on the same extensibility we have for tExtensibleElements to add additional elements and attributes. One core issue I see for 111 to address is that we need to add to the activity <choice> group something that can be recognized directly as an activity. So places where an activity is required this extensibleActivity would be directly recognized. Otherwise you can already put any extension you want in the BPEL and as long as under 92.* guidelines you know what it is and it is an activity you can process it.

I am not sure about your design restriction “global attribute” declaration comment. Maybe you could provide an example.

Regards,

Chris

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, May 25, 2005 11:22 PM
To: chris.keller@active-endpoints.com
Cc: ygoland@bea.com; 'wsbpeltc'; Alex Yiu
Subject: Re: [wsbpel] Issue - 111 - Proposal For Vote

Hi Chris,

+1 to your reminder of adding Frank Leymann's suggestion as well.

Maybe, I can provide another potentially friendly amendent to address Frank Leyman's concern. Just a simple change from "MAY" to "MUST" can be misunderstood (as those optional element MUST be used).

FROM:
------------------------------------
The contents of an extensibleActivity element MUST be a single element that MAY have BPEL's standard-attributes and standard-elements defined on it.
------------------------------------

TO:
------------------------------------
The contents of an <extensionActivityWrapper> element MUST be a single element that MUST be compatible with the syntax of a BPEL activity, which has optional standard-attributes and standard-elements defined on.
------------------------------------

Chris, I hope that is good enough to you. :-)

BTW, regarding to your XSD suggestion, there may be a few of things that will not work. Because, the complex type extension your mentioned is actually a "NO-OP" extension. That is:
<element name="extensibleActivity" type="bpws:tExtensibleActivity"/>
is effectively equivalent to:
<element name="extensibleActivity" type="bpws:tActivity"/>

That is: <extensibleActivity> is EXACTLY like <empty> but with just another element name.

That means it does not allow people to add any new sub-elements or attributes under "extensibleActivity". That will give us a lot of restriction in terms of syntax design. Particularly, we may be forced to use global attribute declaration.

Thanks!

Regards,
Alex Yiu

Chris Keller wrote:

Hi Yaron,

I like Frank Leymann's suggestion of changing the MAY to MUST in "MAY have

BPEL's standard...".  Couldn't we enforce that with a schema definition like

the following?

<element name="extensibleActivity" type="bpws:tExtensibleActivity"/>

<complexType name="tExtensibleActivity">

   <complexContent>

       <extension base="bpws:tActivity"/>

   </complexContent>

</complexType>

And then based on the 92.* rules you can either process the contents of the

extensible activity or you can't.

- Chris

-----Original Message-----

From: Yaron Y. Goland [mailto:ygoland@bea.com]

Sent: Wednesday, May 25, 2005 3:27 PM

To: wsbpeltc

Subject: [wsbpel] Issue - 111 - Proposal For Vote

I re-raise my original proposal -

http://lists.oasis-open.org/archives/wsbpel/200503/msg00188.html

               Yaron

---------------------------------------------------------------------

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

---------------------------------------------------------------------

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

wsbpel message