Re: [wsbpel] Issue - 160 - facilities to define XML schema validationboundary

time to look at 160 again, i think.  i find alex's proposal to be quite
reasonable.  as an aside, this is the same issue as 100 which is marked
as closed, yet i can find nothing in the Waldorf F2F minutes that would
explain why it is closed.

danny

ws-bpel issues list editor wrote:

  
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  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).
  

  
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.