wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsbpel] Issue 160 - Proposal for vote (updated Feb 14)
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpeltc <wsbpel@lists.oasis-open.org>, Diane Jordan <drj@us.ibm.com>, "Furniss, Peter" <Peter.Furniss@choreology.com>
- Date: Tue, 15 Feb 2005 11:26:23 -0800
Hi, all,
Here is the slightly updated proposal for vote.
Incorporating comments from Yaron, Chris and Frank ...
- Minor terms renaming
(suggested by Chris and Frank)
- Making syntax and text
consistent again by making syntax to validate multiple variables
(notified by Yaron)
- Spinng off sub-issue and clarify the fault data body (suggested
by Yaron): make the current issue and proposal as "160.1"
and spin off the fault body data issue as "160.2" to
track it down.
Again, a link to a XSD background supplementary note to list out more
examples
to illustrate how existing <assign>/<copy> can create data
which are
invalid to XSD.
http://lists.oasis-open.org/archives/wsbpel/200501/msg00018.html
In summary, again, explicit XML validation is needed in any serious
programming
languages which has the capability to generate new XML data and
manipulate existing XML data.
Thanks!
Regards,
Alex Yiu
|
Title: Issue 160 - Proposal Draft
Issue 160 - Proposal For Vote
Last modified: Feb 14, 2005 - 3:00pm PDT
[*** Changes are highlighted in green:
- Minor terms renaming (suggested by Chris and Frank)
- Making syntax and text consistent again by making syntax to validate multiple variables (notified by Yaron)
- Spinng off sub-issue and clarify the fault data body (suggested by Yaron)
***]
Spinning off sub issue - 160.2:
The main bulk of proposal for Issue 160 stands on its own without
concerning whether we need to define a standard fault body for this
proposal and how it looks like. However, the fault body issue has
dependencies on other issues (e.g. Issue 182). To make sure we would
not forget about coming back to address this fault body question, we
suggest to spin off a new sub-issue 160.2 to track that down. And, that
issue would have dependencies on Issue 182. And, the current issue 160
becomes 160.1.
Proposal for Issue 160.1
Rationale and Background
- Certain usage of assign operation today already
allow XML data invalid to schema to be created:
- e.g. the literal form of assign
- Data operations that violates schema validation are difficult or even impossible to catch at
static analysis in a number of cases:
- Data value cases: which are impossible to catch at static analysis time
- key/keyRef and id/idRef: for uniqueness and cross referencing
- regular expression pattern for simple type values restriction
- Structure cases: which are difficult (if not impossible) to catch at
static analysis time
- xsi:type: for example: changing (or adding or removing) an xsi:type
attribute will make a piece of data changing from valid to invalid or vice
versa
- local
element declaration: if a part of schema design is using a local
element declaration, when combined with the usage of certain XPath
pattern (e.g. "/abc//def"), it will be impossible for
static analysis to determine which schema type of <def> belongs
during static analysis
- It is a well known fact that it is way too expensive to do validation after
every single data manipulation operation (e.g. assign) at runtime. We should
NOT project this expensive and potentially empty promise in BPEL
specification.
Suggested Goals
- We believe the XML data only needs to be validated at the runtime only at certain points of BPEL
execution: e.g. message boundary or explicit validation markup
- We need allow users to specify where the schema validation points are.
- A BPEL implementation is encouraged to catch the clear cases of invalid
XML data manipulation as much as possible during static analysis.
- Here are some places where data validity checking can happen:
- message boundary: A BPEL engine MAY validate data at the message related operation in both direction
("in" and "out").
- activity boundary: A BPEL developer can choose to validate XML data at the boundary of certain activity. E.g. <assign>.
Detailed Text Changes:
WSDL Message Validation
In Section "11.3 Invoking Web Service Operations" "11.4. Providing Web Service Operations", this paragraph will be added to the end of each section:
An BPEL implementation MAY provide a
configurable mechanism to enable or disable schema validation of
incoming and outgoing messages during the execution of Web Service
related activities, e.g., receive, reply, pick, onEvent and invoke
activities. The details of configuration mechanism is out of the scope
of this specification.
New Activity for Validating XML Data
Besides the message boundary, we
would like to allow people to add explicit validation operation in BPEL.
In Section "6.2. The Structure of a Business Process":
<validate> is added to the bullet list under the heading "token "activity"
can be any of the following". And, add the following paragraph before
the pargraph of "<assign> construct generates a fault from inside
the business process":
The <validate> construct can
be used to validate the values of variables against their associated XML and WSDL data definition. The construct has a variables attribute, which points to the variables being validated. The syntax of the validate activity is:
<validate
variables="ncnames" />
At the end of Section "9.2 Variables", add the following paragraph:
Values stored in variables can be mutated
during the course of process execution. A <validate> activity
can be used explicitly to ensure that values of variables are valid
against their associated XML data definition, including XML Schema
simple type, complex type, element definition and XML definitions of WSDL parts. <validate>
activity has a variables attribute, which has a NCNAMES value. The variable attribute points to the variable being validated. The syntax of the validate activity is:
<validate
variables="ncnames" />
When one or more variables are invalid
against their correponding XML definition, a standard fault of
"bpws:invalidVariables" fault MUST be thrown.
A BPEL implementation MAY provide a mechanism to turn on / off any
explicit validation. E.g. <validate> activity.
New "validate" attribute for <Assign>
A new "validate"
attribute is suggested to be added to <assign> activity:
The syntax of <assign> in Section "6.2. The Structure of a Business Process" and "9.3 Assignment" will be changed as follow:
<assign validate="yes|no"? standard-attributes>
standard-elements
...
</assign>
At the end of Section "9.3 Assignment", add the following paragraphs:
An optional validate attribute can
be used with <assign> activity. When validateXML is set to
"yes". It can be seen as a convenient marco of a combination
of <assign> and <validate> operations. With
validate="yes", the <assign> activity will validate all the
variables, which are being modified by the <assign> activities.
E.g. variables being referenced in the to-specs.
The logic related to "validate" attribute and assignment logic is considered as one unit of
operation. If the "validate" parts of operation fail, the whole
assignment operation is considered as a failure also. When one of the
variables is invalid against its correponding XML
definition, a standard fault of "bpws:invalidVariables" fault MUST be
thrown. Please note that the default of the validateXML attribute is
"no".
A BPEL implementation MAY provide
a mechanism to turn on / off any explicit validation. E.g. validate
attribute at <assign>.
There are a number of outstanding problems in the text of Section "9.3.1. Type Compatibility in Assignment". Hopefully, Issue 51 will address those issues. http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue51
Standard Fault
Add the following fault to Appendix A:
bpws:invalidVariables
Thrown when any XML validation (implicit or explicit: e.g.
<validate> and <assign validate="yes"> activity) fails
Issue 160.2: Whether we need to define a standard fault body for "bpws:invalidVariables" fault
The main bulk of proposal for Issue 160 stands on its own without
concerning whether we need to define a standard fault body for "bpws:invalidVariables" fault and how it looks like. However, the fault body issue has
dependencies on other issues (e.g. Issue 182). To make sure we would
not forget about coming back to address this fault body question, we
suggest to spin off a new sub-issue 160.2 to track that down.
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue182
END
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]