[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 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]