Re: Issue 51 - Seed proposal coming from Issue 157

["Yaron Y. Goland" <ygoland@bea.com>]

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