[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 295
Hi all, Sorry for following this issue a bit late. Yes, it would be a different issue to add additional element/type related info at <fromPart>. Also, given this lifecycle of the spec, I don't think it worths to open a new issue fort that. Thanks! Regards, Alex Yiu Thomas Schulze wrote: >Hi Mark, > >I agree with you. It would be for readability only and differs from the >variable attribute. Not sure if it is worth to open an issue for that... > >Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > > > > "Mark Ford" > <mark.ford@active > -endpoints.com> To > Thomas Schulze/Germany/IBM@IBMDE > 07.06.2006 16:08 cc > "'Alex Yiu'" <alex.yiu@oracle.com>, > "'Danny van der Rijn'" > <dannyv@tibco.com>, "'wsbpeltc'" > <wsbpel@lists.oasis-open.org> > Subject > RE: [wsbpel] Issue - 295 > > > > > > > > > > >You should open this as a separate issue. > >The additional attribute is not required but it may improve readability. >It's similar to the portType attribute on the message exchange activities >(invoke, receive ...etc). These new attributes would be optional and if one >is present it MUST match the declared type of the message part. Obviously >the attributes are mutually exclusive. This would be another static >analysis >check. > >That said, this is slightly different than the variable attribute for the >onEvent. In the case of the onEvent we need the additional attribute in >order to determine if the variable will be an element or a message. In the >case of the <fromPart>, we've already received the data into an ATWMV >(Anonymous Temporary WSDL Message Variable) so the part name is all that is >required to access the data. > >-----Original Message----- >From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com] >Sent: Wednesday, June 07, 2006 3:10 AM >To: Mark Ford >Cc: 'Alex Yiu'; 'Danny van der Rijn'; 'wsbpeltc' >Subject: Re: [wsbpel] Issue - 295 > >Hi Mark, > >thanks for resending ;-) > >Regarding "As for the question about defining a variable's type in ><fromPart>'s implicit var declaration, I believe we state that the type >comes from the message part's type declaration." >Comparing this with the variable declaration on onEvent when using the >variable attribute instead of <fromPart>, it would be more consistent to >have the declared variable type not only in the WSDL message part, but in >the BPEL process itself. > >Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > > > > "Mark Ford" > <mark.ford@active > -endpoints.com> To > "'wsbpeltc'" > 07.06.2006 00:37 <wsbpel@lists.oasis-open.org> > cc > "'Alex Yiu'" <alex.yiu@oracle.com>, > Thomas Schulze/Germany/IBM@IBMDE, > "'Danny van der Rijn'" > <dannyv@tibco.com> > Subject > [wsbpel] Issue - 295 > > > > > > > > > > >Resending Thomas's email with the issue # in the subject. > >I believe that Thomas has identified all of the issues where this applies: >- <variable name="..."> >- <forEach counterName="..."> >- <onEvent variable="..."> >- <onEvent>'s <fromPart toVariable="..."> >- <catch faultVariable="..."> > > >Would we want to update all of pseudo schema examples to use the new type >name or leave them as NCName? > > >As for the question about defining a variable's type in <fromPart>'s >implicit var declaration, I believe we state that the type comes from the >message part's type declaration. > > >-----Original Message----- >From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com] >Sent: Monday, June 05, 2006 4:11 AM >To: Mark Ford >Cc: 'Alex Yiu'; 'wsbpeltc' >Subject: RE: [wsbpel] RE: NCName restriction to avoid "." > >+1 to the idea catching this by the schema validation. > >Isn't this constrain only needed for those places where new variables are >declared? That should be <variable name="...">, <forEach >counterName="...">, ><onEvent variable="..."> and the <fromPart toVariable="..."> version of ><onEvent> and <catch faultVariable="...">. > >All other cases are variable references. Not sure if we really need it >there. > >Btw. doesn't the <fromPart toVariable="..."> variant of <onEvent> require >the variable's type defined (attributes messageType, element and type)? > >Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > > > > "Mark Ford" > <mark.ford@active > -endpoints.com> To > "'Alex Yiu'" <alex.yiu@oracle.com> > 05.06.2006 01:35 cc > "'wsbpeltc'" > <wsbpel@lists.oasis-open.org> > Subject > RE: [wsbpel] RE: NCName restriction > to avoid "." > > > > > > > > > > >Yes. Basically, anywhere that we're referring to a variable the type should >be "BPELVariableName" instead of "NCName". Of course I'll leave the actual >selection of the name to the schema powers at be but you get the idea. > >The only downside to this is that we need to add a little more text to the >current spec to define what this type is since it will appear in our pseudo >schema examples. This may impact readability a little but it goes a long >way >in making the restriction explicit. If I were reading the spec for the >first >time and I saw "BPELVariableName" for the data type I would naturally >assume >that there was some restriction in play and then go and find the definition >of this type. As it is now, NCName appears in multiple places without any >kind of qualifier to indicate that it's a restricted NCName. > >From: Alex Yiu [mailto:alex.yiu@oracle.com] >Sent: Sunday, June 04, 2006 7:26 PM >To: Mark Ford >Cc: 'wsbpeltc'; Alex Yiu >Subject: Re: [wsbpel] RE: NCName restriction to avoid "." > > >Mark, > >Do we want to apply the same restriction to variable attribute of <from> >and ><to> spec also? > >Thanks! > >Regards, >Alex Yiu > > >Mark Ford wrote: > +1 from me ;) > > This would also apply to the implicit variables created by a > <fromPart> nested within an onEvent. > > I'll open an issue on this. > > From: Alex Yiu [mailto:alex.yiu@oracle.com] > Sent: Sunday, June 04, 2006 5:38 PM > To: wsbpeltc > Cc: Mark Ford; Alex Yiu > Subject: NCName restriction to avoid "." (was: [Fwd: BPEL Schema > question]) > > > Hi guys, > > Mark has the following suggestion to use the data type other than > NCName to restrict the "." usage in variable names. > > I am OK with it. > Thought? > > Thanks! > > Regards, > Alex Yiu > > > -------- Original Message -------- > > Subject: BPEL Schema question > > Date: Sun, 4 Jun 2006 13:27:35 -0400 > > From: Mark Ford <mark.ford@active-endpoints.com> > > To: 'Alex Yiu' <alex.yiu@oracle.com> > > > > > > > Hi Alex, > > > What do you think about changing the data type of a variable's name > to be a restriction of NCName to disallow the "." as described in > Section 8.1? The dot is a legal value for NCNames but disallowed for > Xpath binding purposes of message variables. > > > This also applies to the name of the counter attribute on a > <forEach>. > > > I'd prefer to catch these types of errors with the XSD as opposed to > having to write code to catch them during static analysis. > > > 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 > > > > > > > > >--------------------------------------------------------------------- >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]