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] Re: Issue 51 - Seed proposal coming from Issue 157



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



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