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