Issue - 160 - facilities to define XML schema validation boundary

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list. 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.

Issue - 160 - facilities to define XML schema validation boundary

Status: open
Categories: Syntax and validation
Date added: 10 Aug 2004
Submitter: Alex Yiu
Date submitted: 7 August 2004
Description:

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
      
    • xsd:any: for example:  if a part of schema design is using xsd:any (very common pattern), when combined with the usage of certain XPath pattern (e.g. "/abc//def"), it will be difficult 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 executiion: 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 during static analysis. e.g.:
     <from>$fooVar/foo:xyz</from> <to>$barVar/bar:abc</to>
  If deduced types of "foo:xyz" and "bar:abc" are not compatible, a BPEL can report errors / warnings during static analysis.
  

Potential Solution:

How to determine whether a variable should be validated

• Here are the suggested rules for data validity checking:
  
  • message boundary: A BPEL engine needs to validate data at the message related operation in both direction ("in" and "out"). For example, receive/invoke/reply/pick/onEvent activties.
    • This rule is derived from (Internal Work Draft) W3C XQuery-Update Requirement:  An implementation MUST provide a mechanism to enforce schema validity at transactional boundaries.
      
    • This validation can be relaxed or disabled upon configuration / deployment option (see below).
      
  • language boundary:  (e.g. from-spec / to-spec)
    
    • If the language can handle "schema-less" data (e.g. XPath 1.0) only, a BPEL engine is NOT required to perform validation on data passed-in and passed-out from that langauge.
      
    • If the language can handle "schema-ful" data (e.g. XQuery), the definition of the schema validation semantics on the language boundary is out of this particular TC scope.   

Deployment Configuration Option

An implementation MAY provide a 
deployment or configuration mechanism to disable and relax the schema 
validation. The deployment configuration mechanism is out of the scope of this 
TC. (This mirrors a similar feature described in XQuery-Update Requirements 
Draft).

New Activity for Validating XML Data

Besides the message boundary, we 
would like to allow people to add explicit validation operation in BPEL.  
(This mirrors  a similar feature described in XQuery-Update Requirements 
Draft).

<validateXML 
variables="ncnames" /> 

"variables" attribute is a list of 
ncnames which contain any variable visible in the current scope. The variables 
can be based on WSDL message type, schema element, and schema simple type.

New "validateXML" attribute for <Assign>

A new "validateXML" 
attribute is suggested to be added to <assign> activity:

<assign validateXML="yes|no"? >
    <copy />+ 
</assign>

The default of that boolean attribute is 
"no". 

It can be seen as a convenient marco of a sequence of  
<assign> and <validateXML> operations. With validateXML="yes", the 
<assign> activity will validate all the variables used by to-specs, which 
are being modified by the <assign> activities. 

(This validateXML 
attribute pattern can be applied to other activities which creates a new 
variable value. e.g. the potential forEach functionality).

Standard Fault

If any validation (explicit or implicit) described above 
fails, a standard fault bpws:invalidData MUST be thrown by an  
implementation.

References

Fragments copied from 
XUpdate Requirement document

[XQuery Update Requirements - Internal W3C Working Draft - 07 January 2004 ]
...
3.4.12 Validation

Updates MAY support an explicit or implicit in-place XML Schema validation

...

3.5.5 Validity at transactional boundaries

Updates MUST enforce schema validity at transactional boundaries. It MAY provide a mechanism to allow this constraint to be relaxed.

... 
Changes: 10 Aug 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 160 - [anything]" or is a reply to such a message. If you want to formally propose a resolution, please start the subject line "Issue - 160 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).