Re: [wsbpel] Issue 160 - Proposal for vote

["Yaron Y. Goland" <ygoland@bea.com>]

The text and the syntax for the validateXML activity seem to contradict 
each other. The text says that validateXML can validate multiple 
variables at once. The syntax however only allows a single variable to 
be validated.

Also, in the case of the validateXML attribute on assign there needs to 
be some kind of fault body that can identify which variable was schema 
invalid since an assign could contain multiple copies. I suspect I will 
end up being convinced that we don't so much need to specify the actual 
message body as we need to make sure that 160 works with our resolution 
to 182.

		Yaron


Alex Yiu wrote:
> Hi all,
> 
> I am making the proposal sent out two months ago a formal proposal to vote:
> http://lists.oasis-open.org/archives/wsbpel/200412/msg00103.html
> 
> 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 short, 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
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
>       Issue 160 - Proposal For Vote
> 
> Last modified: Dec 15, 2004 - 1:00pm PDT
> 
> 
>         Rationale and Background
> 
>     * Certain usage of assign operation today already allow XML data invalid to
>       schema to be created:
>           o 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:
>           o 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
>           o 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:
>           o message boundary: A BPEL engine MAY validate data at the message
>             related operation in both direction ("in" and "out").
>           o 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":
> <validateXML> 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 <validateXML> construct can be used to validate the values of variables 
> against their associated XML data definition. The construct has a variable 
> attribute, which points to the variable being validated. The syntax of the 
> validateXML activity is:
> 
> <validateXML variable="ncname" />
> 
> 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 <validateXML> 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. <validateXML> activity has a variable attribute, which has a NCNAME 
> value. The variable attribute points to the variable being validated. The syntax 
> of the validateXML activity is:
> 
> <validateXML variable="ncname" />
> 
> When one or more variables are invalid against their correponding XML 
> definition, a standard fault of "bpws:invalidXMLData" fault MUST be thrown.
> 
> 
>         New "validateXML" attribute for <Assign>
> 
> A new "validateXML" 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 Assignement" will be changed as follow:
> 
> <assign validateXML="yes|no"? standard-attributes>
>     standard-elements
>     ...
> </assign>
> 
> At the end of  Section "9.3 Assignment", add the following paragraphs:
> 
> An optional validateXML 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 <validateXML> operations. With validateXML="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 validateXML logic and assignment logic is considered as one unit of 
> operation. If the validateXML 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:invalidXMLData" fault MUST be thrown. Please note that the default of the 
> validateXML attribute is "no".
> 
> 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:invalidXMLData
> Thrown when any XML validation (implicit or explicit: e.g. <validateXML> and 
> <assign validateXML="yes"> activity) fails
> 
> 
>       END
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.