[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [wsbpel] Issue 111 - Proposal For Vote
I agree with Alex's that whether or not the extensible activity can be ignored depends on whether the extension elements are required or not. So this is up to the mechanism we eventually define to resolve issue 92. Assuming that you can always ignore the activity contents and treat the whole thing as <empty> does not seem consistent with the notion of mandatory extensions. The syntax of the extensible activity should be aligned with other activities as much as possible of course. Finally, I don't buy Alex' XSD-centric argument for reviewing the resolution of 111.1. Let's not go there again - please. Paco Alex Yiu <alex.yiu@oracle. To: Frank Leymann <Frank.Leymann@informatik.uni-stuttgart.de> com> cc: "'wsbpeltc'" <wsbpel@lists.oasis-open.org>, Alex Yiu <alex.yiu@oracle.com> 03/26/2005 11:36 Subject: Re: AW: [wsbpel] Issue 111 - Proposal For Vote PM 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]