[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 250 - Proposal for Vote
Should this be
allowed:
<flow>
<link name="crossesExtensionActivity"/> <receive> <source name="crossesExtensionActivity"/> </receive> <extensionActivity> <other:notUnderstoodExtendedSequence> <target name="crossesExtensionActivity"/> <invoke/> <validate/> <assign/> </other:notUnderstoodExtendedSequence> </extensionActivity> </flow> The above example collapses easily enough
into an empty without any errors.
The <extensionActivity> element
doesn't have the standard attributes and standard elements so we should be
careful about boundary crossing terminology since all links will cross the
<extensionActivity> boundary into a contained element.
How does this sound:
Links MUST NOT cross an extensionActivity
into an activity that is not the immediate child of the
<extensionActivity> unless the namespace for the extension has been
declared with a mustUnderstand="yes".
From: Danny van der Rijn [mailto:dannyv@tibco.com] Sent: Friday, March 31, 2006 4:55 PM To: Alex Yiu Cc: Rania Khalaf; wsbpeltc Subject: Re: [wsbpel] Issue 250 - Proposal for Vote If the original wording caused you to understand it that way, then it does need to be changed. However, your rewording doesn't match the intent of what Rania and I were working towards.
We weren't suggesting a normative change here. We were pointing out resultant behavior. We weren't saying to ignore the links in an extensionActivity. We were saying that if there's something like: (syntax compressed for ease of my typing...) <flow> <link name="crossesExtensionActivity"/> <receive> <source name="crossesExtensionActivity"/> </receive> <extensionActivity> <other:notUnderstoodExtendedSequence> <invoke/> <validate/> <assign> <target name="crossesExtensionActivity"/> </assign> </other:notUnderstoodExtendedSequence> </extensionActivity> </flow> then the fact that someone won't understand the notUnderstoodExtendedSequence means that they're not going to know what to do with the assign embedded inside. Since that assign contains the target of the link, they won't know what to do with the process. Therefore to maintain portability, we're proposing that ALL processors must reject the process. Note that we're not talking about standard elements on the extensionActivity itself, but those contained within embedded activities. First - do you agree with that sentiment? Second - if you do, then we can go ahead with new wording, possibly with an example. I think the simplest wording, that doesn't include any rationale or examples, etc., would be along the lines of: Any link that has an extensionActivity as a source or target is legal. However, links MUST NOT cross an extensionActivity into a contained activity if the namespace of the extensionActivity is not declared with mustUnderstand="yes." Granted that still isn't simple... Alex Yiu wrote: --------------------------------------------------------------------- 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]