Issue 157 - dimension of type checking and recap of past discussionand resolution

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:

  
    
WSDL message type checking

    

    
XSD type checking

  
  
Dimension #2:

  
    
Static analysis type checking

    
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:

  
    
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