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: Re: [wsbpel] Issue 247 What goes into the static analysis table?



>ford: Monica,
>The requirement of having a scope within a forEach is something that should
>be caught by the standard schema validation and not something that we should
>have in this appendix. 
>
>I agree though that the change identified below should be applied to the
>spec text. Stating that the forEach MUST have a scope and explaining why is
>good. My only point is that we don't need to reiterate this as a rule check
>for syntax analysis since the schema will enforce it for us.
>
>Perhaps the appendix that identifies all of the static analysis checks
>should include a statement that these are all the checks that MUST be run on
>a process after the process definition has been validated against the
>schema. 
>  
>
mm1: I think this would be a good addition to the appendix and clarify 
the analysis requirement. Thanks.

>-----Original Message-----
>From: Monica J Martin [mailto:Monica.Martin@Sun.COM] 
>Sent: Wednesday, April 12, 2006 9:16 PM
>To: Mark Ford
>Cc: 'wsbpeltc'
>Subject: Re: [wsbpel] Issue 247 What goes into the static analysis table?
>
>Mark,
>In looking at the editors' most recent version of Section 11 (11.6.3), Danny
>vanderRijn pointed out a change that had not been applied related to Issue
>204.  In that issue a syntactic static analysis requirement appears to be
>referenced. Note, I plan to bring this up in the Section
>11 review so a proposed textual change can be considered. Issue 204
>resolution (from Alex Yiu) references this syntactic restriction and static
>analysis.
>
>11.7 (line 4452):
>In order to address Danny's mention of Issue 204.
>Change from:
>The child activity of a <forEach> MUST be a <scope> activity.  The <forEach>
>construct introduces an implicit counter variable, and also introduces
>dynamic parallelism.
>
>Change from:
>The child activity of a <forEach> MUST be a <scope> activity.  This MUST be
>enforced by static analysis. The <forEach> construct introduces an implicit
>counter variable, and also introduces dynamic parallelism (i.e. 
>having parallel branches of which number is not known ahead of time).
>
>Reference in Issue 204 resolution:
>
>    "...Recap and More Details:
>    To restrict that the child activity of:
>    (a) an <onEvent> and <onAlarm> under <eventHandler>
>    (b) a <forEach> activity
>    MUST be a <scope> activity.
>
>    This restriction MUST be enforced during static analysis. (XSD will
>    be updated to reflect this restriction). ..."
>
>    See: http://lists.oasis-open.org/archives/wsbpel/200507/msg00077.html
>
>Thanks.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>  
>




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