RE: [wsbpel] Re: Issue 51 - Seed proposal coming from Issue 157

Hello,

 

personally I think we should allow but not enforce all 
kinds of static checks where the engine can be sure it would cause an runtime 
error. We dont need to define the conditions closer since it basically means 
"apply all your knowledge about the spec to a condition, if there is no external 
event with can make this situation not fail, then you might as well reject it on 
deployment".

 

However your suggestions Alex where you would consider a 
message to be valid are usefull additions to the spec.

 

Greetings

Bernd

From: Alex Yiu [mailto:] 

Sent: Tuesday, September 13, 2005 7:36 AM
To: 

Cc: wsbpeltc; Charlton Barreto; Alex Yiu; Eckenfels. 
Bernd
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