[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]