Re: [wsbpel] Issue 157 - dimension of type checking and recap ofpast discussion and resolution

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

The key issue is that message activities already allow for bad data to 
come into the system because we don't mandate validation. So banning 
WSDL to WSDL message copying if the type names aren't the same means 
that you can still get bad message data but not from copy. That's a 
needless inconsistency. We should be consistent and allow for copies 
only validating when the validation flag is specified.

Alex Yiu wrote:
> 
> Hi all,
> 
> 
> *Dimension of type checking
> *
> *[A]*
> Regarding to the Issue 157 discussion conf call today, we mainly talked 
> about the type checking issue. I want to point out that there are two 
> dimensions of type checking that we should be very clear about:
> 
>     * Dimension #1:
>           o WSDL message type checking
>           o XSD type checking
>     * Dimension #2:
>           o Static analysis type checking
>           o Runtime type checking
> 
> When we discuss this topic, we should be very clear about which 
> combination of the above we are talking about. Lumping them together 
> will just create too much muddy water.
> 
> *[B]
> *One of the focal point today is: Static type checking for copying WSDL 
> message type variables.
> 
> I believe we should ask ourselves the following question:
> 
>           o Do we want to allow a msg-variable to msg-variable copy:
>             from msg-variable-X of POMsgType
>             to msg-variable-Y of ShippingOrderMsgType?
> 
>             And, only relies on runtime validation afterwards?
> 
> 
> 
> *Recap of Past Discussion and Resolution
> * ... to refresh people's memory ....
> 
> *[C]*
> Issue 160 was mentioned a number of times in the discussion.
> 
> Here is the passed resolution:
> http://lists.oasis-open.org/archives/wsbpel/200502/msg00085.html
> 
> The main motivation of this resolution to allow people to catch grey 
> cases *during runtime* by using <assign validate="yes"> or <validate 
> ...  />
> 
> I listed a number of grey cases for static type analysis in Background 
> and Rationale section.
> 
> Goals of the resolution are listed very clearly (here I quote from the 
> resolution):
> -------------------------------------------------
> 
>     * We believe the XML data only needs to be validated at the runtime
>       only at certain points of BPEL execution: 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 as much as possible during static
>       analysis.
> 
> -------------------------------------------------
> 
> Other than above sections, static type analysis is not mentioned in the 
> rest of resolution.
> 
> 
> *[D]
> *June F2F Discussion
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/13150/Minutes%20June%201-3.htm
> 
> Quoting the related part discussion from the minutes (with highlight):
> ---------------------------------------------------------------
>              xxxiii.      (Alex) Stesses difference between static and 
> runtime
> 
>              xxxiv.      (Andrew) more question about default – can 
> vendor do this? Diane says we need a proposal in the future for that
> 
>               xxxv.      (Berndt) we need to allow for static analysis 
> in design time
> 
>              xxxvi.      (Alex) wants to add proposal… Diane wants it 
> well formed
> 
>            xxxvii.      /(Berndt) What kind of checking can we do before 
> deploy time? Maybe reject before running – doesn’t want to disallow this 
> case – Alex says that could be part of a future proposal… will wait to 
> submit proposal./
> 
>           xxxviii.      /(Satish) If I can catch an error before runtime 
> why not? The spec doesn’t prohibit this, what are we doing here? For 
> example in “from” you could have an expr that fails… Some of this 
> proposal language sounds more general than maybe you intended it to be…/
> 
>              xxxix.      (Berndt) question about language in proposal
> 
>                        xl.      (Alex) can we reword ? flip the intent 
> around?
> 
>                       xli.      (Yaron) then how do we explicitly say 
> what should be checked?
> 
>                     xlii.      (Alex) turn it around – if you care about 
> portablility – just say what static analysis is turned off? Vigorous 
> discussion with Yaron…
> 
>                    xliii.      (Satish) clarifying – because so many 
> things are optional because of schema weakneses – (syntactic) – We do 
> not mandate any static analysis for catching runtime errors – if switch 
> is off then no static checking beyond syntactic – proposes a broader 
> statement of checking.
> 
>                   xliv.      /(Yaron) We need a switch to say you cannot 
> reject a process because you predicted that a runtime error would occur./
> 
>                     xlv.     / //(alex) is this for all analysis??/
> 
>                   xlvi.     / //(Yaron) all static analysis that 
> predicts a runtime error…/
> 
>                  xlvii.      (Berndt) Why are we doing this? …
> 
>                xlviii.      (Yaron) but syntactic checking is always 
> allowed…
> 
> ---------------------------------------------------------------
> 
> Note: The "switch" part will be as a part of Issue 9 resolution.
> 
> 
> 
> Thanks!!!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
>