Hi, Danny,
Thanks for agreeing on the values of this proposal. :-)
Issue 100 was closed in SF F2F in Jun.
I tried to resist the closure action on issue 100 during the F2F. Not
much success. :-)
Some people found the description of issue 100 was a bit too general
and it was mentioned that it is OK for me to open a new issue of
similar nature with a more well-defined scope.
Regards,
Alex Yiu
Danny van der Rijn wrote:
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.
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.
