Hi Yaron,
(cc'ing Bernd)
(1)
I also think it is a good idea of adding a text to clarify the
relationship between runtime and static time analysis with the validate
switch at <assign> .
How about the following changes (highlighted in GREEN).
· In all other cases, «if the selection results of
the source (from-spec) and destination (to-spec) are XML Infoset
Information Items, and the XML Schema types of these are known», then
the source value MUST possess «the type» associated with the
destination. Note that this does not require the types associated with
the source and destination to be the same. In particular, the source
type MAY be a subtype of the destination type. «The required XML Schema
type checking can be determined by static analysis and/or evaluated at
runtime. A BPEL processor MAY perform static analysis of the
expression/query language to validate compliance with this
compatibility requirement, and reject a process definition if the
requirement is violated. ||Majority of static
analysis of expressions/queries are operated basing on an assumption
that the data before any manipulation are valid with respect to
corresponding XML Schemas. If a WS-BPEL processor cannot deduce such an
assumption for data being manipulated, related static analysis of
expressions/queries MUST not be performed. Typically, a piece of XML
data can be presumed to be valid right after message operations, as the
underlying message infrastructure provides such a validity guarantee or
after an <assign> activitiy where the "validate" switch is set to
be "yes" or after a <validate> activity is executed.||
When a BPEL processor adopts an XML Schema type aware data model, it
MAY perform the same analysis at runtime, where, on encountering a
violation of the compatibility requirement, it MUST throw a
bpws:mismatchedAssignmentFailure fault. ||Similarly,
the type of a piece of data is known only after the data is confirmed
to be valid against correponding XML Schemas. Such a validity
confirmation is typically achieved via XML Schema Validation, which is
provided by either the underlying messaging infrastructure or
<assign> activity with "validate" set to true or a
<validate> activity.|| Note that when the default XPath
1.0 expression/query language binding is used, XML Schema runtime
type-compatibility checking MUST NOT be performed, as the XPath 1.0
data model is not XML Schema type aware.»
(2)
Yaron wrote: "Similarly the text should explicitly point out that no
form of static schema validation can be applied when XPATH 1.0 is
used."
I am not sure I can agree with you here. With XPath 1.0, static schema
validation would be limited. But, it is feasible to still do some
validation.
Bernd from SeeBurger gave a good and simple example during the last F2F
at Palo Alto. e.g. "$poVar/p:lineIteem" (Note: I intentionally
introduce a typo here "Iteem" instead of "Item".
Without any expert logic on schema, one can easily match the QName in
the XPath step with any <xsd:element> declaration in related
schema definition. If a QName cannot match any element name
declared/defined in XSD, then that is a clear "black" case (not grey
case) which can be ruled out easily.
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
One of the
challenges in creating a XML document from content in various messages
is that one must incrementally build up the content of the message from
incoming messages. This inevitably means that the XML document being
built up will go through periods where it is not schema compliant. To
deal with this we provide an explicit switch on copy to control when
schema validation is used. The text below makes no reference to that
switch and would lead the naive reader to believe that static schema
validation can be applied even when the switch is set to off. Minimally
the text needs to be amended to explicitly state that static schema
validation can only occur when the switch is turned off. Similarly the
text should explicitly point out that no form of static schema
validation can be applied when XPATH 1.0 is used.
Yaron
Alex Yiu wrote:
Hi all,
Here is the "seed" proposal for Issue 51 - coming from section (C) of
previous version of proposal draft for Issue 157.
Let's get the ball rolling ... :-)
Thanks!
Regards,
Alex Yiu
----------------------------------------------------------
Update Section 9.3.2, “Type Compatibility in Assignment”, as
follows:
* Update the section title to “*Type Compatibility in Copy
Operations*”
* Update the first paragraph of the section and first two bullet
items
following to read (changes denoted by «»):
“For «a copy operation» to be valid, the data referred to by the
from and
to specifications MUST be of compatible types. The following
points make
this precise:
· The «selection result of the» from-spec is a variable of a
WSDL message type, and the «selection result of the» to-spec is a
variable of a WSDL message type. In this case, both variables MUST be
of the same message type, where two message types are said to be equal
if their qualified names are the same.
· The «selection result of the» from-spec is a variable of a
WSDL message type, and the «selection result of the» is not, or vice
versa. This is not legal because parts of variables, selections of
variable parts, or endpoint references cannot be assigned to/from
variables of WSDL message types directly.”
* Update the third bullet item to read (changes denoted by «»):
· In all other cases, «if the selection results of the source
(from-spec) and destination (to-spec) are XML Infoset Information
Items, and the XML Schema types of these are known», then the source
value MUST possess «the type» associated with the destination. Note
that this does not require the types associated with the source and
destination to be the same. In particular, the source type MAY be a
subtype of the destination type. «The required XML Schema type checking
can be determined by static analysis and/or evaluated at runtime. A
BPEL processor MAY perform static analysis of the expression/query
language to validate compliance with this compatibility requirement,
and reject a process definition if the requirement is violated. When a
BPEL processor adopts an XML Schema type aware data model, it MAY
perform the same analysis at runtime, where, on encountering a
violation of the compatibility requirement, it MUST throw a
bpws:mismatchedAssignmentFailure fault. Note that when the default
XPath 1.0 expression/query language binding is used, XML Schema runtime
type-compatibility checking MUST NOT be performed, as the XPath 1.0
data model is not XML Schema type aware.»
* Remove the last paragraph of the section.
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
