[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Fixing up extensiblity syntax in BPEL by using <annotation>pattern
If we are not matching any other specification's scheme, that I'd like to make a friendly amendmant that we call the element extension. It clearly conveys what the element is about. assaf Alex Yiu wrote: > > Hi, > > Yes, the syntax are very similar but not identical. > There is a minor difference: I do not make use of the <appinfo> wrapper. > > XSD syntax: > <annotation> > <documentation> anything goes </documentation>* > <appinfo source="URI"?> xsd:any </appinfo>* > </annotation> > > BPEL syntax: > <annotation> > <documentation> anything goes </documentation>* > xsd:any* > </annotation> > > If people have strong opinion of having similar to <appinfo>, I don't > mind adding it. > As of now, I don't see a big need of it. > > > Regards, > Alex Yiu > > > Assaf Arkin wrote: > >> If I remember correctly, the XSD syntax is: >> >> <annotation> >> <documentation> anything goes </documentation> >> <appinfo> anything goes </appinfo>? >> </annotation> >> >> All application extensions are placed in the appinfo element of the >> annotation element. >> >> Assaf >> >> Alex Yiu wrote: >> >>> >>> Hi, all, >>> >>> I would like to discuss the following issue in upcoming BPEL F2F: >>> either as a standalone issue or as a sub-issue Issue 111 or Issue 11. >>> >>> ============================================= >>> >>> >>> Fixing up extensiblity syntax in BPEL by using <annotation> >>> pattern >>> >>> >>> _*Issue Description:*_ >>> >>> Currently, we have a number of places which make uses of <xsd:any> >>> (aka extensibility or xml-data placeholder) in our BPEL language: >>> >>> 1. xsd:any to any BPEL activity and bpws:tExtensible construct: >>> e.g. <empty>, <sequence> or <flow>) >>> 2. literal form of from-spec >>> 3. query and expression language as a result of Issue 13 >>> 4. extended assign operation as a result of Issue 11.1 >>> 5. Other extensibilities: e.g. extension actvity if we pass Issue >>> 111 >>> >>> >>> Mix and matching all these extension points and xsd:any produces a >>> bunch of syntax and semantic ambiguities. Given our current >>> extension syntax, we find it very difficult to come-up a very clear >>> and easy-to-use syntax grammar. >>> >>> Since not all the people on this email list are XSD experts here, I >>> am going to illustrate those ambiguities by some samples and EBNF: >>> >>> * _Semantic ambiguity in from-spec:_ >>> E.g.: >>> <from> >>> <foo:extensionToFromSpec /> >>> <bar:literalFromData /> >>> </from> >>> >>> Here we have two elements of other namespace. One is the >>> extension of from-spec. One is the literal data for the >>> from-spec. By just looking into the syntax / parse-tree, without >>> looking into its semantics, we CANNOT tell which elements fits >>> which role!!! >>> >>> Paul Brown from FiveSight reported in a similar problem before: >>> [ See: >>> http://lists.oasis-open.org/archives/wsbpel/200410/msg00077.html >>> - item (3) ] >>> >>> * _Syntax ambiguity in <assign>_ >>> E.g.: >>> <assign> >>> <foo:transactionEnabled /> >>> <foo:xmlDataOp /> >>> <copy> >>> <from>...</from> >>> <to>...</to> >>> </copy> >>> </assign> >>> >>> Informal EBNF for assign >>> assign ::= <assign> <documentation>* *any** <targets>? <sources>? >>> ( *any* | <copy> )+ </assign> >>> >>> As a result of Issue 11.1, under <assign>, we have both an >>> extension to <assign> (i.e. <foo:transactionEnabled />) and an >>> extended xml manipulation operation (i.e. <foo:xmlDataOp />). >>> Again, by just looking into the syntax / parse-tree, we CANNOT >>> tell which elements fits which role (*xsd:any*)!!! >>> >>> [ One additional caveat is: when the above syntax is mixed with >>> source or target control links. Those source and target elements >>> will be inserted between <foo:xmlDataOp> and <copy>. This caveat >>> was discovered by Yaron. ] >>> >>> >>> These ambiguities are definitely undesirable. They are sometimes >>> even illegal or creates misleading syntax. The illegal case is known >>> as: ambiguous grammar problem. As long as we are using context-free >>> grammar (e.g. EBNF) to construct parse tree, it seems to us that we >>> cannot escape this clasical ambiguous grammar problem with our >>> current extension syntax. In the XSD world, this ambigous grammar >>> problem is known as "indeterministic content model", which is >>> illegal in XSD. >>> >>> *_Submitter's Proposal: _* >>> >>> Some of us have banged our heads to the table to try to resolve this >>> problem while keeping the same level of BPEL extensibility. >>> Finally, we think we find the solution: _to apply a syntax pattern >>> similar to <xsd:annotation> to BPEL_. >>> >>> We suggest to have a <annotation> wrapper element to clearly >>> separate the element-based extension to any Extensible BPEL >>> Construct (bpws:tExtensible). After applying <annotation> pattern, >>> the previously ambigous examples would become like the following: >>> >>> <from> >>> *<annotation> * >>> <foo:extensionToFromSpec /> >>> *</annotation>* >>> *<literal>* >>> <bar:literalFromData /> >>> *</literal>* >>> </from> >>> >>> (We also add <literal> as a separator per Paul Brown's suggestion >>> and that will allow use to use any namespace inside the <literal> >>> element.) >>> >>> <assign> >>> *<annotation>* >>> <foo:transactionEnabled /> >>> *</annotation>* >>> <foo:xmlDataOp /> >>> <copy> >>> <from>...</from> >>> <to>...</to> >>> </copy> >>> </assign> >>> >>> Now those ambigous extension entries are nicely seperated. >>> >>> Informal EBNF for assign will become: >>> annotation ::= *<annotation>* <documentation>* *any* <annotation> * >>> assign ::= <assign> *<annotation>?* <targets>? <sources>? >>> ( *any* | <copy> )+ </assign> >>> >>> >>> This will solve Issue 111 grammar as well. E.g.: >>> >>> <sequence> >>> *<annotation>* >>> <foo:extensionToSeq /> >>> *</annotation>* >>> <foo:barExtendedActivity /> >>> <invoke ... /> >>> ... >>> </sequence> >>> >>> >>> Please note that this <bpel:annotation> is VERY similarly to >>> <xsd:annotation> design pattern. Existing XSD users should have no >>> problem in learning this pattern. >>> >>> >>> >>> _*Details XSD Changes:*_ >>> >>> ----------------------------- >>> * <element name="annotation"> >>> <complexType> >>> <sequence> >>> <element ref="bpws:documentation" minOccurs="0" >>> maxOccurs="unbounded" /> >>> <any namespace="##other" processContents="lax" >>> minOccurs="0" maxOccurs="unbounded"/> >>> </sequence> >>> </complexType> >>> </element>* >>> <complexType name="tExtensibleElements"> >>> <annotation> >>> <documentation> >>> This type is extended by other component types >>> to allow elements and attributes from >>> other namespaces to be added. >>> </documentation> >>> </annotation> >>> <sequence> >>> *<element ref="bpws:annotation" minOccurs="0"/>* >>> </sequence> >>> <anyAttribute namespace="##other" processContents="lax"/> >>> </complexType> >>> ----------------------------- >>> >>> ----------------------------- >>> <group name="activity"> >>> ... >>> <choice> >>> <element name="empty" type="bpws:tEmpty"/> >>> <element name="invoke" type="bpws:tInvoke"/> >>> <element name="receive" type="bpws:tReceive"/> >>> <element name="reply" type="bpws:tReply"/> >>> <element name="assign" type="bpws:tAssign"/> >>> <element name="wait" type="bpws:tWait"/> >>> <element name="throw" type="bpws:tThrow"/> >>> <element name="rethrow" type="bpws:tRethrow"/> >>> <element name="exit" type="bpws:tTerminate"/> >>> <element name="flow" type="bpws:tFlow"/> >>> <element name="switch" type="bpws:tSwitch"/> >>> <element name="while" type="bpws:tWhile"/> >>> <element name="sequence" type="bpws:tSequence"/> >>> <element name="pick" type="bpws:tPick"/> >>> <element name="scope" type="bpws:tScope"/> >>> <element name="compensate" type="bpws:tCompensate"/> >>> * <!-- this xsd:any is for Issue 111, if we pass it --> >>> <any namespace="##other" processContents="lax" /> >>> * </choice> >>> </group> >>> ----------------------------- >>> >>> ----------------------------- >>> <complexType name="tAssign"> >>> <complexContent> >>> <extension base="bpws:tActivity"> >>> * <!-- for Issue 11.1 --> >>> <choice maxOccurs="unbounded"> >>> <element name="copy" type="bpws:tCopy" /> >>> <any namespace="##other" processContents="lax" /> >>> </choice> >>> * </extension> >>> </complexContent> >>> </complexType> >>> >>> * <element name="literal"> >>> <complexType mixed="true"> >>> <sequence> >>> <any processContents="lax" minOccurs="0" >>> maxOccurs="unbounded"/> >>> </sequence> >>> </complexType> >>> </element>* >>> ----------------------------- >>> >>> >>> ----------------------------- >>> *<!-- pre 103 --> * >>> <complexType name="tFrom"> >>> <complexContent> >>> <extension base="bpws:tExtensibleElements"> >>> <sequence> >>> <choice minOccurs="0"> >>> * <any namespace="##other" >>> processContents="lax" />* >>> <element ref="bpws:query"/> >>> <element ref="bpws:expression"/> >>> <element ref="bpws:service-ref"/> >>> *<element ref="bpws:literal" />* >>> </choice> >>> </sequence> >>> <attribute name="variable" type="NCName"/> >>> <attribute name="part" type="NCName"/> >>> <attribute name="property" type="QName"/> >>> <attribute name="partnerLink" type="NCName"/> >>> <attribute name="endpointReference" >>> type="bpws:tRoles"/> >>> <attribute name="opaque" type="bpws:tBoolean"/> >>> </extension> >>> </complexContent> >>> </complexType> >>> <element name="to"> >>> <complexType> >>> <complexContent> >>> <restriction base="bpws:tFrom"> >>> <sequence> >>> * <element ref="bpws:annotation" >>> minOccurs="0"/> * >>> <choice minOccurs="0"> >>> <element ref="bpws:query"/> >>> </choice> >>> </sequence> >>> <attribute name="opaque" type="bpws:tBoolean" >>> use="prohibited"/> >>> <attribute name="endpointReference" >>> type="bpws:tRoles" use="prohibited"/> >>> </restriction> >>> </complexContent> >>> </complexType> >>> </element> >>> ----------------------------- >>> >>> >>> ----------------------------- *<!-- post 103 -->* >>> <complexType name="tFrom" mixed="true"> >>> <sequence> >>> *<element ref="bpws:annotation" minOccurs="0"/>* >>> <choice minOccurs="0"> >>> *<any namespace="##other" processContents="lax" /> >>> <element ref="bpws:literal" /> >>> * <element ref="bpws:service-ref"/> >>> </choice> >>> </sequence> >>> <attribute name="expressionLanguage" type="anyURI"/> >>> <attribute name="variable" type="NCName"/> >>> <attribute name="property" type="QName"/> >>> <attribute name="partnerLink" type="NCName"/> >>> <attribute name="endpointReference" type="bpws:tRoles"/> >>> <attribute name="opaque" type="bpws:tBoolean"/> >>> <anyAttribute namespace="##other" processContents="lax"/> >>> </complexType> >>> >>> <element name="to"> >>> <complexType mixed="true"> >>> <sequence> >>> * <element ref="bpws:annotation" minOccurs="0"/> >>> <any namespace="##other" processContents="lax" >>> minOccurs="0" />* >>> </sequence> >>> <attribute name="queryLanguage" type="anyURI"/> >>> <attribute name="variable" type="NCName"/> >>> <attribute name="property" type="QName"/> >>> <attribute name="partnerLink" type="NCName"/> >>> <anyAttribute namespace="##other" processContents="lax"/> >>> </complexType> >>> </element> >>> ----------------------------- >>> ============================================= >>> >>> >>> >>> Thanks! >>> >>> >>> Regards, >>> Alex Yiu >>> >>> >>> >> > > >
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]