[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:
[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:
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): -------------------------------------------------
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]