[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New sub-issue 111.1: Fixing up extensibility syntax in BPEL by using <annotation> pattern
The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.
Status: open
Date added: 4 Mar 2005
Date split: 4
March 2005
Categories: Syntax
and validation
Submitter: Alex Yiu
Champion: Alex Yiu
Document: BPEL
specification
Description:
Currently, we have a number of places which make uses of <xsd:any> (aka extensibility or xml-data placeholder) in our BPEL language:
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 classical ambiguous grammar problem with our current extension syntax. In the XSD world, this ambiguous grammar problem is known as "indeterministic content model", which is illegal in XSD.
Proposed Solution:
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 ambiguous 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 ambiguous extension entries are nicely separated.
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>
-----------------------------
Changes: 4 Mar 2005 - new issue
Best Regards,
Tony
|
|
Tony Fletcher Technical Advisor
| |
|
Phone:
|
+44 (0) 1473 729537 | |
|
Mobile:
|
+44
(0) 7801 948219 | |
|
Fax:
|
+44 (0) 870 7390077 | |
|
Web: |
||
|
Cohesions™ | ||
|
Business transaction management software for application
coordination | ||
|
Work: tony.fletcher@choreology.com | ||
|
Home: amfletcher@iee.org | ||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
