OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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.


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


  • 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 />+

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.


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

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]