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





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