[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [wsbpel] Issue 111 - Proposal For Vote
Since issue 111.1 was closed at the last f2f only after a completely
unreasonable amount of discussion we need to make sure it is not reopened
w/o a very good motivation, and backed by new facts not already considered.
I don't believe this is the case here.
Paco
"Yaron Y. Goland"
<ygoland@bea.com> To: Alex Yiu <alex.yiu@oracle.com>
cc: Frank Leymann <Frank.Leymann@informatik.uni-stuttgart.de>, wsbpeltc
03/28/2005 03:05 <wsbpel@lists.oasis-open.org>
PM Subject: Re: AW: [wsbpel] Issue 111 - Proposal For Vote
Please respond to
ygoland
Alex, why don't you write up your original 111.1 proposal as it applies
to extension activities (e.g. just using a xs:any) as a separate
proposal for vote? I think we should discuss it and vote on it because I
agree with you that it is the most elegant solution to 111.
As for your new proposal, it requires us to violate our current
extension pattern. What you have done is removed the extension point at
the top of the activity's contents and moved it to the bottom. The
problem I see with this approach is that it means that any elements that
were defined for use before the standard elements would be unusable in
that position with extension activities. I don't think it is a good idea
to change the extension pattern in such an inconsistent manner.
Yaron
Alex Yiu wrote:
> Hi,
>
> After reading this proposal more closely, I guess what Yaron means might
be: the
> general optional nature of BPEL's standard attributes and standard
elements.
>
> On the other hand, I do have two other questions / suggestions:
>
> (1) _Semantic of unknown extension_:
> About "the unknown activity MUST be treated as if it were an empty
activity"...
>
> Should the child content of [other] namespace within <extensibleActivity>
be
> governed by the same set of rules from Issue 92 and 92.*? That was how I
> approach Issue 182.
>
> One more alternative semantic: if an BPEL implementation does not
recognize the
> child content within extensibleActivity, the BPEL processor MUST ALWAYS
reject
> the BPEL source code.
>
> (2) _Syntax:_
>
> Instead of
> ------------------------
>
> <extensibleActivity >
> <???:??? standard-attributes>
> standard-elements
> </???:???>
> </extensibleActivity>
>
> ------------------------
>
> Yaron, have you considered syntax:
> ------------------------
>
> <extensibleActivity /standard-attributes/>
> /standard-elements/
> <???:??? />
> </extensibleActivity>
>
> ------------------------
> ?
>
> It looks more like other activities syntax-wise. It allows us to reuse
> "tActivity" definition for standard attributes and elements.
>
> *Note:
> *
>
> * standard-attributes include anyAttributes from other NS.
> * Standard-elements includes <sources> and <targets>, but excluding
any
> element from other NS. (This is different from other activity.)
>
>
> XSD Details:
> ---------------------------
> <complexType name="tExtensibleActivityAbstractBase" abstract="true">
> <complexContent>
> <restriction base="bpws:tActivity">
> <sequence>
> <element ref="bpws:documentation" minOccurs="0"
> maxOccurs="unbounded"/>
> <any namespace="##other"
> processContents="lax" *minOccurs="0"
maxOccurs="0"*/>
> <element name="targets" type="bpws:tTargets"
minOccurs="0"/>
> <element name="sources" type="bpws:tSources"
minOccurs="0"/>
> </sequence>
> </restriction>
> </complexContent>
> </complexType>
> <complexType name="tExtensibleActivity">
> <complexContent>
> <extension base="bpws:tExtensibleActivityAbstractBase">
> <sequence>
> *<any namespace="##other" processContents="lax" />*
> </sequence>
> </extension>
> </complexContent>
> </complexType>
> ---------------------------
>
>
> *Note #2:
> *
> The extra complicated XSD design here (if we like the new syntax) and
slightly
> odd syntax details (of both Yaron's suggestion and my new syntax
suggestion) are
> caused partially by XSD limitation and partially by the issue 111.1
decision in
> March F2F, which I still tend to think it may not be the most optimal one
...
>
> If we go for the original design of Issue 111.1, the syntax details here
would
> be just: (a) add an xsd:any to "activity" group and (b) declare that
xsd:any
> must be type of "tActivity". End of definition. Simple and elegant.
>
> E.g.: (I would call it [A])
>
> <flow>
> ...
> <sequence>
> <invoke ... />
> <assign ... />
> <receive ... >
> <sources> <source linkName="L1"> </sources>
> </receive>
> ...
> </sequence>
> <sequence>
> <invoke ... />
> * <foo:myActivity>
> <targets> <target linkName="L2"> </targets>
> </foo:myActivity>
> * ...
> </sequence>
> </flow>
>
> With current 111.1 decision, the same example would become:
>
> either: (Yaron's original suggestion, I would call it [B1])
>
> <sequence>
> <invoke ... />
> * <extensibleActivity>
> <foo:myActivity>
> <targets> <target linkName="L2"> </targets>
> </foo:myActivity>
> </extensibleActivity>
> * ...
> </sequence>
>
> or: (this newer suggestion, I would call it [B2])
>
> <sequence>
> <invoke ... />
> * <extensibleActivity>
> <targets> <target linkName="L2"> </targets>
> <foo:myActivity>
> </**extensibleActivity**>
> * ...
> </sequence>
>
>
> I don't have a superstrong preference between [B1] and [B2].
> ( But, I guess I still a stronger preference for [A] ... :-) )
>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
>
> Frank Leymann wrote:
>
>>Yaron,
>>
>>why "MAY have BPEL'S standard..." instead of "MUST"?
>>
>>Do you have an example, where it doesn't make sense to have standard
>>attributes and elements for an activity?
>>
>>Gruss / Regards
>>Frank Leymann
>>
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Yaron Y. Goland [mailto:ygoland@bea.com]
>>Gesendet: Freitag, 25. März 2005 22:36
>>An: wsbpeltc
>>Betreff: [wsbpel] Issue 111 - Proposal For Vote
>>
>>111 - Extension Activities
>>
>>Proposal: Add an extensibleActivity element to hold extension activities
>>
>>Introduce Section 11.9
>>
>>New activities can be introduced for use in BPEL by placing them inside
>>of the extensibleActivity element. The contents of an extensibleActivity
>>element MUST be a single element that MAY have BPEL's
>>standard-attributes and standard-elements defined on it. If the element
>>contained within the extensibleActivity element is not recognized then
>>the unknown activity MUST be treated as if it were an empty activity. In
>>all cases however any standard-attributes or standard-elements used on
>>the contained activity MUST be treated as defined by this specification.
>>
>><extensibleActivity >
>> <???? standard-attributes>
>> standard-elements
>> </????>
>></extensibleActivity>
>>
>>Schema:
>>
>>Add to activity group:
>><element name="extensibleActivity" type="bpws:textensibleActivity"/>
>>
>>Add the following definition:
>> <complexType name="textensibleActivity">
>> <sequence>
>> <any processContents="lax"/>
>> </sequence>
>> </complexType>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]